尽管大多数Unix/POSIX/etc世界都使用UTF-8进行文本表示，但Windows使用UTF-16LE。
为什么？有很多人说，Windows API是在UTF-8(甚至我们所知道的Unicode)存在之前编写的(1、2、3)，所以UTF-16(甚至更早的UCS-2)是他们拥有的最好的，将现有API转换为UTF-8将是一项荒谬的工作。
但这两种说法有官方来源吗？Unicode的官方MSDN页面让人觉得UTF-16可能是可取的(尽管我自己并不同意)：
这些函数使用UTF-16(宽字符)编码，这是Unicode最常见的编码，也是Windows操作系统上用于本机Unicode编码的编码。
是否有任何官方说明(或参与该项目的工程师)解释选择UTF-16背后的原因以及为什么Windows会/不会切换到UTF-8？
免责声明：我在微软工作
Windows是最早采用Unicode的操作系统之一。当时，确实还没有UTF-8，UCS-2是Unicode最常用的编码方式。因此，Windows最初对Unicode的支持是基于UCS-2。
当Unicode超过UCS-2，UTF-8和UTF-16变得更加流行时，Windows在不破坏大量现有代码的情况下切换到UTF-8已经太晚了1，然而UTF-16与UCS-2向后兼容，因此微软能够以最小的努力切换到UTF-16，并且对现有用户代码几乎没有更改。
1：20多年后的今天，在Windows 10中，微软才刚刚开始真正开始在Win32 API层支持UTF-8，但该功能仍然是实验性的，必须由用户手动启用，或在每个应用程序的基础上通过应用程序清单启用，并且通常需要对用户代码进行更改以利用启用了UTF8的API而不是基于UTF16的API
Raymond Chen实际上有一个"官方的"；答案——或者至少是一个来自微软的答案(重点增加)：
Windows在大多数其他操作系统之前采用了Unicode。因此，Windows对许多问题的解决方案与那些等待尘埃落定的人所采用的解决方案不同。这方面最显著的例子是Windows使用UCS-2作为Unicode编码这是Unicode联盟推荐的编码，因为Unicode 1.0仅支持65536个字符。²Unicode联盟在五年后改变了主意，但那时对Windows来说已经太晚了，Windows已经推出了Win32、Windows NT 3.1、Windows NT 3.5、Windows NT 3.51和Windows 95，所有这些都使用了UCS-2。³
Visual C++中Unicode printf风格格式说明符的悲惨历史
换句话说，Remy Lebeau和AmigoJack都是对的——Windows在推荐UTF-8之前采用了Unicode(甚至存在？)；当时，UCS-2是标准配置，所以这就是Windows所选择的。
当我们开发出更高效(现在也更常见)的UTF-8标准时，Windows已经推出了几个版本，更改是非常不切实际的(如果不是不可能的话)。
感谢所有为这个问题提供答案的人！由于我在寻找官方来源，我将其标记为答案(尽管我将其标为社区维基，因为它是一个合并)By"世界；您很可能指的是所有东西：操作系统(内部使用的编码)、可执行文件件格式[/strong>(支持的编码器)、 文件系统Windows不会轻易切换，因为PE(用于EXE、DLL等)等基本文件格式的资源字符串只能处理 由于在Windows中引入了Unicode，其API被布置为每个字符 NTFS也将每个字符存储在WORDs中的代码点。该格式已经是一个补丁上的一个补丁，向其添加另一个扩展可能比仅使用二进制资源块并将其强制转换为UTF-8更烦人。WORD；每个函数的大多数ANSI版本都只是调用该函数的WIDE版的存根。对于UTF-8，它不能被强制使用，并且会与所有遗留代码相冲突——需要一个全新的API(或每个函数的第三个版本)。只有少数函数是"；未来就绪"；因为你可以告诉他们文本来自哪种编码(显然是MultiByteToWideChar())。WORDs中(因此间接支持UTF-16)，我看不出只有一个新版本会有什么变化——我敢打赌，会引入一个全新的文件系统，取代NTFS，至少还具有以UTF-8存储所有文件名的新功能。