Big5 0xC8B8 的問題

在 MozTW 那邊討論時發現到一個問題

Big5 0xC8B8 在不同的 Big5 -> Unicode 碼表會轉換到不同的碼位去

一些舊的碼表，如 Big5-Eten 或 Mozilla 1.5 使用的碼表，會轉到 U+FB02

許多 unicode 字型在這個碼位是空的，或者是其他符號

如果是 Unicod-At-On 2.41 或 Mozilla 1.8 的表，會轉到 U+30FB (・)

google 一下，看到 PCMan 開發時也遇到這個問題

不曉得各位有什麼看法？

各種碼表我是參考 Big5 Variants in Mozilla: Mozilla 系列與 Big5 中文字碼

所以mozilla 有自己的轉換 table，不是用 iconv

Big5-Eten 會把一些字轉碼到 PUA，目前 GNU libc 就是如此。但其他的 libc 或轉碼 lib 則不一定。不管哪一種轉碼表， Big5-Eten 有些字是不可逆的。

這個沒辦法，歷史因素，不是說誰的對或錯的問題，我出生的時候從來沒想到過將來會有 Unicode。

U+F802 才對。

對照 0xC8B8 前後的同一系列編碼，看起來轉成 U+F802 應該是合理的。

Big5 本來就沒有和 Unicode 一對一對應。

底下列出幾個解決不了的問題：

1. Big5 本來就很多種

2. 不同國家的各大字型廠商各造各的字，各支援不同的編碼

3. glibc 裡的 Big5 和 CP950 也不一樣

4. 有些轉碼本來就沒有一定的轉法 (glibc 裡的 GBK ←→ UTF-8 ←→ GB2312 竟然會轉出不同結果，理論上 GBK / GB2312 是 100% 相容)

這種沒有一定轉法的符號，應該改成其它有固定轉法的符號，這樣就沒困擾了。

哈哈，目瞅被蛤肉糊到

是 U+F802 才對沒錯，謝謝幫我挑出來

以實際功能來看，這個問題只有在「閱讀」的時候比較需要特別去解決

此時，大多會希望 Big5 0xC8B8 轉到 U+30FB

如果是在系統，倒也好解決，在 editor 或文書處理軟體搜尋/取代一下就好了

如果是在網頁上，目前想到的解法是用 greasemonkey 或 bookmarklet 手動把 U+F802 轉成 U+30FB

可是我不會寫 XD

或者，乾脆把 AR PL New Sung U+F802 的 glyph  改成・

:P

不妥，學行列的人會抗議。我沒弄錯的話，那是行列輸入法字根符號。

我比較好奇的是為什麼會用到  U+F802？這些是屬 PUA 的字，要流通的話就要盡量避免用到這裡的字。

圓點有好幾個，都有固定的 Unicode 編碼可用，我是認為是寫文章的人的錯誤輸入造成的？

我一直搞不懂 AR PL New Sung 的 U+F802 是什麼符號 :P

那可能是從 BBS 拷貝下來的

貼到 unicode 網頁上，就變成這樣了

我的意思是，不知道這個符號代表什麼意思  :)

那要問行列的專家。行列輸入法的 cai 就有一堆這些符號。

這可能是 bbs 上就有問題了，有些 bbs 是用補完計劃之類的在顯示，轉換成正規的會出問題。所以，這些補完計劃的私人 spec 是不值得鼓勵的，會愈弄愈亂。

日文要轉回 Big-5，會出問題的是 U+30FB 這個圓點，因為沒有相對應的 Big-5 碼位給他，而當初倚天的那些日文，竟然是不含這個圓點的，所以無法對應到。變通的辦法是多一層轉換，把  U+30FB 轉成 U+2027 或 U+FF0E 再來轉回 Big-5 碼。

對於 UAO 特有的 big5 字元，有裝 UAO 的人，不會有任何問題。當轉到 Unicode 時，是正規的 Unicode，不是 PUA 內的 Unicode，所以不會製造問題。當使用 big5 時，那些字元，原本的 big5 本來就不能顯示 (HTML Entity 除外)，UAO 讓我們可以顯示那些字元。

對於 UAO 特有的 big5 字元，沒裝 UAO 的人，會有很大問題。當轉到 Unicode 時，那些字元會跑到 PUA，許多字型無法正常顯示那些字元。當使用 big5 時，無法顯示 UAO 特有的 big5 字元。

所以我覺得大家都裝 UAO 比較實際一點。(期待 Linux/FreeBSD 也能支援！)

這樣好像兜了遠路，我覺得鼓吹大家用 UAO，把 UAO 變主流，以後這種問題就會比較少了。

UAO 是問題的根源啊，它一直都是小眾，且從來不是標準。

鼓吹用 UAO 是完全沒意義的。

千萬不要啊！私有規格最後會害了下一代人，Big-5 碼就是個活生生的例子！Orz

可行之道是使用 Big5-2003 並在各 libc team 之間最得共識（當然我們自己要先有共識）。

BSD libc/GNU libc team 接受私有規格的可能性不大。當初 Big-ETEN 是居士磨了好久才接受的。現在有關 locale/i18n 的開發人員都有共識，不會隨意接受私有規格，所以，UAO 盡早消失，下一代受害就會輕些。

我 PO 出上一篇就知道一定會有不同意見。 :)

只能說，我是一個使用者，從使用者的角度來看，我認為那是目前最實用的解決方式。

支持的原因最重要的就是：

• 它不會繼續製造 Unicode PUA 的字。
• 讓 Big5 可以顯示日文、簡體。
• 要人放棄在 Big5 環境使用日文，就像要人禁慾一樣，太不實際。

不過，我又不會寫程式，所以各位不用太擔心。 XD

微軟還沒支援 Big5 2003 ?

嚴格而言，這並不是不同意見，而幾乎是一種共識了。

我就是純粹使用者（Big-5 受害者）的角度來說明的。並不是程式設計的角度。

請考慮一下所要付出的社會成本，長期文件的轉檔、轉碼問題。使用者重新適應的問題。主流社會接不接受的問題。

Big-5 就讓他功成身退吧！不然還會搞出更多文化斷層之事，我這絕不是危言聳聽。

該改的是 bbs 文化或系統。 尤其 ptt 這種人多的站。

使用者的習慣常常左右程式設計師，eliu 就是受害者之一（誤）！

要不要的問題，微軟也還沒支援 CNS 11643 呀！這可是台灣的唯一國家及世界承認的標準（唯二是 Big5-2003）。

瞭解了，你是在說用 unicode 取代 big5？

我當然很同意把主流從 big5 導向 unicode，這也是現在的趨勢。

可是我覺得這不代表 big5 這種舊編碼就要消失，因為，unicode 對某些人來講並不是那麼必要，在適當的時機使用適當的工具就好了，big5/Unicode 各得其所。

Anyway, 剛想到一個 UAO 的大問題：把造字區用光，使用者好像就不能造字了哦？

 

感覺好像應該由政府來想辦法解決 

但是像

Why is GB18030 important?

就變成笑話了 :D

不是要消滅 Big-5，而是有其他需求，盡量使用標準規格，對內對外都容易接軌。

Big-5 要留著有備無患，但盡量使用標準，例如 Big-5 2003。Big-5 無法滿足需求時，顯然該改用合需求的編碼系統才是，而不是私下改 Big-5 的內容。請想想看，如果是專門討論古文或中醫的論壇，硬要用 Big-5，這不是在自討苦吃嗎？連內容的傳承都會出問題。所謂的傳承，不僅僅是在某些軟體或某些作業系統，傳承的東西是國際觀的。

民主國家當然不可能像中共這樣做。但現在既然 Big-5 2003 已成 CNS 11643 標準的附錄，為何不用呢？有其他需求就要用其他需求的編碼，例如戶政就是用 CNS 11643，圖書館系統會用 CCCII，只要你用標準公開的規格，別人才有辦法去接軌。

如果標準可以落實，當然是使用標準啊，可是，現在情況是， BBS、微軟不改 unicode、不支援 big5 2003，就很難說服人家不用 UAO。

 

我覺得很怪，為什麼我們政府事情只做半套，把標準訂出來以後，沒有想到推廣的問題？Big5 不夠用，不是一天兩天的的事了。

畢竟比起所有中文電腦使用者，UAO 算是小眾。微軟已經走向 Unicode 化，當然就不會在 Big-5 出力氣了，他當然是希望大家習慣用 Unicode。

bbs 不改，所以才會說，問題的根源，其實是在 bbs。

因為沒人要用。而要另立標準，需得到 iso 那邊的認同。但我們目前的政治立場無法得到認同，CNS 11643 當時成立標準，據說是私人商業團體幫忙的。

有了 Windows，Big5 應該還會存在很久。 Windows 只支援 unicode UTF-16 or Big5(cp950)。 

UTF-16 需要改很多，而且 ascii 的情形浪費空間。像 zip .7z  好像也沒聽過用 UTF-16 儲存 file/dir names. 一堆 mp3 也還是用 big5 當歌名。

懷疑 Windows 的 MBCS(multi-byte character set) 不支援 UTF-8 可能是故意的。

記得他們是故意不推 utf8 的。