在 C++ 下处理 Unicode 字符串的最佳多平台方法是什么？

Question

我知道 StackOverflow 上已经有几个关于 std::string 与 std::wstring 或类似问题，但没有一个提出完整的解决方案。

为了获得一个好的答案，我应该定义以下要求：

• 多平台使用，必须在 Windows、OS X 和 Linux 上工作
• 与平台特定 Unicode 字符串之间的转换例如 CFStringRef、wchar_t *、char* 作为 UTF-8 或操作系统 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

我强烈建议在应用程序内部使用 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 2

与 Adam Rosenfield 答案（+1）相同，但我使用 UTFCPP 代替。

Answer 3

我最近参与的一个项目决定使用 std::wstring 进行跨平台项目，因为“宽字符串是 Unicode，对吗？”这导致了一些令人头痛的问题：

• wstring 中的标量值有多大？答：这取决于编译器的实现。在 Visual Studio (Win) 中，它是 16 位。但在 Xcode (Mac) 中，它是 32 位。
• 这导致了使用 UTF-16 进行有线通信的不幸决定。但是哪种 UTF-16 呢？有两种：UTF-16BE（大端）和 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，那么字符串问题就很简单了。
比较难的是UI框架。
为此，我推荐 wxWidgets (http://www.wxWidgets.org)。支持许多平台，成熟（17 年了，仍然非常活跃），本机小部件，Unicode，自由许可证。

Answer 5

我会在内存中使用 UTF16 表示，在硬盘或线路上使用 UTF-8 或 16。主要原因：UTF16每个“字母”的大小是固定的。这简化了使用字符串时的许多职责（搜索、更换零件......）。

使用 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。

由于上述原因，许多 API（例如 Windows、QT、Java、.NET、wxWidgets）仍然使用 UTF-16

Answer 6

您可以将UTF-16存储在std::string中。因此原则上您可以在所有平台上使用 std::string ，并存储在平台首选的编码中（Linux 为 UTF-8，Windows 为 UTF-16， ETC。）。这将使您在 C++ 类型级别上得到一些简单的东西，但必须跟踪字符串的编码。如果应用程序是独立的，这可能很简单，如果它必须互操作（参见存储、有线格式），则不太简单。

将 UTF-16 存储在 std::string 中的风险在于，您迟早会调用 .c_str() 并且结果将被解释为以第一个 0 结尾，对于 std::string s = reinterpret_cast(L"hello") 将位于 s[1]。