c - 如何最好地处理 Windows 的 16 位 wchar_t 丑陋？

Question

我正在编写一个与 mingw 一起使用的包装层，它为应用程序提供了一个虚拟的 UTF-8 环境。处理文件名的函数是从 UTF-8 转换并调用相应的“_w”函数等的包装器。我遇到的最大问题是 Windows 的 wchar_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. 以下技巧:

mbrtowc 读取一个4字节的UTF-8字符的前3个字节后，输出一个高代理对应的wchar_t，其余状态保存在mbstate_t 对象。收到下一个字节后，它将其与保存的状态结合起来输出低代理项。如果最后一个字节最终无效，它返回 -1(使用 EILSEQ)并且一个单独的代理项最终出现在输出流中(坏...)。

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

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

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

我正在寻找有关不同选项的反馈，尤其是我提出的 hack:是否合理，缺点是否可能导致严重错误，以及是否还有其他我尚未考虑的缺点可能会保留从完全工作的计划。我也很乐意听到我没有想到的任何其他可能的解决方案。

Answer 1

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

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