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

可能的解决方案：

>提供CESU-8环境而不是UTF-8.我真的不喜欢这个.
>采取简单的方法,只支持BMP.将长度为4的UTF-8序列视为无效.
>扩展包装器以使用typedef替换mingw的wchar_t int32_t wchar_t;并且处理WCHAR和wchar_t是不同的.这是一个痛苦但它可能是移植期望清洁POSIX类型环境的应用程序并且不使用wchar_t用于任何Windows-API目的的理想选择.
>以下黑客：

读取4字节UTF-8字符的前3个字节后,mbrtowc输出对应于高代理的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字符串不允许有状态)并且它会延迟检测格式错误的字符,直到已经写入错误的部分输出.

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