<本文PDF文檔下載>

硬編碼的硬傷

我們現(xiàn)在知道，C/C++的寬窄轉(zhuǎn)換是依賴系統(tǒng)的locale的，并且在運(yùn)行時(shí)完成?？紤]這樣一種情況，我們?cè)诤?jiǎn)體中文Windows下編譯如下語(yǔ)句：
const char* s = "中文abc";
根據(jù)我們之前的討論，編譯器將按照Windows Codepage936（GB2312）對(duì)這個(gè)字符串進(jìn)行編碼。如果我們?cè)诔绦蛑羞\(yùn)行寬窄轉(zhuǎn)換函數(shù)，將s轉(zhuǎn)換為寬字符串ws，如果這個(gè)程序運(yùn)行在簡(jiǎn)體中文環(huán)境下是沒問題的，將執(zhí)行從GB2312到UCS-2BE的轉(zhuǎn)換；但是，如果在其他語(yǔ)言環(huán)境下，比如是繁體中文BIG5，程序?qū)⒏鶕?jù)系統(tǒng)的locale執(zhí)行從BIG5到UCS-2BE的轉(zhuǎn)換，這顯然就出現(xiàn)了錯(cuò)誤。

補(bǔ)救

有沒有補(bǔ)救這個(gè)問題的辦法呢？一個(gè)解決方案就是執(zhí)行不依賴locale的寬窄轉(zhuǎn)換。實(shí)際上，這就已經(jīng)不是寬窄轉(zhuǎn)換之間的問題了，而是編碼之間轉(zhuǎn)換的問題了。我們可以用GNU的libiconv實(shí)現(xiàn)任意編碼間的轉(zhuǎn)換，對(duì)于以上的具體情況，指明是從GB2312到UCS-2BE就不會(huì)出錯(cuò)。（請(qǐng)參考本人前面的章節(jié)：win32下的libiconv），但這顯然是一個(gè)笨拙的策略：我們?cè)诤?jiǎn)體中文Windows下必須使用GB2312到UCS-2BE版本的寬窄轉(zhuǎn)換函數(shù)；到了BIG5環(huán)境下，就必須重新寫從BIG5到UCS-2BE的寬窄轉(zhuǎn)換函數(shù)。

Windows的策略

Windows的策略是淘汰了窄字符串，干脆只用寬字符串。所有的硬編碼全部加上特定宏，比如TEXT()，如果程序是所謂Unicode編譯，在編譯時(shí)就翻譯為UCS2-BE——Windows自稱為Unicode編程，其本質(zhì)是使用了UCS-2BE的16位寬字符串。

Linux的策略

Linux下根本就不存在這個(gè)問題！因?yàn)楦鞣N語(yǔ)言的Linux都使用UTF-8的編碼，所以，無論系統(tǒng)locale如何變化，窄到寬轉(zhuǎn)換的規(guī)則一直是UTF-8到UTF32-BE 。

跨平臺(tái)策略

因?yàn)樵?6位的范圍內(nèi)，UTF32-BE的前16位為0，后16位與UCS2-BE是一樣的，所以，即使wchar_t的sizeof()不一樣，在一般情況下，跨平臺(tái)使用寬字符（串）也應(yīng)該是兼容的。但是依然存在潛在的問題，就是那些4字節(jié)的UTF32編碼。

gettext策略

以上都是將ASCII及以外的編碼硬編碼在程序中的辦法。GNU的gettext提供了另外一種選擇：在程序中只硬編碼ASCII，多語(yǔ)言支持由gettext函數(shù)庫(kù)在運(yùn)行時(shí)加載。（對(duì)gettext的介紹請(qǐng)參考本人前面的章節(jié)：Win32下的GetText）。gettext的多語(yǔ)言翻譯文件不在程序中，而是單獨(dú)的提出來放在特定的位置。gettext明確的知道這些翻譯文件的編碼，所以可以準(zhǔn)確的告訴給系統(tǒng)翻譯的正確信息，而系統(tǒng)將這些信息以當(dāng)前的系統(tǒng)locale編碼成窄字符串反饋給程序。例如，在簡(jiǎn)體中文Windows中，gettext的po文件也可以以UTF-8儲(chǔ)存，gettext將po文件翻譯成mo文件，確保mo文件在任何系統(tǒng)和語(yǔ)言環(huán)境下都能夠正確翻譯。在運(yùn)行是傳給win32程序的窄串符合當(dāng)前l(fā)ocale，是GB2312。gettext讓國(guó)際化的翻譯更加的方便，缺點(diǎn)是目前我沒找到支持寬字符串的版本（據(jù)說是有ugettext()支持寬字符串），所以要使用gettext只能使用窄字符串。但是gettext可以轉(zhuǎn)換到寬字符串，而且不會(huì)出現(xiàn)寬窄轉(zhuǎn)換的問題，因?yàn)間ettext是運(yùn)行時(shí)根據(jù)locale翻譯的。例如：
const char* s = gettext("Chinese a b c");
其中"Chinese a b c"在po中的翻譯是"中文abc"
使用依賴locale的運(yùn)行時(shí)寬窄轉(zhuǎn)換函數(shù)：
const std::wstring wstr = s2ws(s);
運(yùn)行時(shí)調(diào)用該po文件對(duì)應(yīng)的mo文件，在簡(jiǎn)體中文環(huán)境下就以GB2312傳給程序，在繁體中文中就以BIG5傳給程序，這樣s2ws()總能夠正常換算編碼。

更多

在本文的最后，我想回到C++的stream問題上。用fstream轉(zhuǎn)換如此的簡(jiǎn)單，sstream卻不支持。改造一個(gè)支持codecvt的string stream需要改造basic_stringbuf。basic_stringbuf和basic_filebuf都派生自basic_streambuf，所不同的是basic_filebuf在構(gòu)造和open()的時(shí)候調(diào)用了codecvt，只需要在basic_stringbuf中添加這個(gè)功能就可以了。說起來容易，實(shí)際上是需要重新改造一個(gè)STL模板，盡管這些模板源代碼都是在標(biāo)準(zhǔn)庫(kù)頭文件中現(xiàn)成的，但是我還是水平有限，沒有去深究了。另外一個(gè)思路是構(gòu)建一個(gè)基于內(nèi)存映射的虛擬文件，這個(gè)框架在boost的iostreams庫(kù)中，有興趣的朋友可以深入的研究。
（完）