为什么 wchar_t 和 wstrings 在 C 中国际化效率低下，有哪些更好的选择？

C 中宽字符 (wchar_t) 和 Wstring 的低效率：国际化的替代方案

简介

wchar_t，C 中的宽字符类型，具有一直是编程界争论的话题。它的使用，特别是在 Windows API 中，引起了对其缺点的担忧。本文研究了 wchar_t 和 wstrings 的固有缺点，探索国际化的替代方法。

wchar_t 的问题

wchar_t 的定义要求它表示来自每个受支持的语言环境都使用单个代码点。但是，不能保证 wchar_t 足够大以同时容纳来自不同语言环境的所有字符。这对使用一种语言环境将字符串转换为 wchar_t，然后使用另一种语言环境转换回 char 提出了挑战。

此外，wchar_t 最初旨在通过在代码单元和字符之间建立一对一映射来简化文本处理。然而，Unicode 的采用允许使用多个代码点表示字符，打破了这一假设。因此，wchar_t 无法可靠地用于简单的文本处理算法。

wchar_t 的有限使用

在可移植代码中，wchar_t 几乎没有什么用处。虽然定义 STDC_ISO_10646 确保 wchar_t 值和 Unicode 代码点之间的一对一映射，但 Windows 不遵守此约定，而是使用 UTF-16 作为其 wchar_t 编码。这种不一致破坏了依赖 wchar_t 进行文本处理的代码的可移植性。

在特定于平台的平台上，wchar_t 可能具有一些价值，特别是在 Windows 上，它对于打开某些文件至关重要。然而，在这些利基用例之外，wchar_t 的优势是值得怀疑的。

宽字符的替代品

UTF-8 编码的 C 字符串是 wchar_t 的首选替代品用于可移植代码。它们提供跨平台的通用文本表示，并以其预期形式利用标准数据类型。这种方法利用语言支持、字符串文字和调试器集成，为处理文本提供强大的解决方案。

另一种选择涉及利用与平台无关的表示形式，例如保存 UTF-16 数据的无符号短数组。虽然这种方法需要自定义库支持，但它可以提供便携式文本处理解决方案。

C 11 引入了 char16_t 和 char32_t 作为 wchar_t 的替代品，提供了语言和库的增强。虽然不能保证它们对应于 UTF-16 或 UTF-32，但主要实现很可能会采用这些编码。 C 11 还改进了 UTF-8 支持，包括引入 UTF-8 字符串文字。

可避免的替代方案

TCHAR，一种过时的 Windows 特定类型，应该是避免了。它是为迁移遗留代码而设计的，由于其模糊的编码和数据类型定义而缺乏可移植性。由于其目的与 wchar_t 的错误使用一致，因此 TCHAR 没有提供任何有意义的价值。

以上是为什么 wchar_t 和 wstrings 在 C 中国际化效率低下，有哪些更好的选择？的详细内容。更多信息请关注PHP中文网其他相关文章！