漢字編碼標準與識別(一)

代碼頁(Code Page)初識


本節是根據以下文章編寫出來的，建議認真研讀這些專家的高論。
參考1 <> 張 軸 材 
<<計算機世界>>周報 97-1-17
參考2 <<張軸材 談漢字交換碼標準建立歷程>> <<計算機世界>>周
報記者 黃偉敏 肖春江 99-8-30
參考3 <<中文平臺把住“根”留住>> 吳健 <<中國計算機報>>
出版日期：1998-12-21　總期號：348　本年期號：51
參考4 <<為種種UNIX中文平臺號脈>> 孫玉芳 <<中國計算機用戶>>
出版日期：1998-07-06　總期號：323　本年期號：26
參考5 CJK.INF:ftp://ftp.ora.com/pub/examples/nutshell/ujip/
doc/cjk.inf

因為本人只是業余水平，不是專家，對于參考資料中許多術語還不
理解，更沒有見過任何一種標準的正式文本，錯誤和模糊之處再所
難免。同時，因為國家有關部門對于宣傳，推廣和貫徹國家標準方
面力度不夠，致使象我這樣的初學者或初涉該領域的小企業因信息
資源不足而處于不利的競爭地位。
ASCII制訂的時候，并沒有考慮對多語種，特別是對象中國漢字這樣
的象形文字的支持。為此后來又提出了不少解決方案，其中代碼頁
體系(ISO2022)是現在普遍實行的方案，而ISO10646/GB13000/Unicode
是今后發展的方向。
中國的漢字編碼標準GB2312是7bits標準，具體說是雙7位字節標準。
而ASCII是單7位字節標準,計算機怎么區分呢?一種是在第八位置"1",
提示計算機轉入雙字節編碼,這是最常見的一種實現,也叫EUC
(Extended Unix Code)編碼.另一種是用特殊標記提示計算機轉入雙
字節編碼,如HZ編碼就是用開始，用結束的塊標識雙字節編碼區.它們
都是GB2312的一種實現.對象中國漢字這樣的象形文字體系，代碼頁
是根據各個國家，地區或行業標準，按照EUC方式編碼。代碼頁向下
兼容ASCII，是一種不等長編碼。會帶來代碼的復雜性，同時還會引
起因代碼頁切換而帶來的亂碼問題。
Unicode是一種多字節等長編碼。ISO10646/GB13000/Unicode現已在
UCS2上實現一致，也就是已實現雙字節編碼標準。下面所討論的
ISO10646/GB13000/Unicode，就只是指UCS2這種情況。Unicode對
ASCII采取前面加"0"字節的策略實現等長兼容。如"A"的ASCII碼為0x41,
Unicode碼就為0x00,0x41。
這里主要從國家標準(GB)系列入手了解Unicode。如果不是看了參考5
(英文)，我還不知道國家關于漢字編碼的標準如此之多。中國人居然
要從英文資料里了解漢字編碼標準，實在是很無奈的事情。
常用中文編碼標準 資料來源:CJK.INF
GB2312-1980(GB0)(簡體) GB7589-1987(GB2)(簡體)
GB7590-1987(GB4)(簡體) GB13000-1993
GB6345.1-1986(GB0修正)
GB8565.2-1988(GB8,GB0擴充)
GB/T12345-90(GB1)(繁體) GB/T13131-9X(GB3)(繁體)
GB/T13132-9X(GB5)(繁體)


其中橫向表示字符集系列。縱向表示各個系列的發展標準。其中
GB2312是基本集，也就是目前最常用的標準。GB7589/GB7590是擴展
集，使用時可能不能和GB2312共存，需要切換使用。GB7589/GB7590
是按部件(部首)和筆順(筆畫)排列，但具體有什么字，怎么排列，
用在什么領域，不清楚。GB2312系列經過兩次修正和擴充，已和原
始的GB2312-1980標準有些不同(參考5)。因為沒有標準文本，不知
道正在使用的字體是屬于哪個標準。根據最新的Unicode3.0，國家
標準最新的是GB16500-95 ，更不知是哪個系列的了。ISO/IEC 10646
等同于GB13000-1993/JIS0221-1995/KSC5000-1995這些國家標準。
制訂的目標是包容各語種的文字，其中以漢字最多(Unicode2.0有
20902個漢字)。關于標準的特點可以看參考1，制訂過程中的風風
雨雨，可以看參考2�？傊�，這是一個我們國家參與并占主導地位
的國際標準。
GBK是GB2312向GB13000過渡的一個中間產物。它是GB2312的一次大
的擴展，編碼向下兼容GB2312的EUC編碼，字匯(字符集)和GB13000
相同，是GB2312的3倍。所以說GBK也包含BIG5，Shift-JIS，KSC的
字匯。注意只是包含字匯，而編碼與原始的標準是不同的。在具體
應用中，用GBK字體就可以同時顯示GB2312，BIG5，Shift-JIS，KSC
的字符串。但除了GB2312字符串，其它都要轉換(convert)。
因為語焉不詳，不清楚制訂GBK時是誰占主導地位。因為有些英文資
料說是Microsoft制訂了GBK，而國家方面也沒有進行說明。目前從
這些參考資料只知道，94年ISO/IEC 10646發布后，Microsoft開發
Windows95中文版，要制訂中文擴展編碼。96年《漢字擴展內碼規范》
GBK發布(參考1~3)。按標準發布比制定晚一年推算，這是95年的事。
Windows95及后續版本中文版支持GBK。
GB2312的EUC編碼范圍是第一字節0xA1~0xFE(實際只用到0xF7)，第
二字節0xA1~0xFE。GBK對此進行擴展。第一字節為0x81~0xFE，第二
字節分兩部分，一是0x40~0x7E，二是0x80~0xFE。其中和GB2312相
同的區域，字完全相同。擴展部分大概是按部件(部首)和筆順(筆畫)
從GB13000中取出再排列入GBK中。因此GBK并不是GB13000，雖然兩者
字匯相同，但編碼體系不同。一個是ISO2022系列不等長編碼，一個
是等長編碼，并且編碼區域也不同。注意到GBK實際上不是國家標準。
在此之前有一個GB2312基本集，在它之上是一個技術更先進的GB13000。
GBK只是一種過渡和擴展規范。所以在Unicode里有GB2312->Unicode,
GB12345->Unicode的轉換表格，而沒有GBK->Unicode轉換表格。只有
Microsoft制作的Code Page 936(CP936.TXT)可以算作GBK->Unicode
轉換表格。但要注意這是一個商業公司制作的文件，而不是國家或
國際標準組織制作的，有可能與標準有不一致的地方。最近在方正字
體網站發現一些有用的標準文件,有興趣可以下載看看.但要注意
Gbk-big5.tab和Gb-big5.tab這兩個文件有點瑕疵.
http://www.founderpku.com/fontweb/download/Gbk-big5.tab
http://www.founderpku.com/fontweb/download/Gb-big5.tab
http://www.founderpku.com/fontweb/gb2312.htm
http://www.founderpku.com/fontweb/gbk.htm
在使用這些轉換表制作其它標準的相互轉換表，會和傳統的轉換表
有所不同。如用GBK<=>Unicode<=>BIG5制作GBK<=>BIG5轉換表，就
會和傳統的GB<=>BIG5轉換表有所不同。主要是漢字有簡體和繁體。
前者是GBK(中的繁體字)<=>BIG5(繁體字)，后者是GB(簡體)<=>BIG5(繁體)。
還有就是對一些制表符選用不同。對漢字繁簡轉換有興趣的讀者，可以看
http://www.basistech.com/articles/c2c.html
http://www.cjk.org




內碼與字體的關系

雖然沒有標準文本，但還是可以大致了解常用標準有那些字。TLC4.0的
字庫帶有GB2312，GB12345，BIG5，GBK標準的pcf字體�？梢杂脁fd實用
程序查看。在http://www.debian.org/chinese下有一個16點陣的Unicode
的pcf字體。如果安裝了FreeType，可以使用xmbdfed軟件查看TTF字體。
如果用MS WORD，可能會更簡單些。
在日常使用中，我們實際上熟悉的是字碼(內碼).在中文WIN9X下,我們輸
入一個雙八位字節,就得到一個漢字,就會認為這雙八位字節就是對應這
樣的字形.這是錯誤的.其實內碼對于字庫來說,只是查找字形的索引.如
果換另一個編碼標準的字體，同一個字符串就會呈現不同的字形，也就
是亂碼。我見過GB2312,BIG5和ISO10646/GB13000的TTF字庫.對于操作系
統和應用程序來說,最喜歡的自然是ISO10646/GB13000的TTF字庫了.因為
這時只需提供一套代碼和一套字庫,修改外部配置文件,就可以用在不同的
語種環境.這就是國際化和本地化.其中有個技巧就是ISO10646/GB13000的
TTF字庫可以在使用時可以通過重映射變成其它標準的字庫.這時需要的是
GBK->Unicode,Big5->Unicode這些轉換表.一個系統要升級支持Unicode3.0,
也難也不難.簡單的地方是只需修改轉換表就行了(如windows
ls*.*).
難的是要升級字庫.開發字庫是很困難的,可以到方正字庫網站看看開發字
庫的步驟.WIN9X使用的是北京中易公司的TTF字庫,MS是不可能開發一套中
文字庫的.我所見過的ISO10646/GB13000的TTF字庫,最新的是99年版,Unicode2.1
,
方正字庫.要想見到Unicode3.0的所有字形,也只有等這些專業字庫開發商
做出來才行.如果現在就想看,只有問張軸材了.因為每通過一次新標準,中
國方面就要提供所有漢字的48x48高精密字形.使用TTF字體始終是誘人的話
題。但現在了解不多，只能簡單談談從TTF字體生成bdf/pcf字體的問題。
因為現在中文pcf字體很少，只有宋體，仿宋，黑體，楷體四種。要想有更
多的字體，有個取巧的方法就是使用freetype庫。用ttftobdf程序生成bdf
字體，再用bdftopcf程序生成pcf字體。但這種方法生成的字體縮放后比較
難看，而且不宜控制。這可能是ttf->bdf的轉換過程丟失了信息，高寬比
也和標準的不一樣。機器生成的東西就是機械，是不能和手繪的字體相比
的。同時，因為TTF技術已成熟，所以也沒有必要繼續開發更多的pcf字體。
X window將接受和大量使用TTF字體。而pcf字體今后主要用在標準字型
（如宋體），小點陣，網上快速下載傳輸方面。只有實際在X Window下用
過Unicode和TTF的字體，才會體會到使用Unicode和TTF，既是一種能力，
也是一種負擔。因為不論是什么格式的字體文件，最后在使用時都轉化為
內存里固定點陣字體。如果是16x16點陣，一個漢字就用32字節。Unicode3.0
有27786個漢字,至少需要868kb的內存。如果要中文英文美觀一致，還得裝
載大量的中文字體，所需內存可想而知。如果再使用TTF，還需要另一塊內
存來運算和存儲。因此，就算X Window提供了字體cache和deferglyphs，
還是于事無補。而我們常用的漢字其實很少。根據統計，常用漢字的頻率，
前165個漢字頻率和>50%，前1000個漢字頻率和>95%；按小學教學經驗，識
字900個左右，基本可以讀書，看報，寫作文；按小學教學大綱，小學畢業
識字2500字；GB2312的一級字庫的頻率和已>99%。我想我自己識字大約為
4000~5000，對比Unicode的漢字，好象一個文盲:-)。因此是用GB2312，還
是用GB13000，真是一個兩難決擇，我們也要為我們的選擇付出代價。
最后通過內碼與字體的關系，討論UTF8的作用。
UTF8是現有ASCII系統轉向Unicode系統的一個過渡解決方案。UTF8是保證
ASCII兼容性，再向大字符集方向擴展。這是Unicode推薦的方案。但是因
為解決問題的角度不同，對現有的中文系統不是好的解決方案。
CJK字符編碼標準目前都為一字/兩字節。中文在UCS2中的編碼范圍是
U+4E00~U+9FFFF。按照UTF8的編碼規則，為一字/三字節，增加1/3的空間。
同時和現有的CJK系統不兼容。CJK系統要使用UTF8，先轉換為UCS2，再轉換
為UTF8。后一步簡直是多此一舉。因為從字庫的角度看，字的編碼只是字形
在字庫中的索引。UTF8是變長碼，不能直接做索引，需要轉換為UCS2才能使
用字庫。
隨著GUI的發展，字庫逐漸轉向TTF。TTF字庫的編碼標準，有GB2312/GB2312
的EUC標準；BIG5標準；ISO10646標準。沒有見過UTF8的TTF，也不知道CJK
這些國家有哪些系統使用了UTF8編碼。
目前Unicodde有一個特點就是內核代碼(CoreCode)。用戶表面上可以繼續使
用原有的編碼標準，系統內部使用UCS2進行運算和操作。系統使用用戶可改
變的標志或模塊，以識別用戶需要的編碼標準，然后進行轉換。這樣，系統
只需提供一套ISO10646的TTF，不修改內部代碼，就可以為多個用戶同時提供
中文，日文，韓文的支持。Windows95及后面的中文版就是采用這個方案�，F
有的X window的TTF服務器，X-TT和xfsft也可以使用這個方案。
前者在TurboLinux中文版里得到了實現，后者我試驗過，效果還不錯。還有
一個有趣的現象，就是紅旗Linux1.1版所帶的那個12點陣的pcf字體
/usr/X11R6/lib/X11/fonts/misc/gb12st.pcf.gz。這已不是嚴格意義上的
GB2312編碼的字庫了。用xfd實用程序查看，好象是從Unicode編碼的TTF字體
轉換來的，有些GBK的字，可惜太少。如果他們能出些GBK編碼標準的pcf字體
就好了。
CJK系統轉向UCS2與ASCII系統轉向UTF8，兩者的代碼修改量是相當的。只是前

者多了轉換表，需要內存多些。不過ASCII系統使用UCS2，需要增加50%的空間。

目前計算機里大多數還是ASCII的信息，看來這也是一個問題。