我在这里和其他地方看了很多其他帖子（见下文），但我仍然没有对这个问题有一个明确的答案：windows wchar_t如何处理基本多语言平面之外的unicode字符？
那是：
那么当您想在Windows上编写类似（U + 2008A）汉字的代码时，Windows会做什么？
答案 0 :(得分：17)
Windows stdlib下wchar_t的实现是UTF-16无视的：它只知道大约16位代码单元。
因此，您可以在字符串中放置UTF-16代理序列，并且可以选择使用更高级别的处理将其视为单个字符。字符串实现不会帮助您，也不会阻碍您;它将允许您在字符串中包含任何代码单元序列，甚至包括在解释为UTF-16时无效的代码单元序列。
Windows的许多高级功能都支持UTF-16代理的字符，这就是为什么你可以调用文件.txt并看到它正确呈现并正确编辑（单个按键）在资源管理器中支持复杂文本布局的程序（通常使用Windows的Uniscribe库），而不是两个，超过角色）。
但是仍然有一些地方你可以看到UTF-16遗忘的情况，例如你可以在与.txt相同的文件夹中创建一个名为.txt的文件，其中否则，不敏感会禁止它，或者您可以通过编程方式创建[U+DC01][U+D801].txt。
对于Windows是否“支持”UTF-16字符串或仅支持UCS-2，这就是小学生可以有一个很长且基本无意义的争论。
答案 1 :(得分：9)
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可能导致的结果）。