<本文PDF文檔下載>

硬編碼的硬傷

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

補救

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

Windows的策略

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

Linux的策略

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

跨平臺策略

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

gettext策略

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

更多

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