<本文PDF文檔下載>

硬編碼的硬傷

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

補救

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

Windows的策略

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

Linux的策略

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

跨平臺策略

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

gettext策略

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

更多

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