|
之所以會(huì)有此感嘆，并非覺得GB18030的編碼框架有什么不妥，而是對該標(biāo)準(zhǔn)在實(shí)際應(yīng)用中遇到的尷尬情形的一些個(gè)人看法。 疑惑一：GB18030到底是一種ANSI編碼還是Unicode編碼？ 
既然是ANSI編碼，那么在實(shí)際的系統(tǒng)中，它就應(yīng)該是作為一種本地化的編碼字符集出現(xiàn)的。比如在Windows里面，它就應(yīng)該像GBK、Big5這些 ANSI編碼那樣，有自己的代碼頁和相應(yīng)的代碼頁屬性（主要指引導(dǎo)字節(jié)和尾隨字節(jié)的取值范圍）。對于代碼頁，微軟已經(jīng)給出了答案：Win2k以上的操作系統(tǒng)只要安裝了微軟的GB18030-2000擴(kuò)展支持包，就可以支持GB18020-2000編碼標(biāo)準(zhǔn)的54936代碼頁了。我在安裝了18030支持包之后，根據(jù)微軟給出的測試建議，寫了個(gè)調(diào)用API函數(shù)IsValidCodePage(54936)的小程序，測試結(jié)果是54936代碼頁可用（未安裝 18030支持包以前，測試54936代碼頁不可用）。 但僅僅是某個(gè)代碼頁可用并不表示文本處理程序就可以處理基于該代碼頁編碼的文本了，還必須把這個(gè)代碼頁設(shè)為系統(tǒng)的當(dāng)前代碼頁才行。可是，18030擴(kuò)展包不是自帶了一個(gè)GB18030?Unicode的文本編碼轉(zhuǎn)換程序的嘛，這個(gè)程序并不需要把系統(tǒng)的當(dāng)前代碼頁設(shè)為54936就可以工作呀。其實(shí)，關(guān)于這一點(diǎn)花點(diǎn)時(shí)間想一下也很簡單：文本文件的內(nèi)碼轉(zhuǎn)換其實(shí)根本不需要操作系統(tǒng)的支持，這種轉(zhuǎn)碼工作在計(jì)算機(jī)文本處理任務(wù)中來說算是最簡單的了――說得極端一點(diǎn)，只要有轉(zhuǎn)碼表，我們甚至可以寫一個(gè)在DOS下運(yùn)行的GB18030?Unicode 轉(zhuǎn)碼程序，如果省去中文界面的話，這個(gè)程序連中文系統(tǒng)都不用加載。在現(xiàn)實(shí)應(yīng)用中，文本處理工作遠(yuǎn)不只轉(zhuǎn)碼這一項(xiàng)，就拿日常用得比較多的文本編輯來說吧―― 假設(shè)有一款以ANSI方式來處理文本的字處理軟件，如果想要在這個(gè)軟件中正確顯示和編輯GB18030編碼的文本的話，首先就應(yīng)該把系統(tǒng)的當(dāng)前代碼頁設(shè)為 54936才行。這是因?yàn)榇鞧BK的936代碼頁的屬性和代表GB18030的54936代碼頁的屬性有很大的不同，在936代碼頁下，ANSI程序是無法正確處理GB18030編碼的文本的。 那么把系統(tǒng)的當(dāng)前代碼頁設(shè)為54936不就好了嗎？可是事情好像并沒有那么簡單……在編程時(shí)，通過調(diào)用API函數(shù)GetACP可以獲得系統(tǒng)當(dāng)前的代碼頁，可是Win32 API里面并沒有對應(yīng)提供一個(gè)類似"SetACP"這樣的設(shè)置當(dāng)前代碼頁的函數(shù)。事實(shí)上即使是Windows自己，也沒有辦法直接改變系統(tǒng)當(dāng)前的代碼頁， 改變當(dāng)前代碼頁的方法是在控制面板中設(shè)置區(qū)域和語言選項(xiàng)，然后重啟才能生效。Windows區(qū)域和語言選項(xiàng)里面的"非Unicode程序語言版本"設(shè)置對 于普通電腦用戶來說就是為那些只能處理特定語言的程序（ANSI文本處理程序）指定一個(gè)正確的，默認(rèn)可以處理的語言種類（比如是中文、日文或韓文）；而對 于開發(fā)ANSI文本處理程序的程序員來說，其實(shí)就是設(shè)置系統(tǒng)當(dāng)前的代碼頁。比如要設(shè)置950代碼頁的時(shí)候，選"中文(臺(tái)灣)"，要設(shè)置936代碼頁的時(shí)候，就選"中文(中國)"。可是讓人難以理解的是，在安裝了18030支持包以后，"代碼頁轉(zhuǎn)換表"里面已經(jīng)顯示"54936(GB18030 簡體中文)"代碼頁是可用使用的了。但在"非Unicode程序語言版本"列表里面，卻沒有相應(yīng)地提供一個(gè)類似"中文(中國GB18030)"這樣的選項(xiàng)，也就是說：Windows根本就沒有提供給我們把代表GB18030編碼標(biāo)準(zhǔn)的54936代碼頁設(shè)為系統(tǒng)當(dāng)前代碼頁的選擇。難道微軟并不認(rèn)為 GB18030是一種ANSI編碼，不需要相應(yīng)的代碼頁支持？可是這個(gè)結(jié)論顯然跟微軟提供了54936這個(gè)代碼頁是相矛盾的，因?yàn)榇a頁本身就是處理不同本地化語言的一種機(jī)制，生來就是為ANSI編碼而設(shè)的。而且18030支持包里面的ReadMe文檔也透露了它附帶的轉(zhuǎn)碼程序其實(shí)是調(diào)用了API函數(shù) MultiByteToWideChar和WideCharToMultiByte來實(shí)現(xiàn)的（否則無法解釋這個(gè)程序怎么會(huì)只有區(qū)區(qū)25KB之小），這就是說微軟確實(shí)是把GB18030當(dāng)作一種多字節(jié)的ANSI編碼來看待的。可是現(xiàn)在這個(gè)編碼的代碼頁卻根本不能設(shè)置為系統(tǒng)的當(dāng)前代碼頁！這恐怕在 Windows所支持的所有代碼頁里面，是唯一的一個(gè)吧。 疑惑二：54936代碼頁的真相？既然CP54936在所有的代碼頁中顯得如此之特殊，這不得不讓人產(chǎn)生了一窺其具體技術(shù)細(xì)節(jié)的欲望。我們知道：對于代碼頁機(jī)制來說，不同代碼頁間的主要區(qū)別在于各個(gè)位置上的字節(jié)取值范圍的不同。比如 CP936的引導(dǎo)字節(jié)范圍在0x81-0xFE之間，尾隨字節(jié)范圍在0x40-0x7E或0x80-0xFE之間；CP932的引導(dǎo)字節(jié)范圍在 0x81-0x9F或0xE0-0xFC之間，尾隨字節(jié)范圍在0x40-0xFC（0x7F除外）之間。顯然CP936和CP932有 很大的不同，這種不同成了系統(tǒng)在當(dāng)前代碼頁下，區(qū)分哪些是有效編碼（字符）和無效編碼（字符）的依據(jù)。言歸正傳，雖然Windows需要重啟才能改變當(dāng)前 代碼頁，但要查看某個(gè)代碼頁的信息卻不用那么麻煩。在任意一個(gè)代碼頁下，隨時(shí)都可以用API函數(shù)GetCPInfo讀出包括當(dāng)前代碼頁在內(nèi)的所有系統(tǒng)支持 的代碼頁的屬性信息。我們先用最熟悉的CP936試看看，測試結(jié)果GetCPInfo返回的信息如下：MaxCharSize=2；LeadByte= {81,FE,00,00,00,00,00,00,00,00,00,00}。這個(gè)結(jié)果的意思是說：CP936的字符最大編碼長度是兩個(gè)字節(jié)，它的引導(dǎo)字節(jié)有一個(gè)取值范圍：0x81-0xFE。顯然GetCPInfo(936)返回的信息跟我們所了解的GBK編碼標(biāo)準(zhǔn)的技術(shù)框架是符合的。接下來看看我們所關(guān)心的CP54936的情況，測試結(jié)果GetCPInfo返回的信息如下：MaxCharSize=4；LeadByte= {00,00,00,00,00,00,00,00,00,00,00,00}。按照Windows代碼頁機(jī)制的說法，這個(gè)結(jié)果意味著CP54936沒有引導(dǎo)字節(jié)取值范圍的定義，而這種情況通常只有單字節(jié)ANSI編碼才會(huì)出現(xiàn)。難怪Windows沒有提供把54936設(shè)為系統(tǒng)當(dāng)前代碼頁的選項(xiàng)了，因?yàn)榧词拱袰P54936設(shè)為當(dāng)前代碼頁，那些ANSI字處理程序（也就是非Unicode程序）也是無法顯示和編輯GB18030編碼的文本的。這一點(diǎn)可以很容易地從Windows的代碼頁技術(shù)原理上分析得到：CP54936沒有定義引導(dǎo)字節(jié)的取值范圍，但它本身又是一種ANSI編碼的代碼頁，所以當(dāng)系統(tǒng)運(yùn)行在這個(gè)代碼頁下的時(shí)候，實(shí)際上等于是運(yùn)行在單字節(jié)ANSI編碼的代碼頁下面。這樣一來，當(dāng)我們試圖在ANSI程序里面顯示一個(gè)四字節(jié)編碼的GB18030字符的時(shí)候，系統(tǒng)會(huì)毫不客氣地把它識(shí)別為無效編碼（字符），實(shí)際顯示出來的就是一堆的問號(hào)了。這是因?yàn)閱巫止?jié)ANSI編碼的每個(gè)字節(jié)取值都不會(huì)超過0x7F 的，而GB18030的四字節(jié)編碼的第一、三個(gè)字節(jié)的取值都在0x81以上，根據(jù)Windows代碼頁的技術(shù)規(guī)則，當(dāng)然會(huì)被判定為無效編碼（字符）了。 注：Windows 的代碼頁技術(shù)原理并不難理解。系統(tǒng)里面對應(yīng)不同的代碼頁存儲(chǔ)了不同的代碼頁屬性――包括這個(gè)代碼頁所代表的編碼標(biāo)準(zhǔn)的最大字符存儲(chǔ)長 度（單位：字節(jié)）；引導(dǎo)字節(jié)取值范圍；尾隨字節(jié)取值范圍（這個(gè)是隱藏的，用GetCPInfo函數(shù)是得不到它的，但它確實(shí)存在，看來微軟還是習(xí)慣性地留了 一手）。系統(tǒng)存儲(chǔ)這些代碼頁屬性最主要的目的就是用來判斷某個(gè)給定的字符串里面是否包含有不符合當(dāng)前代碼頁編碼框架的字符（編碼），當(dāng)然這種判定是對于那 些準(zhǔn)備要送去給程序中需要顯示在用戶界面上的字符串（文本）而言的。對于發(fā)生在計(jì)算機(jī)內(nèi)部（內(nèi)存）里面的文本處理過程（比如文本文件的內(nèi)碼轉(zhuǎn)換），是不需 要進(jìn)行這種判斷的。這也就是為什么說文本文件的轉(zhuǎn)碼不需要特定系統(tǒng)的支持的原因。系統(tǒng)判斷有效編碼（字符）和無效編碼（字符）的過程是這樣的：順序讀取字 符串中每個(gè)字節(jié)值，如果出現(xiàn)一個(gè)取值不在當(dāng)前代碼頁屬性許可的取值范圍（比如在單字節(jié)代碼頁中出現(xiàn)大于0x7F的字節(jié)）內(nèi)的字節(jié)的話，那么這個(gè)字節(jié)所屬的字符就是無效字符，在軟件界面上就會(huì)被顯示為問號(hào)。對于雙字節(jié)編碼的代碼頁（Windows支持的代碼頁都是單字節(jié)或雙字節(jié)代碼頁，只有CP54936是四字節(jié)這個(gè)例外），如果讀出的某個(gè)字節(jié)值小于等于0x7F,就說明它是一個(gè)單字節(jié)字符；如果讀出的字節(jié)值大于0x7F， 就把它當(dāng)成引導(dǎo)字節(jié)處理，看看這個(gè)字節(jié)值是否在當(dāng)前代碼頁指定的引導(dǎo)字節(jié)取值范圍內(nèi)，以及它的下一個(gè)字節(jié)值是否在當(dāng)前代碼頁指定的尾隨字節(jié)取值范圍內(nèi)。如 果這兩個(gè)條件都成立，說明當(dāng)前讀到的這個(gè)字節(jié)和它的下一個(gè)字節(jié)組成了一個(gè)有效的雙字節(jié)字符，否則當(dāng)前字節(jié)值判為無效編碼，顯示為問號(hào)。 上述這個(gè)判定過程是真實(shí)存在的，完整的編碼有效性判定工作需要引導(dǎo)字節(jié)取值范圍和尾隨字節(jié)取值范圍兩個(gè)基本信息的支持。只是不知道微軟出于什么原因，只 開放了引導(dǎo)字節(jié)取值范圍，但從Windows在文本處理上的一些行為中，是可以發(fā)現(xiàn)尾隨字節(jié)取值范圍信息是肯定存在的。比如，在簡體中文系統(tǒng)下（CP936）寫一個(gè)ANSI的小程序：這個(gè)程序的界面包括一個(gè)Edit控件和一個(gè)Button控件（兩個(gè)控件的字體屬性已經(jīng)設(shè)置成了"宋體－18030"），編寫B(tài)utton控件的鼠標(biāo)單擊過程實(shí)現(xiàn)把一個(gè)編碼字節(jié)值序列為<82 34 84 34>的ANSI字符串賦值給那個(gè)Edit控件讓它顯示"䢎"（0x82348434是CJK ExtA漢字"䢎"的GB18030編碼）這個(gè)字的功能。做這個(gè)實(shí)驗(yàn)程序的目的是要測試在CP936代碼頁下，ANSI程序是否能支持GB18030編碼字符的顯示和編輯。該程序的運(yùn)行結(jié)果是，按下Button按鈕之后，Edit編輯框里面并沒有如希望的那樣顯示"䢎"，而是??。顯然Windows認(rèn)為在當(dāng)前代碼頁（CP936）下面，0x82348434是兩個(gè)非法字符。因?yàn)檫@個(gè)編碼字節(jié)序列由四個(gè)字節(jié)組成，當(dāng)系統(tǒng)讀出第一個(gè)字節(jié)0x82的時(shí)候，因?yàn)檫@個(gè)字節(jié)值大于0x7F，所以需要判斷它和下一個(gè)字節(jié)0x34能否組成一個(gè)雙字節(jié)字符，而由于0x34不在GBK尾隨字節(jié)取值范圍之內(nèi)，所以第一和第二字節(jié)被判定為無效編碼；而第三字節(jié)的0x84和第四字節(jié)的0x34也是一樣的。所以這四個(gè)字節(jié)組成的編碼序列被判定為兩個(gè)無效字符，在軟件界面（Edit控件）上被顯示成了兩個(gè)問號(hào)。系統(tǒng)的這一處理結(jié)果反映了尾隨字節(jié)取值范圍信息的真實(shí)存在，否則很難想象它怎么會(huì)把0x8234判斷為無效字符。因?yàn)楦鶕?jù)雙字節(jié)ANSI編碼框架的一般規(guī)則：組成雙字節(jié)字符的前后兩個(gè)字節(jié)中，第一個(gè)字節(jié)必須大于0x7F以便文本處理程序把這個(gè)字節(jié)和單字節(jié)字符編碼區(qū)分開來。而對第二個(gè)字節(jié)的取值范圍并不作特別的規(guī)定，可以是任意取值范圍（包括小于等于0x7F的ASCII編碼值范圍）。如果系統(tǒng)中沒有存儲(chǔ)GBK尾隨字節(jié)取值范圍定義的話，由于第一個(gè)字節(jié)0x82已經(jīng)符合GBK引導(dǎo)字節(jié)取值范圍的要求了，第二個(gè)字節(jié)不管取什么值都應(yīng)該判定這兩個(gè)字節(jié)組成的字符是有效的雙字節(jié)字符。而事實(shí)是Windows準(zhǔn)確地判斷出了0x8234不符合GBK的雙字節(jié)編碼框架，這只能說明它是清楚地知道GBK的尾隨字節(jié)取值范圍定義的。 實(shí)驗(yàn)分析到這里，結(jié)論已經(jīng)很明顯了：在目前正式發(fā)行的Windows操作系統(tǒng)，包括微軟聲稱能支持GB18030的Win2k、WinXP和Win2003 中，即使安裝了GB18030-2000擴(kuò)展支持包，也不能真正使這些系統(tǒng)支持GB18030編 碼標(biāo)準(zhǔn)。因?yàn)榈览碓俸唵尾贿^了，程序員根本就沒有辦法編寫出能在這些系統(tǒng)下顯示和編輯GB18030-2000四字節(jié)編碼文本的ANSI文本處理程序。不 是很清楚這些系統(tǒng)是怎么通過GB18030-2000的標(biāo)準(zhǔn)符合性測試的。因?yàn)檫@些產(chǎn)品并不完全符合其中的"體系正確性：產(chǎn)品必須能夠正確識(shí)別和處理按照 國家標(biāo)準(zhǔn)GB 18030進(jìn)行編碼的文本文件。"這項(xiàng)要求。而微軟提供的GB18030支持包充其量只是提供了一個(gè)字體和幾個(gè)修改過的字符編碼轉(zhuǎn)換API函數(shù)，以及一個(gè)無法使用的CP54936，最后用一個(gè)其實(shí)跟系統(tǒng)支不支持GB18030標(biāo)準(zhǔn)并沒有關(guān)系的內(nèi)碼轉(zhuǎn)換小程序就蒙混過關(guān)了。 為什么 GB18030制定出來已經(jīng)6年 了，卻一直沒有得到有效的應(yīng)用？為什么我們大部分的應(yīng)用程序還只能停留在處理GBK字符集的階段？為什么當(dāng)我們很多公民在電腦中錄入自己包含生僻字的姓名 時(shí)仍然只能用×來代替？其實(shí)這并不怪GB18030-2000的編碼技術(shù)框架不好，而是相關(guān)部門在推廣應(yīng)用該標(biāo)準(zhǔn)上虎頭蛇尾的態(tài)度造成的。單以編碼框架而 言，雖然一直被很多人視為Unicode/ISO10646的中國版（實(shí)際上也是）。但技術(shù)上還是有它自己獨(dú)到之處的，即使它的四字節(jié)編碼框架跟傳統(tǒng)的單 /雙字節(jié)ANSI編碼相比顯得不是那么的標(biāo)準(zhǔn)，但還不至于另類到無法處理的地步。個(gè)人認(rèn)為它的四字節(jié)編碼格式跟UTF-16編碼格式的代理對機(jī)制在處理思想上很有些相似之處，從應(yīng)用層來說，單獨(dú)某款軟件要識(shí)別和處理這種單、雙、四字節(jié)混合編碼并不困難。但要把這些技術(shù)融入到整個(gè)操作系統(tǒng)之中，并不是簡單地修改幾個(gè)API就能完成的，單是把Win32 API里面所有有關(guān)Ansi字符串處理的函數(shù)列出來就夠嚇人一跳的了。因?yàn)槲④洸豢赡軉螢榱艘粋�(gè)GB18030放棄其他的ANSI編碼標(biāo)準(zhǔn)，加入對 GB18030的 支持必須是確保兼容原有的代碼頁機(jī)制的前提下才能實(shí)施的。而要保證這一點(diǎn)，就必須對幾乎所有的字符串處理API進(jìn)行一定的修改。總之以當(dāng)年的情形，微軟是 很難在短時(shí)間之內(nèi)拿出完整的解決方案的。政府壓得急，微軟草草地拿出了個(gè)換湯不換藥的支持包應(yīng)付了事，沒想到還真通過了。也不知道政府是不是真的不清楚這 個(gè)支持包的底細(xì)，反正自從這場"GB18030-2000標(biāo)準(zhǔn)之爭"以微軟推出擴(kuò)展支持包這個(gè)皆大歡喜的體面方式收場之后，雙方好像就沒把推廣應(yīng)用這回事 放心上了。幾年中就一直任由應(yīng)用層面上這種不尷不尬的局面持續(xù)下來，把一班滿心期待迎接GB18030時(shí)代卻又不明就里的中國應(yīng)用開發(fā)人員撩在了一邊。這些人在經(jīng)過了幾次徒勞的嘗試之后，終于還是放棄了支持GB18030標(biāo)準(zhǔn)的念頭，要么退回到GBK的小窩，要么踏上了Unicode未知的前程。總之在大家看來結(jié)論都是一樣的：對于Windows，GB18030是不可用的。 新版的GB18030-2005已經(jīng)出來了，雖然尚未有幸一睹標(biāo)準(zhǔn)原文真容，但希望它不會(huì)步GB18030-2000的后塵。落 個(gè)不尷不尬的局面吧，因然從長遠(yuǎn)來說主流肯定是Unicode，但短期內(nèi)仍然還是ANSI和Unicode并存的局面。像GB18030這種本地化版本的 Unicode還是需要的。希望它的應(yīng)用價(jià)值不要被再度埋沒了。雖然這不是我這種小人物的努力就可以決定的。（cnBeta） |
