windows wchar_t如何处理基本多语言平面之外的unicode字符？

Question

我在这里和其他地方看过其他一些帖子(见下文),但我仍然没有对这个问题有一个明确的答案:windows wchar_t如何处理基本多语言平面之外的unicode字符？

那是:

• 许多程序员似乎觉得UTF-16是有害的,因为它是一个可变长度的代码.
• wchar_t在Windows上为16位宽,但在Unix/MacOS上为32位宽
• Windows API使用宽字符,而不是Unicode.

那么当你想在Windows上编写像(U + 2008A)Han Character这样的东西时,Windows会怎么做？

Answer 1

wchar_tWindows stdlib下的实现是UTF-16遗忘:它只知道大约16位代码单元.

因此,您可以将UTF-16代理序列放在字符串中,您可以选择使用更高级别的处理将其视为单个字符.字符串实现不会帮助您,也不会阻碍您; 它将允许您在字符串中包含任何代码单元序列,甚至包括在解释为UTF-16时无效的代码单元序列.

Windows的许多高级功能确实支持由UTF-16代理制作的字符,这就是为什么你可以调用一个文件.txt并看到它正确渲染并正确编辑的原因(只需一个按键,而不是两个,以便移过在像Explorer这样支持复杂文本布局的程序中(通常使用Windows的Uniscribe库).

但是仍然有一些地方你可以看到UTF-16遗忘通过,例如你可以创建一个.txt在同一文件夹中调用的文件.txt,其中不区分大小写会禁止它,或者你可以创建的事实[U+DC01][U+D801].txt编程.

对于Windows是否"支持"UTF-16字符串或仅支持UCS-2,这就是小学生可以有一个很长且基本无意义的争论.

Answer 2

Windows曾经使用UCS-2,但在Windows 2000中采用了UTF-16.Windows wchar_t API现在生成并使用UTF-16.

并非所有第三方程序都能正确处理此问题,因此可能存在BMP之外的数据错误.

另请注意,作为可变长度编码的UTF-16不符合与wchar_t一起使用的编码的C或C++要求.这会导致一些问题,例如某些标准函数(如wctomb)需要单个wchar_t,无法处理Windows上的BMP以外的字符,Windows会定义一些使用更宽类型的附加函数以便能够处理单个字符在BMP之外.我忘了它是什么功能,但我遇到了一个返回int而不是wchar_t的Windows函数(并且它不是EOF可能导致的结果).