UAO0.jpg

常看很多人對「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-8UTF-16、UTF-32 幾種:


UTF-8:

這個編碼方式的特色就是針對不同種類的字元使用不同的 byte 數,其中最大優點為原 ASCII 的資訊 (即使用 1 byte 的) 不必轉換就可以繼續使用,增加不少便利性:

Unicode 範圍使用 byte 數 範例
字碼Unicode 編號UTF-8 編碼
U+0000 ~ U+007F1 byteGU+004747
U+0080 ~ U+07FF2 byteЯU+042F042F
U+0800 ~ U+FFFF3 byteU+FF20EFBCA0
U+010000 ~ U+10FFFF4 byte U+20000F0A08080


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)2F0420FF2F0420FF
UTF-16BE (UTF-16 Big-Endian)042FFF20042FFF20
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)2F040000FF2000002F040000FF200000
UTF-32BE (UTF-16 Big-Endian)0000042F0000FF200000042F0000FF20
UTF-32LE 含 BOM (Byte Order Mark)  FFFE00002F040000FF200000
UTF-32BE 含 BOM
  0000FEFF0000042F0000FF20


其後,有人認為中文、日文、韓文、越南文中很多漢字其實都一樣或是差不多,所以推動 UnihanCJKV,以將編入 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 轉換方式:

UAO3.gif

如圖左邊部份。也就是:從 DBCS 軟體貼到 unicode 的軟體時,系統會做內碼切換,反之亦然。

但是,在繁體中文的 CP 950 中並沒有日文假名,當然更沒有日製漢字。所以中文 Windows 下,不支援 unicode 的軟體碰到此類未對應的 unicode 字元時轉換會出問題,變成「?」或「_」,若檔名就有這種字元時,則連該檔案都無法開 (漢字部份則拜 CJKV 所賜,大多可以直接轉換)。


CP 932 (日文)unicodeCP 950 (正體中文)
あ (82A0)<->あ (U+3042)->?


Unicode 補完計畫 (Unicode at Once)

Unicode 補完計畫」就是為了解決這問題而出現的 (當初它的名字叫「Big5 Extension」,意思就是擴充 BIG5 缺少的部分,結果改成現在名字後反而產生被人誤會的問題)。

它的做法:

UAO3.gif

如圖左邊部份。它修改「Unicode 對 Code Page 950 的轉換對照表」,使 Unicode 日文假名在非 Unicode 狀況下改去用原倚天的造字區編碼,甚至還增加對應 Unicode 日製漢字、簡體中文、特殊正體中文字 (也是用造字區)。


Unicode 補完計畫的問題點

由於對應的是 Code Page 950 沒有使用到的區域 (原 BIG5/倚天 的造字區),因此不支援 Unicode 軟體弄出來的字,在未裝 UAO 的電腦上看時會是空白,使用者若沒注意到這點而大量用不支援 Unicode 的軟體處理檔案,結果就會發生慘案:

UAO1.gif UAO2.gif

非 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 日文」



參考資料:



Wayne Su 發表在 痞客邦 PIXNET 留言(3) 人氣()


留言列表 (3)

發表留言
  • jims
  • 你好~目前在處理造字問題~看到你這篇收穫頗豐~想請問主計處的全字庫編準跟你提到的unicode有關聯嗎?
  • CNS11634 是中華民國的國家標準,在 unicode 還沒推出時就已經制訂了,用在編「中文字」 (unicode 的宗旨則是放入「全世界的各種文字」)。

    詳細可以閱讀官方網站的說明:
    http://www.cns11643.gov.tw/AIDB/encodings.do

    Wayne Su 於 2011/03/03 13:37 回覆

  • jims Hsu
  • 這網頁我看了後有個疑問~
    他在CNS11643與Unicode對應表
    http://www.cns11643.gov.tw/AIDB/statistics.do
    最後一欄"沒有對應到Unicode之字數"是0
    這是代表Unicode已經收錄這些字集了嗎?

    會注意到這個是因為我的mysql是用Unicode編碼處理
    兒我目前遇到了很多生物名字的特殊字,這些字網頁顯示不出來
    我的理解是網頁Unicode沒收錄,所以我無意間找到CNS網站
    看了後有點搞不清楚CNS的角色與Unicode的關係
    假如我跟CNS申請造字或是CNS裡頭有,但是網頁顯示不出來的字之後會不會有機會可以在網頁顯示?


  • 首先要瞭解,unicode 並不負責「編碼」,他們只是統整出全世界文字並訂出順序。實際編碼是採用 uft8、utf16 等實做方法;但大致上編碼都會依照 unicode 的順序來。(上面有大概做粗淺解釋)

    而 CNS11643 除了編列中文字外還有實做編碼,而且有自己的排序方式、跟 unicode 排的順序並不一定一樣。因此 CNS11643 編碼的資料要經轉碼後才能在一般電腦上看 (市面電腦通常是用 utf16、utf8 編碼)。可參考這個網站整理的比較:
    http://code.web.idv.hk/cns11643/cns11643.php
    (個人建議是除非你一直要和政府機關打交道,不然不要按 CNS11643 去做,還是按國際比較常用的標準來走。)

    你的狀況我推測問題應該是在於字形。要在電腦上顯示文字,電腦使用的字形有支援才行。目前市面上大多字形能完全支援 plane 0 已經算很優秀了,更別說之後才擴充的其他字。

    以 WinXP 裏原附的「細明體/新細明體」為例,只支援 plane 0 裏面的中文,(也就是那個比較表裏「對應到Unicode第0字面碼位之字數」這欄),其他的中文字可能都會變成裏面有內碼的方框,也就是你說的「顯示不出來」。

    微軟後來有釋出可以支援到 extB 區段的更新字形 (也就是比較表中「對應到Unicode第2字面碼位之字數」這欄內的一部分),但被評字形改得看不習慣,所以官方網站沒再讓人下載,在私人網站還能找到:
    http://briian.com/?p=5097

    你可以先用這個網站大致看一下哪些字會顯示不出來:
    http://zh.wikibooks.org/wiki/Unicode/0000-0FFF

    再到這個網站,有圖形可顯示大致上該字元會是什麼字:
    http://www.decodeunicode.org/

    Wayne Su 於 2011/03/03 15:34 回覆

  • jims Hsu
  • 我想我面臨的問題應該是大部分使用者系統的字型可能都只支援到plane 0,
    (不確定非中文系統的OS是如何的狀況?)
    即使某些特殊字已經編進了unicode,但因為字型沒支援的原因,網頁上看不到字,

    所以簡單說CNS是中華民國的中文字標準,這些字同時也會對應到unicode


    真是非常感謝!!!
    我終於搞懂了~~




  • 目前 Vista、Win7 附的字形應該都能完全支援 plane 0 了 (試過中文版、日文版,微軟都有更新字形版本),有特殊需求的人才會再去找支援擴充字集的字形來用。

    在 XP 時代,英文版 OS 好像要另外開啟「東亞語言檔案」選項才會安裝中日韓語系的字形、輸入法。而 Ubuntu Linux 桌面版則是預設會載入許多國家的字型 (阿拉伯、印度、泰文、中文、波斯...etc);但根據我推測,應該也是支援到 plane 0 而已。

    至於 CNS11643,就把他當成「中華民國的中文內碼標準」吧,政府機關都規定公文交換要用那個,戶政機關也是用那個,但一般民間當然還是繼續用 unicode (utf8、utf16)。至於說「對應嘛」.. 不如說是「unicode 有編入的中文字在 CNS11643 也有、反之亦然」,也就是兩者可以互相轉碼使用。

    至於官方為何不直接使用 unicode ? 因為官方認為沒必要為了很少用的他國語言而浪費編碼空間啊,省下的空間可以放更多中文字。日本、中國、韓國也是這樣,在 unicode 出現後仍繼續推行自己的編碼法;但一樣的,民間仍是在使用 unicode...

    Wayne Su 於 2012/06/01 13:05 回覆

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼