常看很多人對「Unicode 補完計畫」都有意見，不是大力推薦、就是極力反對；但不管贊成或是反對的人，真的都瞭解它的原理嗎？都瞭解它產生的背景為何嗎？知道罪魁禍首其實是微軟的 Code Page 950 嗎？
系統字元編碼 (ASCII、Code Page)
很久很久以前，美國人做出電腦時只考慮了歐洲語系，沒考慮到東方語系的問題，所以當時採用的國別 Code Page 方法，編碼只有 8 bit (1 byte)，最多 255 個字。前面 127 個字元 (只用 7 bit) 是一些字母、符號和控制字元，相容 ASCII 標準；後面 127 個字元叫「高位元」(因為用到 8 bit)，則是按 Code Page 而不同。預設的是 Code Page 437，裏面有西歐語言字母和表格框線的符號。
東亞語言雙字元系統編碼 (DBCS)
之後，東亞地區也有很多人在使用電腦了，不可能一直只用英文字，於是各國就開始發展各國語言的編碼系統。因東亞文字數量太多，就採用兩個 byte 來組成文字，理論上最多可有 65535 個字 (實際上當然不可能有這麼多，因為低位元部分要保留給英文字母和符號，第一碼只能用高位元，否則到時像「at」這樣普通的英文字都被會轉成文字)。各國都出了各自的編碼，台灣香港 BIG5、日本 SJIS、中國 GB、韓國 KS 等。
例如在 BIG5 裏面「特」字的編碼是 AF53，表示由十六進位的 AF、53 兩碼組成。AF (175) 是「»」、53 (83) 是「R」；在中文模式下，只要發現這兩個字元組合在一起，系統就會將之轉成「特」字。但就因這原理，故常有一些英文軟體畫面的框線在中文模式下變成亂碼 (eg. C4C4C4C4「────」 會變成「闡闡」)。
而在 SJIS 裏面，AF53 是「ｯR」，在 GB 裏面是「瘲(的簡體)」也就是說，同樣的碼用不同的系統來看會是不同的字，除非該編碼內就有編入他國文字，否則無法同時顯示多個國家的文字。
BIG5
台灣在那時其實是「萬"碼"奔騰」，各公司都推出自己的中文編碼，沒有統一規範。後來資訊公會統一弄出了 BIG5 碼，使用到後來卻成了主流。當時 BIG5 編碼是非常急就章而推出的，選字根本就是依據教育部的常用字標準，所以很多字都沒被選入 (eg.堃、煊、喆) 但因變成主流，大家只好將就著用 (政府戶政、圖書管理等系統用不同的編碼，所以字數多很多)。
Unicode
後來有一群人/公司開始發展 Unicode，也就是將世界上主要的文字統一編碼，只要電腦支援該編碼、有相對應的字型，就可以看到所有文字。
它做出一個將世界上主要文字整理後按編號排列的列表，用 U+xxxx 來表示，原始是規劃使用兩個 byte，可編列 65535 個字，從 U+0000 ～ U+FFFF (這個範圍叫「Basic Multilingual Plane」)，但之後發現 65535 個字似乎不太夠用 (其中光是東亞文字就佔掉 3/4) 於是又增加了十六倍的編號位置，從 U+010000 ～ U+1000FD，只是其中很多部分都是保留用或還在規劃用途中。 (詳細的 Unicode 編號表)
不過，前述的 U+xxxx 只是編號方式 (專用術語叫「codepoint」)，實際的「編碼」有很多，目前常見的是 UTF-8、UTF-16、UTF-32 幾種：
UTF-8：
這個編碼方式的特色就是針對不同種類的字元使用不同的 byte 數，其中最大優點為原 ASCII 的資訊 (即使用 1 byte 的) 不必轉換就可以繼續使用，增加不少便利性：
Unicode 範圍 使用 byte 數 範例 字碼 Unicode 編號 UTF-8 編碼 U+0000 ～ U+007F 1 byte G U+0047 47 U+0080 ～ U+07FF 2 byte Я U+042F 042F U+0800 ～ U+FFFF 3 byte ＠ U+FF20 EFBCA0 U+010000 ～ U+10FFFF 4 byte U+20000 F0A08080
UTF16：
不像 UTF8 變動 byte 數，而是固定用 2 byte 對 U+0000 ～ U+FFFF 編碼 (但 U+010000 ～ U+10FFF 則用 4 byte 編碼)。目前為目前 Windows 等許多作業系統內部處理使用的編碼方式。分為好幾種排列方式：
排列方式 編碼範例 Я (U+042F) ＠ (U+FF20) Я＠ UTF-16LE (UTF-16 Little-Endian) 2F04 20FF 2F0420FF UTF-16BE (UTF-16 Big-Endian) 042F FF20 042FFF20 UTF-16LE 含 BOM (Byte Order Mark) FFFE2F0420FF UTF-16BE 含 BOM
FEFF042FFF20
UTF-32：
每個字元都固定用 4 byte 編碼：
排列方式 編碼範例 Я (U+042F) ＠ (U+FF20) Я＠ UTF-32LE (UTF-16 Little-Endian) 2F040000 FF200000 2F040000FF200000 UTF-32BE (UTF-16 Big-Endian) 0000042F 0000FF20 0000042F0000FF20 UTF-32LE 含 BOM (Byte Order Mark) FFFE00002F040000FF200000 UTF-32BE 含 BOM
0000FEFF0000042F0000FF20
其後，有人認為中文、日文、韓文、越南文中很多漢字其實都一樣或是差不多，所以推動 Unihan、CJKV，以將編入 unicode 中的漢字數量縮減。
以上都是講古，重點開始了
倚天中文
'80、'90 年代初，佔市場比例最大的是「倚天」的中文系統，倚天當時在 BIG5 保留的「造字區」放了一些部首、符號、日文假名、俄文字母。在 DOS 時代很常被使用者用到，累積了不少用到那些字的文件資料。
萬惡的淵藪、一切問題的起源：微軟
時代繼續發展，萬惡的微軟推出 Windows，將正體中文編為 Code Page 950，但是卻沒把前述造字區中的日文、俄文字母以及某些符號收進去！一直到 Windows Vista 出了，除了新增了歐元符號以外，還是沒日文字，這就是今天發生這個問題的起源！話說微軟放了幾個造字區的符號進正體中文 Code Page 950，但就是日文假名、俄文字母不收。簡體中文 CodePage 936 甚至連日製漢字、常用正體字都弄進去了，Code Page 950 卻是啥都缺。
在 Win95/98/ME 時代，使用者大多是以匯入 eudc、font.24 等使用造字區的方式來解決。到了 Win NT 之後，系統都採用 unicode 做內部處理，如果應用軟體也使用 unicode，那當然沒有問題，但是對於一些仍用以前 DBCS 編碼的軟體，Windows 就使用 codepage 轉換方式：
如圖左邊部份。也就是：從 DBCS 軟體貼到 unicode 的軟體時，系統會做內碼切換，反之亦然。
但是，在繁體中文的 CP 950 中並沒有日文假名，當然更沒有日製漢字。所以中文 Windows 下，不支援 unicode 的軟體碰到此類未對應的 unicode 字元時轉換會出問題，變成「?」或「_」，若檔名就有這種字元時，則連該檔案都無法開 (漢字部份則拜 CJKV 所賜，大多可以直接轉換)。
CP 932 (日文) unicode CP 950 (正體中文)
あ (82A0) <-> あ (U+3042) -> ?
Unicode 補完計畫 (Unicode at Once)
「Unicode 補完計畫」就是為了解決這問題而出現的 (當初它的名字叫「Big5 Extension」，意思就是擴充 BIG5 缺少的部分，結果改成現在名字後反而產生被人誤會的問題)。
它的做法：
如圖左邊部份。它修改「Unicode 對 Code Page 950 的轉換對照表」，使 Unicode 日文假名在非 Unicode 狀況下改去用原倚天的造字區編碼，甚至還增加對應 Unicode 日製漢字、簡體中文、特殊正體中文字 (也是用造字區)。
Unicode 補完計畫的問題點
由於對應的是 Code Page 950 沒有使用到的區域 (原 BIG5/倚天 的造字區)，因此不支援 Unicode 軟體弄出來的字，在未裝 UAO 的電腦上看時會是空白，使用者若沒注意到這點而大量用不支援 Unicode 的軟體處理檔案，結果就會發生慘案：
非 Unicode 軟體看到的是 BIG5 造字區的編碼、Unicode 軟體看到的 Unicode 造字區的編碼，但這兩者都要有裝 UAO 的電腦才能看到字。
目前不支援 Unicode 的軟體仍為數不少，或者用慣了的軟體不支援 Unicode、有支援的卻又功能不符合需求或用不慣。按人的惰性來看，只要還有這種情況，UAO 就仍會一直存在、就會有人去使用。畢竟在在東亞地區處理資訊，會用到日文的機會相當大，但微軟卻一直不將日文放入，也才會有 UAO 產生出來的契機。
如果真要使用 UAO，就必須時常注意軟體輸出的文字是否變成 BIG5 了，否則雖然自己電腦看得到，但傳出去在沒有 UAO 的電腦上看到的都是空白啊！
輸入字碼 在有 UAO 的系統 在無 UAO 的系統 支援 Unicode 的軟體 不支援 Unicode 的軟體 支援 Unicode 的軟體 不支援 Unicode 的軟體 Unicode あ (U+3042) あ (U+3042) あ (C6E8) あ (U+3042) ? Unicode (U+F6F8) あ (U+3042) あ (C6E8) (U+F6F8) あ (C6E8) BIG5 あ (C6E8) あ (U+3042) あ (C6E8) (U+F6F8) あ (C6E8) SJIS あ (82A0) あ (U+3042) あ (C6E8)
あ (82A0)あ (U+3042) ?
註：U+3042 才是 あ 的正式 Unicode 編碼
U+F6F8 是位於 Unicode 的造字區，通常沒有字型會去對應，會顯示空白
C6E8 是以前倚天的擴充字區裏面 あ 的編碼，即俗稱的「uao 日文」、「BIG5 日文」
參考資料：
全站熱搜
留言列表
旅遊健行 (4)
{{ article.title }}
