用JAVA轉換簡繁體的基礎知識 (轉)

用JAVA轉換簡繁體的基礎知識 (轉)[@more@]漢字編碼標準與識別(一) 

內碼表(Code Page)初識 


本節是根據以下文章編寫出來的，建議認真研讀這些專家的高論。 
參考1 <> 張 軸 材 
<>週報 97-1-17 
參考2 <> <>周 
報記者 黃偉敏 肖春江 99-8-30 
參考3 <> 吳健 <> 
出版日期：1998-12-21　總期號：348　本年期號：51 
參考4 <> 孫玉芳 <> 
出版日期：1998-07-06　總期號：323　本年期號：26 
參考5 CJK.INF:://ftp.ora.com/pub/examples/nut/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時是誰占主導地位。因為有些英文資 
料說是制訂了GBK，而國家方面也沒有進行說明。目前從 
這些參考資料只知道，94年ISO/IEC 10646釋出後，Microsoft開發 
95中文版，要制訂中文擴充套件編碼。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這兩個檔案有點瑕疵. 
//Gbk-big5.tab 
web/download/Gb-big5.tab 
web/gb2312.htm 
web/gbk.htm 
在使用這些轉換表製作其它標準的相互轉換表，會和傳統的轉換表 
有所不同。如用GBK<=>Unicode<=>BIG5製作GBK<=>BIG5轉換表，就 
會和傳統的GB<=>BIG5轉換表有所不同。主要是漢字有簡體和繁體。 
前者是GBK(中的繁體字)<=>BIG5(繁體字)，後者是GB(簡體)<=>BIG5(繁體)。 
還有就是對一些製表符選用不同。對漢字繁簡轉換有興趣的讀者，可以看 






內碼與字型的關係 

雖然沒有標準文字，但還是可以大致瞭解常用標準有那些字。TLC4.0的 
字型檔帶有GB2312，GB12345，BIG5，GBK標準的pcf字型。可以用xfd實用 
檢視。在下有一個16點陣的Unicode 
的pcf字型。如果了FreeType，可以使用xmbdfed檢視TTF字型。 
如果用MS ，可能會更簡單些。 
在日常使用中，我們實際上熟悉的是字碼(內碼).在中文下,我們輸 
入一個雙八位位元組,就得到一個漢字,就會認為這雙八位位元組就是對應這 
樣的字形.這是錯誤的.其實內碼對於字型檔來說,只是查詢字形的.如 
果換另一個編碼標準的字型，同一個字串就會呈現不同的字形，也就 
是亂碼。我見過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及後面的中文版就是採用這個方案。現 
有的X window的TTF，X-TT和xft也可以使用這個方案。 
前者在Turbo中文版裡得到了實現，後者我試驗過，效果還不錯。還有 
一個有趣的現象，就是紅旗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的資訊，看來這也是一個問題。