大多数Unix/POSIX/etc使用UTF-8来表示文本，而Windows使用UTF-16 LE。
为什么会这样呢？有很多人说Windows API是在UTF-8（甚至我们所知道的Unicode）存在之前编写的（1，2，3），所以UTF-16（甚至更早的UCS-2）是他们拥有的最好的API，将现有的API转换为UTF-8将是一项荒谬的工作量。
但是这两个说法有官方来源吗？The official MSDN page for Unicode让UTF-16看起来甚至是可取的（尽管我自己不同意）：
这些函数使用UTF-16（宽字符）编码，这是Unicode最常用的编码，也是Windows操作系统上用于本机Unicode编码的编码。
是否有任何官方说明（或参与该项目的工程师）解释选择UTF-16背后的原因以及为什么Windows会/不会切换到UTF-8？Disclaimer: I work for Microsoft.
3条答案
按热度按时间z5btuh9x1#
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，而不是基于UTF 16的API。
aoyhnmkz2#
Raymond Chen实际上有一个“官方”的答案--或者至少是来自微软的一个消息来源的答案（着重号是后加的）：
Windows在大多数其他操作系统之前采用了Unicode。因此，Windows对许多问题的解决方案与那些坐等尘埃落定的人所采用的解决方案不同。¹最显著的例子是Windows使用UCS-2作为Unicode编码。这是Unicode协会推荐的编码，因为Unicode 1.0仅支持65536个字符。5年后，Unicode联盟改变了他们的想法，但那时对Windows来说已经太晚了，Windows已经发布了Win32、Windows NT 3.1、Windows NT 3.5、Windows NT 3.51和Windows 95，所有这些都使用UCS-2。
换句话说，雷米Lebeau和AmigoJack都是对的--Windows在UTF-8被推荐之前就采用了Unicode（甚至存在？）;当时，UCS-2是标准，所以Windows选择了UCS-2。
当我们意识到我们需要超过65,536个字符来完成整个人类语言（现在表情符号也需要）时😁，Windows已经发布了几个版本，改变**将是非常不切实际的（如果不是不可能的话）。
感谢所有回答这个问题的人！因为我在寻找一个官方来源，所以我把这个标记为答案（虽然我把它标记为社区wiki，因为它是一个合并）。
ddrv8njm3#
“世界”很可能指的是一切：操作系统（内部使用的编码）、可执行文件（支持的编码）、文件格式（支持的编码）、文件系统（内部使用的编码）等。
WORD中的代码点。该格式已经是补丁上的补丁，添加另一个扩展可能比仅使用二进制资源块并将其转换为 UTF-8 更烦人。自从在 Windows 中引入 Unicode 以来，其API的布局是每个字符
WORD;每个函数的大多数 ANSI 版本只是调用该函数的 WIDE 版本的存根。对于 UTF-8，它不能被强制，并且会与所有遗留代码中断--需要一个全新的API（或者每个函数的第三个版本）。只有少数函数是“未来可用的”，因为你可以告诉它们文本来自哪种编码（显然如MultiByteToWideChar()）。WORDs格式存储每个字符（因此间接支持 UTF-16），我看不出它的新版本会有什么变化--我敢打赌，一个全新的文件系统将被引入，它将淘汰 NTFS，至少还具有以 UTF-8 格式存储所有文件名的新功能。