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

2019-11-18 11:50:56

字體：大中小

來源：轉載

供稿：網友

　　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。假如不是看了參考，我還不知道國家關于漢字編碼的標準如此之多。中國人居然要從英文資料里了解漢字編碼標準，實在是很無奈的事情。
　　常用中文編碼標準資料來源: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字體。可以用xfd實用程序查看。在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,也難也不難.簡單的地方是只需修改轉換表就行了(如windowsls*.*).難的是要升級字庫.開發字庫是很困難的,可以到方正字庫網站看看開發字庫的步驟.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)。用

上一篇：Java語言基礎五

下一篇：JAVA初學建議