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