c++ - Unicode 与 wchar_t 与 C++ 中的 ICU 的不一致

Question

虽然 wchar_t 在支持不同编译器的情况下不一致，但是可以安全地假设 wchar_t 实现和大小在 GNU/GCC 中至少在 Linux 上是相似的吗？

尽管 wchar_t 大小在位大小(32 位/64 位)方面具有系统架构依赖性，但在 Linux (GNU/GCC) 上是宽字符类型，实际上依赖于编译器或依赖于 libstdc++ 库？我的意思是通过更改或升级我应该考虑的 wchar_t 在大小和支持方面可能无法按预期工作

同时 IBM ICU是另一种选择，它可以与 std::string 一起使用吗？

我应该完全放弃 wchar_t 以支持 ICU 吗？

注意:在类似 Unix 的操作系统上，例如带有 GNU/GCC libstdc++ 的 Linux 为编译器带来了核心 C++ 功能，因此会不时更新。

Answer 1

如果您想向用户显示字符串，您可能必须考虑 wchar_t(或其他一些库定义的类型)。不同的编译器和平台对wchar_t的定义不同，因为它们使用不同的Unicode编码技术。例如在 Windows/Visual C++ 上，wchar_t 是一个 16 位类型，适用于 UTF-16。例如在 GCC/Linux 上，wchar_t 是一个 32 位类型，适用于 UTF-32。

IBM ICU 库具有从一种编码转换为另一种编码的转换函数。您的平台(例如 Win32)可能还具有从一种编码转换为另一种编码的功能。

根据您的要求(速度、内存使用)，您应该选择适合平台的内部格式。在 Windows 上它可能是 UTF-16，在 Linux 上它可能是 UTF-32。这样您就不必一直对字符串进行代码转换，只需对它们进行简单的平台定义操作(wcslen()、wcscmp() 等)。

对于外部格式(文本文件等)，我倾向于使用 UTF-8。原因是如果文件包含西方语言的文本，文件会小得多。另一个好处是您不必考虑 UTF-8 中的字节序，这降低了(您或其他人)出错的可能性。

IBM ICU 是一个非常庞大且功能强大的库，用于处理 Unicode 字符串。虽然，它可能正在使用大锤钉入小钉子。您需要它的所有功能吗？目标平台支持的 Unicode 功能可能会满足您的要求。