为什么Windows和Linux系统的创建者选择不同的方式来支持Unicode

发布时间：2020-12-14 04:35:32 所属栏目：Windows 来源：网络整理

导读：据我所知,Linux选择了UTF-8的向后兼容性,而Windows为UTF-16添加了全新的API函数(以“W”结尾).这些决定会有所不同吗？哪一个证明更好？ UTF-16几乎是一个损失,两个世界中最糟糕的.它既不紧凑(对于典型的ASCII字符),也不会将每个代码单元映射到一个字符.由于

据我所知,Linux选择了UTF-8的向后兼容性,而Windows为UTF-16添加了全新的API函数(以“W”结尾).这些决定会有所不同吗？哪一个证明更好？

UTF-16几乎是一个损失,两个世界中最糟糕的.它既不紧凑(对于典型的ASCII字符),也不会将每个代码单元映射到一个字符.由于基本多语言平面之外的人物仍然很少使用,但这并没有真正咬过任何人,但它肯定是丑陋的.

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处于起步阶段的时候,从头开始设计新的操作系统是不吉利的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!