如何最好地处理 Windows 16 位 wchar_t 的丑陋问题？

Question

我正在编写一个与 mingw 一起使用的包装层，它为应用程序提供了虚拟 UTF-8 环境。处理文件名的函数是从 UTF-8 转换并调用相应的“_w”函数的包装器，依此类推。我遇到的最大问题是 Windowswchar_t是 16 位的。

对于文件系统操作来说，这不是什么大问题。我可以在 UTF-8 和 UTF-16 之间来回转换，一切都会正常。但标准 C 多字节/宽字符转换 API 不允许多 wchar_t 字符。

可能的解决方案：

1. 提供 CESU-8 环境而不是 UTF-8。我真的不喜欢这个。
2. 走捷径，只支持BMP。将长度为 4 的 UTF-8 序列视为无效。
3. 扩展包装器以替换 mingw 的包装器wchar_t并typedef int32_t wchar_t;处理WCHAR和wchar_t不同。这很痛苦，但对于需要干净的 POSIX 类型环境且不用于wchar_t任何 Windows API 目的的移植应用程序来说，它可能是理想的选择。
4. 以下黑客：

mbrtowcwchar_t读取 4 字节 UTF-8 字符的前 3 个字节后，输出对应于高代理项的值，并将剩余状态保留在mbstate_t对象中。收到下一个字节后，它将其与保存的状态组合以输出低代理。如果最后一个字节最终无效，它将返回 -1（使用 EILSEQ）并且一个单独的代理最终会出现在输出流中（坏...）。

wcrtomb当处理高位代理时，输出 UTF-8 的前 2 个字节，并将剩余状态保存在其mbstate_t对象中。当它随后处理低位代理时，它将其与保存的状态结合起来以输出 UTF-8 的最后 2 个字节。如果未收到有效的低代理项，它将返回 -1（使用 EILSEQ）并且不完整的 UTF-8 序列最终会出现在输出流中（不好...）。

这个 hack 的优点是，只要输入有效，它就可以工作，并且允许访问任何 UTF-8 字符，从而访问任何可能的文件名/参数/等。应用程序可能需要使用的文本。

缺点是它不严格符合 ISO C（wchar_t字符串不允许有状态），并且它会延迟对格式错误字符的检测，直到写入不正确的部分输出为止。

我正在寻找有关不同选项的反馈，尤其是我提出的黑客：是否合理，缺点是否可能导致严重错误，以及是否有任何其他我尚未考虑的缺点可能会阻止该方案完全工作。我也很高兴听到我没有想到的任何其他可能的解决方案。

Answer 1

我会做类似#4 的事情，但在确定输入有效之前不会生成任何输出。

• mbrtowc应该解码整个字符。如果它在 BMP 之外，则输出高代理并将低代理存储在mbstate_t.
• wcrtomb应将高位代理存储在 中mbstate_t，然后如果字符有效则输出所有 4 个 UTF-8 字节。