由 堃(方方土) 探討 Big5e 編碼 前言 會寫這篇文章是因為想討論看看 Big5e 是否有推行的必要性，以及此方案的可行性和大家對這個編碼的看法，順便整理一下自己對 Big5 的觀念。此篇文章只介紹 Big5 與 Big5e(使用於政府行政機關)，並不會多著墨於 CNS11643(公文交換系統用)、CCCII(只使用於圖書館OPAC系統)、Unicode(這個大家最熟了∼)。 當開始蒐集資料後，覺得 Big5e 只能是一個過渡方案，大家且聽我慢慢道來。本文還有許多疏漏之處，還請大家多多指教。  | | 游錫方方土任民進黨秘書長 | 游錫方方土？台灣開始有五個中文漢字的人名了呀？ 無意開政治人物的玩笑，只是為何不直接將那字打出來就好了， 還要拆開來打呢，實際上 堃(方方土) 在我們常用的 Big5 的編碼下是不存在的， 這造成了我們無法輸入、輸出、顯示 堃(方方土)。 何謂編碼？ 在介紹編碼前，先介紹另一個名詞：字集(Character Set)， 字集是一組符號或文字的組合，而編碼(Encoding)則是將這一組符號或文字以適當的方式編入位元組中，以便電腦能夠表示與儲存。在許多情況下，由於 一個編碼方式所能容納的字數是有限的，所以可能一個編碼沒辦法包含整個字集，例如，Big5 編碼只是中文字集的一部分。當然也有一個編碼包含許多字集的，例如 Unicode 的目標是包含所有字集。 英文系統內一樣有編碼。以一字節八位（8BITS）排列，共可得256個組合，即0至255。但由於英文字母加上大小寫及常用的符號後，也不到128個，所以在早期的電腦系統內，只用了0至127（即十六進制的00至7F）。 西文由於基本字符少，所以用2的8次冪就能包涵所有的字元。它的內碼集共0至255，名為ASCII。 但是中文字集龐大，擁有數萬字，8Bits 已經不敷使用，所以使用了 16Bits 固定長度的 Big5 編碼，不過 16Bits 也只頂多能表示 65535，還考慮相容於 ASCII，所以能用的字少很多，所以後來出現了 CCCII 以及 CNS11643 的中文編碼。 而最近也開始有人推 Unicode，這是準備包含所有字集的編碼。 在 UNIX 底下也就常會看到 zh_TW.Big5，在此，zh_TW 為中文字集， 而 Big5 為編碼。 目前 Big5 編碼的長度都是兩個 Byte，所以在本文中將會使用 00~FF 來代表一個 Byte，這是十六進位的表示法。所以，一個 Big5 編碼的字就會用 0000~FFFF 來表示，前兩個字十六進位代表高位元， 後兩個代表低位元。 在現行的系統下，在同一種環境中，只能顯示一種編碼， 所以只要這個編碼沒支援的字，就沒辦法顯示。 Big5 編碼 背景 Big5 碼是 1984 年台灣資訊工業策進會根據《通用漢字標準交換碼》 制訂的編碼方案。(學長看到這個就說： 原來 Big5 是資策會發展的呀，終於知道兇手是誰了。 我看編碼系統發展的第一步就是把這種萬惡的機構先裁掉，再把該負責的人 抓出來鞭數十，驅之別院....) 編碼空間 BIG5 碼系統為兩位元組之內碼系統，共可定義 19782 個字碼，其高、低位元組的範圍如下： - 高位元組 0x81~0xFE
- 低位元組 0x40~0x7E、0xA1-0xFE
其第一位元組的值在 16 進制的 A1∼FE 之間， 第二位元組在 40∼7E 和 A1∼FE 之間。因此，其第一位元組的最高位元是 1， 第二位元組的最高位元可能是 1，也可能是 0。 Big5 在上述範圍內，規劃出標準字(STDFONT)、特殊符號(SPCFONT、SPCFSUPP)及使用者造字(USRFONT)的區域，分別說明如下： | | 使用範圍 | 字數 | 保留範圍 | 字數 | | 標準字 常用字 | A440~C67E | 5401 | C6A1~C8FE | 408 | | 標準字 次常用字 | C940~F9D5 | 7652 | | | | 標準字 倚天字 | F9D6~F9FE | 41 | | | | SPCFONT 標準字 | A140~A3BF | 408 | | | | SPCFONT 控制碼 | A3C0~A3E0 | 33 | A3E1~A3FE | 30 | | SPCFSUPP 標準字 | C6A1~C8FE | 408 | | | | 使用者造字 第一段 | FA40~FEFE | 785 | | | | 使用者造字 第二段 | 8E40~A0FE | 2983 | | | | 使用者造字 第三段 | 8140~8DFE | 2041 | | | 筆劃對照表 這是 Big5 編碼的規則之一。 | 中文字型筆劃順序內碼對照表 | | 筆劃 | 常用字區 | 次常用字區 | 筆劃 | 常用字區 | 次常用字區 | | 01 | A440-A441 | | 16 | BEA7-C074 | E8F4-ECB8、F9D9 | | 02 | A442-A453 | C940-C944 | 17 | C075-C24E | ECB9-EFB6 | | 03 | A454-A47E | C945-C94C | 18 | C24F-C35E | EFB7-F1EA | | 04 | A4A1-A4FD | C94D-C95C | 19 | C35F-C454 | F1EB-F3FC | | 05 | A4FE-A5DF | C95D-C9AA | 20 | C455-C4D6 | F3FD-F5BF | | 06 | A5E0-A6E9 | C9AB-C959 | 21 | C3D7-C56A | F5C0-F6D5 | | 07 | A6EA-A8C2 | CA5A-CBB0 | 22 | C56B-C5C7 | F6D6-F7CF | | 08 | A8C3-AB44 | CBB1-CDDC | 23 | C5C8-C5C7 | F7D0-F8A4 | | 09 | AB45-ADBB | CDDD-D0C7、F9DA | 24 | C5F1-C654 | F8A5-F8ED | | 10 | ADBC-B0AD | D0C8-D44A | 25 | C655-C664 | F8E9-F96A | | 11 | B0AE-B3C2 | D44B-D850 | 26 | C665-C66B | F96B-F9A1 | | 12 | B3C3-B6C3 | D851-DCB0、F9DB | 27 | C66C-C675 | F9A2-F9B9 | | 13 | B6C4-B9AB | DCB1-E0EF、F9D6-F9D8 | 28 | C676-C67A | F9BA-F9C5 | | 14 | B9AC-BBF4 | E0F0-E4E5 | 29 | C67B-C67E | F9C6-F9DC | | 15 | BBF5-BEA6 | E4E6-E8F3、F9DC | | | | 問題 一個很嚴重的問題是，編碼區的 C6A1-C8FE 中的字符並非統一， 在不同的編碼中有不同的字符。 C6A1-C8FE 這一段的內容在 MicroSoft 的 CP950( Code Page 950 )中不存在， 在 http://www.unicode.org 的網站上與現行的 Big5_eten 並不相同。下圖是倚天系統下的日文編碼，與 Big5 內此區段的內容不一樣( 因找不 Big5 字碼表，故無法貼圖比對)。  | | 倚天/國喬系統下的日文字型碼 | 以最常用的日文為例，在 Big5 中，C6A1-C6F7 為片假名， C6F8-C7B0 為平假名，但在 Big5_eten 中，C6E7-C77A 為平假名， C67B-C7F2 為片假名。我們目前常用的日文， 竟然與政府制定的日文編碼不同？ 後來有人告訴我，Unicode 網站上的 Big5 是 MAC 在使用的 Big5。 字碼不足 這是最嚴重的問題，就算用滿 Big5 的編碼區，還沒辦法表示所有的中文字集。 這個問題只能期待更好的編碼方式來解決。 內碼表 我寫了一隻 Perl 程式，列印了 A140~F9FE 之間的所有字元， 你可以用瀏覽器開起來看看你的 C6A1-C8FE 的顯示狀況。 程式：http://freebsd.sinica.edu.tw/~statue/hanzi/big5tbl.pl 列印出之字碼表： http://freebsd.sinica.edu.tw/~statue/hanzi/big5tbl.txt 參考資料：國內中文字碼之發展 以編碼空間來看常見的編碼 根據通訊定則之規定，所有控制碼均須避開，控制碼的範圍是 0x00∼0x20，以及 0x7F 均予避開，則 7bit 字碼集共有 128 - 33 - 1 = 94。 這是 CCCII 與 CNS11643 的做法。 Big5 與 Big5e 則是避開 0x00∼0x3F，0x7F，0xFF 等。 Big5 Big5 用兩個位元組表達一個中文字，編碼範圍是 [0x81∼0xFE][0x40∼0x7E、0xA1∼0xFE]，編碼空間大小為 (0xFE∼0x81)*((0xFE∼0xA1)+(0x7E∼0x40)) = 0x8D*(0x5D+0x3E) = 0x8D*0x9B = 0x555F = 21855。 MicroSoft 發行了 CP950，為 Big5 加上 F9D6∼F9FE。之後，倚天發行了倚天擴充字集( Big5_eten )，為 Big5 加上七個常用字 (碁粧裏墻恒銹嫺)(F9D6∼F9DC) & 劃字符號( F9DE~F9FE，╔ ╦ ╗╠ ╬ ╣ ╚ ╩ ╝ ╒ ╤ ╕ ╞ ╪ ╡ ╘ ╧ ╛ ╓ ╥ ╖ ╟ ╫ ╢ ╙ ╨ ╜ ║ ═ ╭ ╮ ╰ ╯ ￭ ) & 日文( C6A1-C8FE )。 Big5e Big5e 包含 Big5 外，又加了一些新字，所以編碼範圍是 [0x81-0xFE][0x40-0x7E0x80-0xFE]，編碼空間大小為 (0x81-0xFE)*((0x40-0x7E)+(0x80-0xFE)) = 0x7D*(\x3E+0x7E) = 0x7D*0xBC = 0x5BCC = 23500 參考資料： BIG-5E 碼 CCCII CCCII 用三個位元組(byte)表達一個中文字，每個位元組只用94個碼位， 因此它共有 94*94*94 = 830,584 個編碼空間。 CCCII 只使用於圖書館OPAC系統。 參考資料： CCCII 碼 CNS11643 中國國家標準(Chinese National Standard)， 又名中文標準交換碼 (Chinese Standard Interchange Code)， 公文交換系統，戶政系統，役政系統。 字集編排原則： CNS11643 用兩個位元組加上字面轉換符號表達一個中文字， 共分為十六個字面，每個字面可陳列94列 *94行， 即8,836個字符。第一至第十一字面為標準區， 第十二至第十六字面則為使用者加字區，供使用者暫編未收於標準區之字符。 所以編碼空間為 16*8836=14,1536。 參考資料： CNS11643 國家中文標準交換碼 Unicode / ISO 10646 參考資料： ISO10646及UNICODE 漢字集碼
甚麼是 ISO 10646 國際編碼標準
ISO 10646 @ HK 比較 下表是 堃(方方土) 出現在各種編碼的位置，漢字數以及編碼空間的比較。 | 編碼 | 堃(方方土) | 漢字數 | 編碼空間 |
|---|
| Big5: | None | 13461 | 19,782 | | Big5e: | 0x964F | Big5+3,954 | 23,500 | | Unicode(3.1): | 0x5803(22531) | 70,000+ | | | CNS11643: | plane 3, 0x3476(13430) | 48,027 | 141,536 | | CCCII: | | 53,940 | 830,584 | 如果要輸出 堃(方方土) 該怎麼做呢？ 自己建立造字區的檔案 如果不想看到 方方土 這樣子的東西，可以自己去造字， 然後將該字再需要使用的時後在匯入就可以了，不過缺點是缺多少字就必須造多少字， 另外造出來的字因為沒有統一的標準，所以無法與其他電腦溝通。 將字存為圖形 這是許多新聞網站的做法，將字存為圖形後，就可以不需要考慮使用者的電腦是否 可以產生 堃(方方土)。 Windows 的做法 在 Windows 2000 之後已經可以顯示 堃(方方土) 了，因為 Windows 2000 將系統用 Unicode 作為內碼核心，平常看到的字仍然是 Big5 編碼， 不過可以利用 堃 的方式在網頁中顯示這個字，只要你是 Windows 2000 之後的版本，並且新細明體是 Unicode 編碼的，並且包含這個字。 更換編碼為 Big5e 這在某種角度上是最省力的，因為相容於 Big5，這樣子的做法同等於將大家的造字區 進行統一而已，沒有使用 Big5e 的也只是某些字看不到。 只是推行 Big5e 有不少困難，例如：我們現在沒有 Big5e 的完整資料， 像是 Big5e <-> Unicode 的轉碼表，也缺少 Big5e 的 TTF 字型等。 更換編碼為大字集 在此大字集的定義為 CCCII、CNS11643、Unicode。 CCCII 多為圖書館在使用，CNS11643 則是戶政機關與役政機關使用， 而 Unicode 則通常作為交換碼。 換成大字集的最大阻力應該是社會的接受度。因為台灣長久以來都是使用 Big5，要換成其他字集要有許多的過渡方案，也需要有比較大的組織來推行。 更換為 Big5e 編碼的好處？ Big5e 擁有 eten 的字，相容於 CP950 與 Big5。 就寫程式的人而言，大多數的程式碼都不需要做變更。 就使用者而言，增加了許多可以用的字，減少了打字找不到字的問題。 更換為 Big5e 編碼的成本？ Big5e 的國際認同度 在目前的電腦系統中，都只有 Big5 編碼，不論是 Windows、Apple、FreeBSD、 Linux、Solaris 等，並沒有 Big5e 的存在，要讓這個編碼存在， 就必須讓這個編碼能通過編碼的審核，所以必須有人來重新的 Review 並且 Commit 給各個標準單位。 Big5e 與 Unicode 的轉碼 目前已經有轉碼表了。
轉碼表： http://freebsd.sinica.edu.tw/~statue/hanzi/BIG5E.TXT 缺乏字型支援 目前並沒有 Big5e 的專用字型，不過，Windows 目前的 TTF 是 ISO10646-1 的編碼，已經有蠻完整的 Big5e 字型可以使用，但是， 該 TTF 內並沒有 Big5e 的 MAP。而且，以市面上的字型而言， 都只支援 Big5，若要更換對社會成本來說影響頗大？ 缺乏輸入法支援 目前的輸入法都不支援 Big5e，這樣子就沒辦法輸入 Big5e 的字。 該怎麼推 Big5e 編碼？ 更新標準 先確定 Big5e 是否有遺珠之憾，目前已知的問題有：不支援日文假名， 日文假名的部分在 c6a0-c8fe，在 SPCFSUPP 的範圍內。 日文字的支援可能還需要與制定標準機關討論，看能不能將日文納入。 Big5e 編碼空間 1. 8E40 - 8E42：納編CNS11643第1字面的3個部首(原倚天定義之C6C2、C6C5、C6C6)。
2. 8E43 - A0FE：納編CNS1643第3字面的2,980個中文字。
3. 8140 - 86DF：納編CNS11643第3字面的911個中文字。
4. 86E0 - 875B：納編CNS11643第4字面的59個中文字。
5. 875C - 875C：國字零(Ｏ)。
以上使用區段都在使用者造字區內：第一段 FA40~FEFE，第二段 8E40~A0FE，第三段 8140~8DFE。 字型問題 建立 Big5e 的 TTF 與 BDF 字型。文鼎已經有 Big5e 的字型在販售。 或是想辦法在原有的字型上加 patch 得以支援 Big5e 的造字。 在 BDF 方面我可以幫忙 support，我已經用 Unicode TTF 做出了 Big5e 的 16x16 與 24x24 的字型，在測試上都沒問題。 不過在 TTF 方面因為沒研究過，所以還不知道該怎麼做。 另外還必須將 Big5e 的 locale 推廣開，locale 的改編應該也沒問題。 以下是測試的例子：
# cd /usr/X11R6/lib/X11/fonts/encodings/large/
# cp big5.eten-0.enc.gz big5.eten-0.enc.gz.bak
# gunzip big5.eten-0.enc.gz
# chmod 644 big5.eten-0.enc
# vim big5.eten-0.enc
0x964F 0x5803
# chmod 444 big5.eten-0.enc
# gzip big5.eten-0.enc
# cd /usr/X11R6/lib/X11/fonts/local
# fetch big5e.bdf
# mkfontdir
# crxvt -fm -freetype-fixed-medium-r-normal--17-160-75-75-p-151-big5-0
// 這裡的 -fm 是 big5e.bdf 的字型
# perl -e 'print "游錫".pack("CC", 0x96, 0x4F);'
 輸入法 將 Big5e 的新字加上輸入法規則。 問題 因為中文字集太大了，以 Big5e 編碼仍然會有漏網之魚， 當一個字不在 Big5e 中出現時，是否應該有解決的方法？ 還是放棄 Big5e 編碼？ 事實上 Big5e 的問題：編碼空間不足，是個非常嚴重的問題。 還有下列的問題：是否真的有需要多搞一個 Big-5e？真的哪麼多人會用嗎？真的 有人會去推廣嗎？真的可以說服國內外軟體商去花功夫實作嗎？然身為 自由軟體界開發者，我們是否真的想花時間實作這個可能不多人使用的標準呢？ （萬「碼」奔騰……搞 CNS 11643 好？ CCCII 好？ 還是什麼都不理， 等待 Big5 的退化，直至 Unicode 成為全域通用？但台灣當局究竟有什麼 明確的方向？） 那我們需要怎樣子的編碼呢？ 確認需求 中文漢字如此之多，為了不要有編碼空間的問題，我們必須選一個夠大的編碼， 如果能夠在一個編碼內同時顯示多國語言，這就得依賴編碼空間的足夠， 另外，還必須與國際組織合作，例如與 ISO 10646 組織合作， 並極力爭取確保需要的漢字能夠進入 Unicode。 必須由一個有力的組織來帶頭 香港在以前是使用 Big5，不過現在已經全面換成 Big5-HKSCS， 新增 4700 多個字符，而且絕大部分字符納入 Unicode/ISO 10646 裏。 技術上，Big5-HKSCS 頗相似 Big-5e，都是在 Big5 的 EUDC (造字區) 裏加字。不同的是： - BIG5-HKSCS 已經是國際公認的了
- Adobe 二年前已經為 PostScript/Acrobat 加了 HKSCS 的 CMap 和字型
- MS Windows 有支援 Big5-HKSCS
- Linux 有支援 Big5-HKSCS
- HKSCS 很多字是新增的，是香港政府採納各政府部門和市民的意見， 經語言學家檢查，遞交給 ISO 10646，是半年前才算大部份成為 ISO 標準。 (CJK Basic Area + Extension A + Extension B) Big-5e 裏的字其實一早已經在 ISO 10646 裏了。 (CJK Basic Area)
參考資訊： 香港資訊科技署 (ITSD) 介紹 HKSCS-2001 和 ISO 10646 香港的做法：Big5 -> BIG5-HKSCS -> ISO 10646。 中國大陸的做法：GB2312 -> GBK -> GB18030 -> GB13000 (等於 ISO 10646)。 GB2312 -> GBK -> GB18030 -> ISO 10646 的優點，是 GB18030 完全反向相容，不會有 CNS 11643 與 Big5 不合的缺點。 而 GB18030 更是為 Unicode 度身訂造，除了 GBK 原有的字符外， 其餘一律是可以直接計算出 Unicode 編碼的，也是一對一的映射。 系統的 Unicode 支援越完善，也就自然對 GB18030 支援更完善。 另外，大陸還強制執行 GB18030。 中國大陸一樣有「鎔」（中國大陸總理朱鎔基先生） 和「方方土」字在 GB2312 打不到的問題，而雖然 GBK 是多了字，但還不足夠。 有很多地名、人名、古籍等等，需要更多更多的漢字。現在這些漢字都已經納入 Unicode 裏了，中國大陸就以 GB18030 為 GB2312 -> Unicode 的移植方案。 從 GB2312/GBK 移至 GB18030，功夫可不太少啊！軟體商 (尤其是 Microsoft) 未必肯花功夫和金錢去實作 GB18030。 Microsoft 之前說會把 Big5+ 實作， 之後將之棄而不顧，Big5+ 胎死腹中，就是明證。中國堂堂大國，怎可以被美國 那家軟件商玩弄？新的 GB18030 編碼可是解決中國二十年來電腦漢字不夠用的 方案啊！中國大陸進入世貿、舉辦奧運、全國建立資訊產業，但連基本的中文編 碼還未搞好，那就糟了，所以實在是不能再等的了！ 所以強制規定，所有作業系統都必須支持 GB18030，否則休想在內地合法 銷售。我當初也覺得是專橫，但想深一層，想起 Big5+ 的收場，就暗暗讚嘆 內地政府的堅定決心。不錯， Microsoft Windows ME 是不能在內地發售的啊！ Microsoft 已經為 Windows 2000 和 Windows XP 加了 GB18030 的 patch 了。 是辛苦的了，字型也很昂貴，但 GB18030 是完完全全和將來的 Unicode 相容， 所以是一個「一勞永逸」的方案，也為將來 (十多年後？？) 實施 GB13000 (即 ISO 10646 / Unicode UTF-8 等) 鋪好了路。 那，我們政府當局的未來走向呢？ 結論 以筆者目前的感覺，我認為可行的方式應該是： Big5 -> Big5e -> ISO 10646 我會建議這樣子做原因如下，先建立一個類似 GBK 或是 Big5-HKSCS 的擴展機制， 將我們所急用的字符先編入，解決一時的需要，由於這樣子的編碼相容於 Big5， 舊有的系統只需要對字型作修正，以及一些相關修正， 這樣子的修正並不會耗費太多的力氣。 接著開始制定我們要從 Big5e 跨到 ISO 10646 這個大障礙的需求，由於這個部分耗時會比較久， 在轉換的過程上也可能不相容於之前的編碼，所以成本也可能會高出許多。 當然這樣子的結論對許多人都沒有辦法接受，因為現行的 CNS11643 以及 CCCII 的沒有提出相關的解決方案，也沒有確切的數據來評估 CNS11643 與 CCCII 對 ISO 10646 的相容性問題，這是我會繼續撰寫並討論的部分， 希望大家能多提供一些意見以供參考。
字元對應表 Windows 98 無此字
Windows 2000 之後提供 Unicode 輸入法，所以可以看到此字
Windows XP 新細明體
CNS11643 的查詢 
http://www.cns11643.gov.tw/web/s ... =3&number=13430
xfd 對 cns11643 的字型查詢
# cd /usr/ports/x11-fonts/intlfonts
# make install clean
# xset fp rehash
# xfd -start 13430 -rows 1 -columns 1 -fn "-cbs-song-medium-r-normal-fantizi-24-240-75-75-c-240-cns11643.1992-3"
| 
發表於 2006-9-12 04:55
| 
發表於 2009-7-13 00:07
|