在C++下處理Unicode字符串的最佳多平臺方式是什麼？

Question

我知道關於std::string與std::wstring或類似的StackOverflow已經存在幾個問題，但他們都沒有提出完整的解決方案。

爲了獲得一個很好的答案，我應該明確要求：

• 多使用，必須在Windows，Mac OS X和Linux工作
• 最小的努力爲轉換到/從特定平臺Unicode字符串像CFStringRef,wchar_t *,char*爲UTF-8或其他類型，因爲它們是OS API所需的。備註：我不需要代碼頁轉換支持，因爲我希望在所有支持的操作系統上只使用Unicode兼容功能。
• 如果需要一個外部庫，這個應該是開源並且在一個非常自由的許可下，如BSD但不是LGPL。
• 能夠使用printf格式語法或類似。
• 簡單的字符串分配/釋放方式
• 性能並不是非常重要，因爲我認爲Unicode字符串僅用於應用程序UI。
• 一些例子可能將不勝​​感激

我真的很感激，只有一個每答案提出的解決方案，這樣做的人會投票給他們的首選替代品。如果您有多個替代方案，請添加其他答案。

請指出確實爲你工作的東西。

相關問題：

• stdwstring-vs-stdstring
• does-c0x-support-stdwstring-conversion-to-from-utf-8-byte-sequence
• portable-wchart-in-c

Answer 1

同亞當·羅森菲爾德回答（+1），但我用UTFCPP代替。

Answer 2

我會強烈建議使用UTF-8內部在你的應用程序，使用普通的舊char*或std::string用於數據存儲。爲了與使用不同編碼（ASCII，UTF-16等）的API接口，我建議使用libiconv，它是根據LGPL許可的。

用法示例：

class TempWstring 
{ 
public: 
    TempWstring(const char *str) 
    { 
    assert(sUTF8toUTF16 != (iconv_t)-1); 
    size_t inBytesLeft = strlen(str); 
    size_t outBytesLeft = 2 * (inBytesLeft + 1); // worst case 
    mStr = new char[outBytesLeft]; 
    char *outBuf = mStr; 
    int result = iconv(sUTF8toUTF16, &str, &inBytesLeft, &outBuf, &outBytesLeft); 
    assert(result == 0 && inBytesLeft == 0); 
    } 

    ~TempWstring() 
    { 
    delete [] mStr; 
    } 

    const wchar_t *Str() const { return (wchar_t *)mStr; } 

    static void Init() 
    { 
    sUTF8toUTF16 = iconv_open("UTF-16LE", "UTF-8"); 
    assert(sUTF8toUTF16 != (iconv_t)-1); 
    } 

    static void Shutdown() 
    { 
    int err = iconv_close(sUTF8toUTF16); 
    assert(err == 0); 
    } 

private: 
    char *mStr; 

    static iconv_t sUTF8toUTF16; 
}; 

iconv_t TempWstring::sUTF8toUTF16 = (iconv_t)-1; 

// At program startup: 
TempWstring::Init(); 

// At program termination: 
TempWstring::Shutdown(); 

// Now, to convert a UTF-8 string to a UTF-16 string, just do this: 
TempWstring x("Entr\xc3\xa9""e"); // "Entrée" 
const wchar_t *ws = x.Str(); // valid until x goes out of scope 

// A less contrived example: 
HWND hwnd = CreateWindowW(L"class name", 
          TempWstring("UTF-8 window title").Str(), 
          dwStyle, x, y, width, height, parent, menu, hInstance, lpParam); 

Answer 3

我最近在一個項目中決定使用std :: wstring作爲跨平臺項目，因爲「寬字符串是Unicode的，對不對？」這導致了一些令人頭痛的問題：

• wstring中的標量值有多大？答：這取決於編譯器的實現。在Visual Studio（Win）中，它是16位。但在Xcode（Mac）中，它是32位。
• 這導致了一個不幸的決定通過線路使用UTF-16進行通信。但是，哪個UTF-16？有兩種：UTF-16BE（big-endian）和UTF16-LE（小端）。不清楚這導致更多的錯誤。

當您處於平臺特定的代碼中時，使用平臺的本機表示與其API進行通信是有意義的。但對於跨平臺共享的任何代碼，或平臺之間的通信，請避免模糊不清，並使用UTF-8。

Answer 4

經驗法則：使用用於處理的本地平臺的Unicode形式（UTF-16或UTF-32），和UTF-8的數據交換（通信，存儲）。

如果所有本地API都使用UTF-16（例如在Windows中），將字符串作爲UTF-8意味着您必須將所有輸入轉換爲UTF-16，調用Win API，然後將答案轉換爲UTF-8。非常痛苦。

但如果主要問題是用戶界面，該字符串是簡單的問題。 更難的是UI框架。 爲此，我會推薦wxWidgets（http://www.wxWidgets.org）。支持許多平臺，成熟（17年，仍然非常活躍），原生小部件，Unicode，自由許可證。

Answer 5

我會去UTF16表示在存儲器和UTF-8或16上的硬盤或導線。主要原因：UTF16對每個「字母」都有固定的大小。這可以簡化使用絃線時的許多職責（se光，更換零件......）。

對於UTF-8的唯一原因是爲「西方/拉丁」字母減少存儲器使用量。您可以將此表示用於光盤存儲或通過網絡傳輸。它也有利於您在加載/保存到光盤/線路時不必擔心字節順序問題。

考慮到這些原因，我會去的std ::內部或wstring的 - 如果你的GUI庫提供了一個WideString的，使用（從QT喜歡的QString）。對於光盤存儲，我會爲平臺api編寫一個小平臺獨立包裝器。或者如果他們有可用於此轉換的平臺代碼，請查看unicode.org。

---

澄清：韓文/日文字母不是西方/拉丁文。日語是以漢字爲例。這就是我提到拉丁字符集的原因。

---

對於UTF-16不是1字符/ 2字節。這種假設只適用於基礎多語言平面上的字符（請參閱：http://en.wikipedia.org/wiki/UTF16）。仍然大多數UTF-16用戶都假定所有字符都在BMP上。如果您的應用程序無法保證，您可以切換到UTF32或切換到UTF8。

還是UTF-16被用於很多的API的上述原因（例如，Windows，QT，Java和.NET，wxWidgets的）