Windows下是宽字符还是UTF-8？

Question

我们正在将Windows代码从传统字符集转换为Unicode。我们的GUI代码使用MFC，但我们也有许多非GUI模块将被合并到非MFC环境中。

UTF-8是最可靠的保存数据文件的方法吗？

Windows系统调用必须使用宽字符串，否则将在旧代码页中解释它们。对于程序中的常规字符串，使用宽字符串(与系统调用和MFC兼容)还是UTF-8 (如果我们这样做，则与数据文件兼容)更好？

我们如何将UTF-8字符串被解释为遗留代码页的风险降至最低？我们在过去遇到过海外用户的跨代码页问题，而摆脱这一问题是我们转向完整Unicode的动机之一。

Answer 1

不幸的是，Windows的情况有点丑陋。尽管在内部对Unicode进行了标准化，但在许多情况下，文本文件仍然使用当前代码页进行解释。

UTF-8是一个很好的文件选择，因为它允许在使用不同语言的Windows系统以及Linux及其相关系统之间交换数据。您可以通过在文件开头放置一个Byte order mark (BOM)来增加正确解释UTF-8文件的机会。这并不是一个完美的解决方案；并不是所有的程序都能识别它，而且它违背了Unicode标准的建议。

Windows API使用UTF-16作为其Unicode接口。我坚持使用内部程序，除非你喜欢逆水行舟。

Answer 2

在应用程序中，您有两个基本模型：

• 在整个应用程序中都使用UTF-16。
• 从头到尾都使用UTF-8字符串，并在Win32 API / MFC / ...调用

如果您打算大量使用不支持UTF-16的库，那么第一个可能是一个问题。在实践中，我从未发现这是一个问题。有些人会说你很愚蠢，仅仅因为你使用UTF-16，你的产品就注定要失败，但我在实践中也从来没有发现这是一个问题。

如果你屈从于同级的压力，或者依赖于现有的以UTF-8为中心的代码，那么在内部使用UTF-8可以被简化，因为对你的字符串使用一个自定义的包装器类来进行CString的转换，再加上一些帮助类来处理[out] CString * / CString &)。对于非MFC CString代码，std::vector<TCHAR>是一个很好的表示。当然，包装器不应该隐式地转换为char *或wchar_t *，或者从char*或char*转换。

你读写的文件：

只要它们是“你的”应用程序文件，你就可以做任何你想做的事情。事实上，使用不透明(二进制)格式可能会将您与用户问题完全隔离开来。只要保持一致即可。

当您开始处理来自其他应用程序的文件时，或者期望用户使用其他应用程序编辑您的应用程序的文本文件时，就会出现问题。这就是它开始变得黯淡的地方。由于多年来对UTF-8的支持非常有限，因此许多工具无法很好地应对这一问题。其他程序可以正确识别和解释UTF-8，但无法跳过存在的任何BOM标记。

尽管如此，UTF-8仍然是“未来的安全赌注”。即使是更多的前期开发，我也强烈建议将其用于共享文件。

我们的解决方案，经过一番反复，如下所示：

读取文本文件时，默认算法为：

物料清单的

• 探测器。如果存在，则依靠BOM (当然跳过它)
• 探测器来获取有效UTF-16 (我们甚至支持LE/ BE，尽管BE不太可能出现)。仅用于ASCII码的
• 探测(所有字节<= 127)。如果是，则解释为UTF-8的ASCII
• 探测器。如果正文是有效的UTF-8，则读作UTF-8
• otherwise回退到当前代码页

UTF-8是专门设计的，因此任何其他编码实际上都是有效的，UTF-8非常非常低。这使得最后两个步骤的顺序相当安全。

在编写文本文件时，我们使用没有BOM的UTF-8。从我们使用的外部工具的简短informat调查来看，这是最安全的选择。

基于此，我们还包含了一个实用程序，以防止我们的开发人员和用户检测到非UTF-8文本文件并将其转换为UTF-8。

Answer 3

我同意@DavidHeffernan的观点，我也建议完全改用Unicode (我们深吸了一口气，对我们所有的应用程序都这样做了，这是一次性的努力，从长远来看是有回报的)