UTF-16 编解码器方面答案

【问题标题】：UTF-16 codecvt facetUTF-16 编解码器方面
【发布时间】：2010-12-27 17:49:32
【问题描述】：

从这个关于locales的问题扩展而来
并在this question 中描述：我真正想做的是将codecvt facet 安装到理解UTF-16 文件的语言环境中。

我可以自己写。但我不是 UTF 专家，因此我相信我会得到它几乎正确的；但它会在最不方便的时候坏掉。所以我想知道是否有任何资源（在网络上）可以从 C++ 中使用经过同行评审和测试的预构建 codecvt（或其他）方面？

原因是默认语言环境（在我的系统 MAC OS X 10.6 上）在读取文件时仅将 1 个字节转换为 1 个 wchar_t 而不进行转换。因此 UTF-16 编码文件被转换为包含大量空 ('\0') 字符的 wstrings。

【问题讨论】：

【解决方案1】：

我不确定“网络上的资源”是否是指免费提供，但 Dinkumware Conversions Library 听起来很适合您的需求——前提是该库可以集成到您的编译器套件中.

codecvt 类型在 Code Conversions 部分中描述。

【讨论】：

【解决方案2】：

从 C++11 开始，有额外的标准 codecvt 特化和类型，用于在各种 UTF-x 和 UCSx 字符序列之间进行转换；其中之一可能适合您的需求。

在<locale>:

在<codecvt>:

std::codecvt_utf8_utf16<typename Elem>：在 UTF-8 和 UTF-16 之间转换，其中 UTF-16 码位存储为指定的Elem（请注意，如果指定了char32_t，则每个char32_t 只会存储一个码位） .
- 有两个额外的默认模板参数（unsigned long MaxCode = 0x10ffff 和 std::codecvt_mode Mode = (std::codecvt_mode)0），并继承自 std::codecvt<Elem, char, std::mbstate_t>。
std::codecvt_utf8<typename Elem>：在 UTF-8 和 UCS2 或 UCS4 之间转换，具体取决于 Elem（UCS2 用于 char16_t，UCS4 用于 char32_t，平台相关用于 wchar_t）。
- 有两个额外的默认模板参数（unsigned long MaxCode = 0x10ffff 和 std::codecvt_mode Mode = (std::codecvt_mode)0），并继承自 std::codecvt<Elem, char, std::mbstate_t>。
std::codecvt_utf16<typename Elem>：在 UTF-16 和 UCS2 或 UCS4 之间转换，具体取决于 Elem（UCS2 用于 char16_t，UCS4 用于 char32_t，平台相关用于 wchar_t）。
- 有两个额外的默认模板参数（unsigned long MaxCode = 0x10ffff 和 std::codecvt_mode Mode = (std::codecvt_mode)0），并继承自 std::codecvt<Elem, char, std::mbstate_t>。

^{codecvt_utf8 and codecvt_utf16 will convert between the specified UTF and either UCS2 or UCS4, depending on the size of Elem. 因此，wchar_t 将在 16 到 31 位的系统上指定 UCS2（例如 Windows，它是 16 位），或在至少 32 位的系统上指定 UCS4 （例如 Linux，它是 32 位的），无论 wchar_t 字符串是否实际使用该编码；在对wchar_t 字符串使用不同编码的平台上，如果您不小心，这将导致问题，这是可以理解的。}

有关详细信息，请参阅 CPP 参考：

^{请注意，对标头codecvt 的支持仅在最近才添加到libstdc++。如果使用旧版本的 Clang 或 GCC，您可能必须使用 libc++，如果您想使用它。

请注意，2015 之前的 Visual Studio 版本实际上并不支持 char16_t 和 char32_t；如果这些类型存在于以前的版本中，它将分别作为unsigned short 和unsigned int 的类型定义。另请注意，旧版本的 Visual Studio 有时可能无法在 UTF 编码之间转换字符串，并且 Visual Studio 2015 has a glitch that prevents codecvt from working properly with char16_t and char32_t, requiring the use of same-sized integral types instead}

【讨论】：