※ 來源:·BBS 水木清華站 smth.org·[FROM: 162.105.10.32]
代碼頁(Code Page)初識
本節(jié)是根據(jù)以下文章編寫出來的，建議認真研讀這些專家的高論。
參考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
因為本人只是業(yè)余水平，不是專家，對于參考資料中許多術語還不理解，更沒有見過任何一種標準的正式文本，錯誤和模糊之處再所難免。同時，因為國家有關部門對于宣傳，推廣和貫徹國家標準方面力度不夠，致使象我這樣的初學者或初涉該領域的小企業(yè)因信息資源不足而處于不利的競爭地位。
ASCII制訂的時候，并沒有考慮對多語種，特別是對象中國漢字這樣的象形文字的支持。為此后來又提出了不少解決方案，其中代碼頁體系(ISO2022)是現(xiàn)在普遍實行的方案，而ISO106/GB13000/Unicode是今后發(fā)展的方向。
中國的漢字編碼標準GB2312是7bits標準，具體說是雙7位字節(jié)標準。而ASCII是單7位字節(jié)標準,計算機怎么區(qū)分呢?一種是在第八位置"1",提示計算機轉入雙字節(jié)編碼,這是最常見的一種實現(xiàn),也叫EUC(Extended Unix Code)編碼.另一種是用特殊標記提示計算機轉入雙字節(jié)編碼,如HZ編碼就是用開始，用結束的塊標識雙字節(jié)編碼區(qū).它們都是GB2312的一種實現(xiàn).對象中國漢字這樣的象形文字體系，代碼頁是根據(jù)各個國家，地區(qū)或行業(yè)標準，按照EUC方式編碼。代碼頁向下兼容ASCII，是一種不等長編碼。會帶來代碼的復雜性，同時還會引起因代碼頁切換而帶來的亂碼問題。
Unicode是一種多字節(jié)等長編碼。ISO106/GB13000/Unicode現(xiàn)已在UCS2上實現(xiàn)一致，也就是已實現(xiàn)雙字節(jié)編碼標準。下面所討論的ISO106/GB13000/Unicode，就只是指UCS2這種情況。Unicode對ASCII采取前面加"0"字節(jié)的策略實現(xiàn)等長兼容。如"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)(繁體)
其中橫向表示字符集系列。縱向表示各個系列的發(fā)展標準。其中GB2312是基本集，也就是目前最常用的標準。GB7589/GB7590是擴展集，使用時可能不能和GB2312共存，需要切換使用。GB7589/GB7590是按部件(部首)和筆順(筆畫)排列，但具體有什么字，怎么排列，用在什么領域，不清楚。GB2312系列經(jīng)過兩次修正和擴充，已和原始的GB2312-1980標準有些不同(參考5)。因為沒有標準文本，不知道正在使用的字體是屬于哪個標準。根據(jù)最新的Unicode3.0，國家標準最新的是GB16500-95 ，更不知是哪個系列的了。ISO/IEC 106等同于GB13000-1993/JIS0221-1995/KSC5000-1995這些國家標準。制訂的目標是包容各語種的文字，其中以漢字最多(Unicode2.0有20902個漢字)。關于標準的特點可以看參考1，制訂過程中的風風雨雨，可以看參考2?？傊?，這是一個我們國家參與并占主導地位的國際標準。
GBK是GB2312向GB13000過渡的一個中間產(chǎn)物。它是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 106發(fā)布后，Microsoft開發(fā)Windows95中文版，要制訂中文擴展編碼。96年《漢字擴展內碼規(guī)范》GBK發(fā)布(參考1~3)。按標準發(fā)布比制定晚一年推算，這是95年的事。Windows95及后續(xù)版本中文版支持GBK。
GB2312的EUC編碼范圍是第一字節(jié)0xA1~0xFE(實際只用到0xF7)，第二字節(jié)0xA1~0xFE。GBK對此進行擴展。第一字節(jié)為0x81~0xFE，第二字節(jié)分兩部分，一是0x40~0x7E，二是0x80~0xFE。其中和GB2312相同的區(qū)域，字完全相同。擴展部分大概是按部件(部首)和筆順(筆畫)從GB13000中取出再排列入GBK中。因此GBK并不是GB13000，雖然兩者字匯相同，但編碼體系不同。一個是ISO2022系列不等長編碼，一個是等長編碼，并且編碼區(qū)域也不同。注意到GBK實際上不是國家標準。在此之前有一個GB2312基本集，在它之上是一個技術更先進的GB13000。GBK只是一種過渡和擴展規(guī)范。所以在Unicode里有GB2312->Unicode,GB12345->Unicode的轉換表格，而沒有GBK->Unicode轉換表格。只有Microsoft制作的Code Page 936(CP936.TXT)可以算作GBK->Unicode轉換表格。但要注意這是一個商業(yè)公司制作的文件，而不是國家或國際標準組織制作的，有可能與標準有不一致的地方。最近在方正字體網(wǎng)站發(fā)現(xiàn)一些有用的標準文件,有興趣可以下載看看.但要注意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
在使用這些轉換表制作其它標準的相互轉換表，會和傳統(tǒng)的轉換表有所不同。如用GBK<=>Unicode<=>BIG5制作GBK<=>BIG5轉換表，就會和傳統(tǒng)的GB<=>BIG5轉換表有所不同。主要是漢字有簡體和繁體。前者是GBK(中的繁體字)<=>BIG5(繁體字)，后者是GB(簡體)<=>BIG5(繁體)。還有就是對一些制表符選用不同。對漢字繁簡轉換有興趣的讀者，可以看
http://www.basistech.com/articles/c2c.html
http://www.cjk.org
//**********************************
內碼與字體的關系
雖然沒有標準文本，但還是可以大致了解常用標準有那些字。TLC4.0的字庫帶有GB2312，GB12345，BIG5，GBK標準的pcf字體。可以用xfd實用程序查看。在http://www.debian.org/chinese下有一個16點陣的Unicode的pcf字體。如果安裝了FreeType，可以使用xmbdfed軟件查看TTF字體。如果用MS WORD，可能會更簡單些。
在日常使用中，我們實際上熟悉的是字碼(內碼).在中文WIN9X下,我們輸入一個雙八位字節(jié),就得到一個漢字,就會認為這雙八位字節(jié)就是對應這樣的字形.這是錯誤的.其實內碼對于字庫來說,只是查找字形的索引.如果換另一個編碼標準的字體，同一個字符串就會呈現(xiàn)不同的字形，也就是亂碼。我見過GB2312,BIG5和ISO106/GB13000的TTF字庫.對于操作系統(tǒng)和應用程序來說,最喜歡的自然是ISO106/GB13000的TTF字庫了.因為這時只需提供一套代碼和一套字庫,修改外部配置文件,就可以用在不同的語種環(huán)境.這就是國際化和本地化.其中有個技巧就是ISO106/GB13000的TTF字庫可以在使用時可以通過重映射變成其它標準的字庫.這時需要的是GBK->Unicode,Big5->Unicode這些轉換表.一個系統(tǒng)要升級支持Unicode3.0,也難也不難.簡單的地方是只需修改轉換表就行了(如\windows\nls*.*).難的是要升級字庫.開發(fā)字庫是很困難的,可以到方正字庫網(wǎng)站看看開發(fā)字庫的步驟.WIN9X使用的是北京中易公司的TTF字庫,MS是不可能開發(fā)一套中文字庫的.我所見過的ISO106/GB13000的TTF字庫,最新的是99年版,Unicode2.1,方正字庫.要想見到Unicode3.0的所有字形,也只有等這些專業(yè)字庫開發(fā)商做出來才行.如果現(xiàn)在就想看,只有問張軸材了.因為每通過一次新標準,中國方面就要提供所有漢字的48x48高精密字形.使用TTF字體始終是誘人的話題。但現(xiàn)在了解不多，只能簡單談談從TTF字體生成bdf/pcf字體的問題。因為現(xiàn)在中文pcf字體很少，只有宋體，仿宋，黑體，楷體四種。要想有更多的字體，有個取巧的方法就是使用freetype庫。用ttftobdf程序生成bdf字體，再用bdftopcf程序生成pcf字體。但這種方法生成的字體縮放后比較難看，而且不宜控制。這可能是ttf->bdf的轉換過程丟失了信息，高寬比也和標準的不一樣。機器生成的東西就是機械，是不能和手繪的字體相比的。同時，因為TTF技術已成熟，所以也沒有必要繼續(xù)開發(fā)更多的pcf字體。X window將接受和大量使用TTF字體。而pcf字體今后主要用在標準字型（如宋體），小點陣，網(wǎng)上快速下載傳輸方面。只有實際在X Window下用過Unicode和TTF的字體，才會體會到使用Unicode和TTF，既是一種能力，也是一種負擔。因為不論是什么格式的字體文件，最后在使用時都轉化為內存里固定點陣字體。如果是16x16點陣，一個漢字就用32字節(jié)。Unicode3.0有27786個漢字,至少需要868kb的內存。如果要中文英文美觀一致，還得裝載大量的中文字體，所需內存可想而知。如果再使用TTF，還需要另一塊內存來運算和存儲。因此，就算X Window提供了字體cache和deferglyphs，還是于事無補。而我們常用的漢字其實很少。根據(jù)統(tǒng)計，常用漢字的頻率，前165個漢字頻率和>50%，前1000個漢字頻率和>95%；按小學教學經(jīng)驗，識字900個左右，基本可以讀書，看報，寫作文；按小學教學大綱，小學畢業(yè)識字2500字；GB2312的一級字庫的頻率和已>99%。我想我自己識字大約為4000~5000，對比Unicode的漢字，好象一個文盲:-)。因此是用GB2312，還是用GB13000，真是一個兩難決擇，我們也要為我們的選擇付出代價。最后通過內碼與字體的關系，討論UTF8的作用。
UTF8是現(xiàn)有ASCII系統(tǒng)轉向Unicode系統(tǒng)的一個過渡解決方案。UTF8是保證ASCII兼容性，再向大字符集方向擴展。這是Unicode推薦的方案。但是因為解決問題的角度不同，對現(xiàn)有的中文系統(tǒng)不是好的解決方案。
CJK字符編碼標準目前都為一字/兩字節(jié)。中文在UCS2中的編碼范圍是U+4E00~U+9FFFF。按照UTF8的編碼規(guī)則，為一字/三字節(jié)，增加1/3的空間。同時和現(xiàn)有的CJK系統(tǒng)不兼容。CJK系統(tǒng)要使用UTF8，先轉換為UCS2，再轉換為UTF8。后一步簡直是多此一舉。因為從字庫的角度看，字的編碼只是字形在字庫中的索引。UTF8是變長碼，不能直接做索引，需要轉換為UCS2才能使用字庫。
隨著GUI的發(fā)展，字庫逐漸轉向TTF。TTF字庫的編碼標準，有GB2312/GB2312的EUC標準；BIG5標準；ISO106標準。沒有見過UTF8的TTF，也不知道CJK這些國家有哪些系統(tǒng)使用了UTF8編碼。
目前Unicodde有一個特點就是內核代碼(CoreCode)。用戶表面上可以繼續(xù)使用原有的編碼標準，系統(tǒng)內部使用UCS2進行運算和操作。系統(tǒng)使用用戶可改變的標志或模塊，以識別用戶需要的編碼標準，然后進行轉換。這樣，系統(tǒng)只需提供一套ISO106的TTF，不修改內部代碼，就可以為多個用戶同時提供中文，日文，韓文的支持。Windows95及后面的中文版就是采用這個方案?，F(xiàn)有的X window的TTF服務器，X-TT和xfsft也可以使用這個方案。
前者在TurboLinux中文版里得到了實現(xiàn)，后者我試驗過，效果還不錯。還有一個有趣的現(xiàn)象，就是紅旗Linux1.1版所帶的那個12點陣的pcf字體/usr/X11R6/lib/X11/fonts/misc/gb12st.pcf.gz。這已不是嚴格意義上的GB2312編碼的字庫了。用xfd實用程序查看，好象是從Unicode編碼的TTF字體轉換來的，有些GBK的字，可惜太少。如果他們能出些GBK編碼標準的pcf字體就好了。
CJK系統(tǒng)轉向UCS2與ASCII系統(tǒng)轉向UTF8，兩者的代碼修改量是相當?shù)?。只是前者多了轉換表，需要內存多些。不過ASCII系統(tǒng)使用UCS2，需要增加50%的空間。目前計算機里大多數(shù)還是ASCII的信息，看來這也是一個問題。
//*************************************
內碼轉換表的來源與制作
由于歷史和地域的原因，電腦里的中文標準有不少種共存于Internet中。這是現(xiàn)實。因此出現(xiàn)了內碼轉換。這方面的程序現(xiàn)在有不少。不過大多是MS Windows的版本，并且有的毛病不少，所以有必要制作一個完整些的內碼轉換表。
資料來源
自從Unicode/ISO106/GB13000標準出現(xiàn)后，這項工作變得簡單和繁瑣。因此制作轉換表時有一個準則：以國際和國家標準為基準，參考有影響的商業(yè)公司的轉換表，個人和小軟件次之。下面是資料的來源：
一)國際和國家標準組織國際標準組織Unicode(http://www.unicode.org)提供了
GB<=>Unicode轉換表:
ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/GB
BIG5<=>Unicode轉換表:
ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/OTHER
JIS<=>Unicode轉換表:
ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/JIS
KSC<=>Unicode轉換表:
ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/KSC
因為GBK不是國家標準，所以Unicode并沒有提供GBK<=>Unicode的轉換表，而只是采用了Microsoft的code page的一個版本:
ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP{936,950}.TXT
中國國家標準網(wǎng)入門太難，須8000元/個人。因此沒有得到正式的GB2312-1980和GB13000-1993的標準。
二)商業(yè)公司
2.1 方正集團字體部
http://www.founderpku.com/fontweb/
因為方正是產(chǎn)，學，研的綜合體，在排版和字體領域奮斗多年，有很特殊的地位。他們提供的轉換表，幾乎可以等同國家標準。
GB2312標準:
http://www.founderpku.com/fontweb/gb2312.htm
GBK標準:
http://www.founderpku.com/fontweb/gbk.htm
GB<=>BIG5轉換表:
http://www.founderpku.com/fontweb/download/Gb-big5.tab
GBK<=>BIG5轉換表:
http://www.founderpku.com/fontweb/download/Gbk-big5.tab
2.2 Microsoft
http://www.microsoft.com/
Microsoft是誰也忽略不了的。有時候就算是他們錯了，最后也是對的。在有些英文資料里把GBK說成是Microsoft制訂的。Microsoft從商業(yè)角度出發(fā)，提供的是code pages：
GBK字形表:
http://www.microsoft.com/typography/unicode/936gif.zip
GBK<=>Unicode轉換表:
http://www.microsoft.com/typography/unicode/936.txt
BIG5字形表:
http://www.microsoft.com/typography/unicode/950gif.zip
BIG5<=>Unicode轉換表:
http://www.microsoft.com/typography/unicode/950.txt
在Windows97/98中文版里也提供了些資料：
GBK標準:\windows\GBK.txt
code pages:\windows\system\cp{932,936,949,950}.nls
三)個人與共享軟件
有不少個人和小團體也在這方面進行了探索。
3.1 TextPro http://person.zj.cninfo.net/~buddha
因為他們特殊的需求，TextPro確實在BIG5=>GBK/GB轉換方面有獨到之處。同時還有個GBK(繁體)=>GB(簡體)轉換表，很有特色。因為繁體=>簡體是多對一的映射，因此很難有簡體=>繁體的轉換表。特別是基于字到字的映射的轉換是不可能的。目前已有人進行基于詞典和上下文的詞到詞的映射。有興趣可以看
http://www.basistech.com/articles/c2c.html
3.2 Stone Chi http://stonec.yeah.net
提供了基于RichWin的內碼轉換表。收集了不少的資料，對內碼標準有較深的了解。同時還有一個中文檢索軟件值得一嘗。
3.3 NJStar http://www.njstar.com 和MagicWin http://www.magicwin.com.my
他們在這領域有些日子了。不過轉換表不是很全。
制作
根據(jù)上面的準則和排列次序制作。如果上一級有空白，就要下一級填補；如果有沖突，就以上一級的為準。
一)根據(jù)Unicode的GB<=>Unicode與BIG5<=>Unicode轉換表制作GB<=>BIG5轉換表。
二)根據(jù)Microsoft的GBK<=>Unicode與BIG5<=>Unicode轉換表制作GBK<=>BIG5轉換表。
至此，基于標準的轉換實際已經(jīng)完成。Unicode的特點就是一字一碼，一碼一字。各個國家和地區(qū)的漢字標準已編入Unicode的，并有相同的Unicode碼的漢字，就是叫CJK認同漢字。但有些漢字因為種種原因而未能得到認同，如果制作這些漢字的轉換表，只能是基于實用的，有可能多對多映射的轉換表。
三)使用方正的GBK<=>BIG5轉換表填充(一)的GB<=>BIG5轉換表。
四)使用Microsoft的GBK<=>BIG5轉換表填充(三)的GBK<=>BIG5轉換表。
五)使用TextPro和stonec的GBK<=>BIG5轉換表填充(四)的GBK<=>BIG5轉換表。
六)NJStar的轉換表雖然不是很全，但在BIG5=>GBK轉換表中的C6行后半段和C7，C8行卻相當完整。上面的轉換表在這里不是空白就是很少轉換。可能這個區(qū)域是屬于擴充符號區(qū)，可有可無。為保險起見，使用NJStar填充這個區(qū)域。
七)校驗。通過電腦對碼表進行校驗，發(fā)現(xiàn)在漢字編碼方面基本一致。有沖突的地方基本上是對制表符的理解不同造成的。
八)目測校驗。也就是用肉眼一個字一個字的檢查。這是最重要的一步。但因為學識和精力有限，未能做到這一步。
//***************************************
漢字編碼識別
因為歷史和地域原因，漢字有不少編碼標準。最常見的是GB2312和BIG5。在Unicode被完全接受前，他們將共存相當長的一段時間。因此在實際應用中有必要把它們區(qū)分顯示。這就是編碼識別。
現(xiàn)在在Windows平臺下有不少軟件可以識別和同屏顯示GB2312和BIG5字符串，已相當準確。但因為其中蘊藏著不小的商機，這些算法都不公開。現(xiàn)在只見兩種算法：
1)算法1 http://www.mandarintools.com
2)算法2 http://202.38.128.58/~yumj/www/chrecog.html
具體的原理可以看發(fā)明人的主頁。因為這兩種算法是通過大量的文章統(tǒng)計出來的，而實際應用是一行行的識別。所以有必要對短句和詞組的有效性進行驗證。這里用了一個取巧的方法，分析對常用詞組的識別率。因為句子大多由這些有意義的詞組組成。因為兩岸不但編碼不同，習慣用語也不同。所以分別收集了GB詞組1.3MB，BIG5詞組900KB。通過對比發(fā)現(xiàn)一些有趣的事情。
1)算法1占用內存大些，速度慢些，但識別率高些，并且穩(wěn)定.誤差為8.6%，算法2正好相反，誤差為17.6%。綜合兩者可以提高一些識別率。
兩種算法的識別率
算法1 算法2 綜合
GB文件 5% 2.6% 0.7%
BIG5文件 3.6% 15% 5%
2)算法2提到的平均值184的閾值確實存在。但最好的算法不是作者所說的第二字節(jié)算法。而是第一字節(jié)和第二字節(jié)相加的算法。用三種算法分析GB詞組，都呈正態(tài)分布：第一字節(jié)算法峰值在195，坡度陡峭，說明平均值集中。第二字節(jié)算法峰值在207，坡度平緩，說明平均值分散。雙字節(jié)相加算法介于兩者之間。
分析BIG5詞組：
第一字節(jié)算法有峰值174，但坡度平緩得多。
第二字節(jié)算法有峰值160左右，更平緩,呈矩形分布，也就是BIG5常用詞組的第二字節(jié)的編碼范圍分布比較均勻。
雙字節(jié)相加算法是兩者的迭加。
所以較好的算法是：
flag = (a * c1 + c2) / (a + 1) (a = 5 ~ 7為佳)
以184為界，GB詞組有5%的詞的平均值小于184，BIG5詞組有15%的詞的平均值大于184，綜合誤差為17.6%。也就是說，對于GB碼的字符串，算法2不易錯判，對于BIG5碼的字符串則相反。如果是GB文件轉換為BIG5碼,誤差要低些,為15%,好象是GB碼的編碼和用字比較集中些.
3)算法1識別率提高的可能
GB2312標準的漢字有6763個，BIG5還要多些。而算法1只取600個字進行加權，似乎少了些。加權系數(shù)從1~600規(guī)則排列，似乎不能反映字頻變化的規(guī)律。對于GB2312，按常用的2:8的規(guī)律，應選1200字左右；按小學教學大綱，小學畢業(yè)識字2500字；按小學教學經(jīng)驗，識字900個左右，基本可以讀書，看報，寫作文。因此，這加權范圍應該在900~1000字左右。但選哪些字，字頻多少，應該是我們的語言文字專家發(fā)言的時候了。
4)新的可能算法
兩岸漢字編碼不同，常用語也不同，那么常用詞組也不同。因此從常用詞組分析差別更大，識別率也就更高?？上]有資料，因此現(xiàn)在只有設想，沒有算法。同時希望更多的人本著GPL大集市的精神，提供更多更好的算法。
- 作者： easthero 2005年08月22日, 星期一 19:25
