POSIX(Linux等)也有一些基于wchar_t类型的w API.在Windows以外的平台上,这通常对应于UTF-32而不是UTF-16.这对于简单的字符串操作很有用,但却非常臃肿.

但是内存中的API并不是那么重要.导致更多困难的是文件存储和线上协议,其中数据在具有不同字符集传统的应用程序之间交换.

在这里,紧凑性优于易于索引;到目前为止,UTF-8被证明是最好的格式,而Windows对UTF-8的支持不佳会导致真正的困难. Windows是最后一个仍然具有特定于语言环境的默认编码的现代操作系统;其他人默认都转为UTF-8.

虽然我真的希望微软能够在未来的版本中重新考虑这个问题,因为即使在仅限Windows的世界中它也会引起巨大而不必要的问题,但它是如何发生的,这是可以理解的.

在过去设计WinNT时的想法是UCS-2是用于Unicode的.在16位字符范围之外没有任何东西.每个人都会在内存中使用UCS-2,自然最简单的方法就是直接从内存中保存这些内容.这就是为什么Windows将这种格式称为“Unicode”,并且直到今天仍然在UI中将UTF-16LE称为“Unicode”,就像保存盒一样,尽管它完全是误导性的.

在Unicode 2.0之前,UTF-8甚至没有标准化(连同扩展的字符范围和使UTF-16成为今天的代理).到那时,微软已经开始使用WinNT4,此时改变战略已经太晚了.简而言之,微软在Unicode处于起步阶段的时候,从头开始设计新的操作系统是不吉利的.