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

【问题标题】：Why the creators of Windows and Linux systems chose different ways to support Unicode?为什么 Windows 和 Linux 系统的创建者选择不同的方式来支持 Unicode？
【发布时间】：2010-05-28 11:12:41
【问题描述】：

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

【问题讨论】：

标签： windows linux unicode

【解决方案1】：

UTF-16 几乎是一种损失，两全其美。它既不紧凑（对于 ASCII 字符的典型情况），也不将每个代码单元映射到一个字符。这并没有对任何人造成太大影响，因为基本多语言位面之外的字符仍然很少使用，但它确实很丑。

POSIX（Linux 等）也有一些 w API，基于 wchar_t 类型。在 Windows 以外的平台上，这通常对应于 UTF-32 而不是 UTF-16。这很适合简单的字符串操作，但非常臃肿。

但内存中的 API 并不是那么重要。造成更大困难的是文件存储和在线协议，其中数据在具有不同字符集传统的应用程序之间交换。

在这里，紧凑性胜过易于索引；到目前为止，UTF-8 显然被证明是最好的格式，而 Windows 对 UTF-8 的糟糕支持造成了真正的困难。 Windows 是最后一个仍然具有特定于语言环境的默认编码的现代操作系统；默认情况下，其他所有人都已迁移到 UTF-8。

虽然我非常希望 Microsoft 会在未来的版本中重新考虑这一点，因为即使在仅 Windows 的世界中它也会导致巨大且不必要的问题，但它是如何发生的是可以理解的。

在过去设计 WinNT 时的想法是，UCS-2 是 it 用于 Unicode。不会有任何超出 16 位字符范围的内容。每个人都会在内存中使用 UCS-2，自然最容易直接从内存中保存这些内容。这就是为什么 Windows 将这种格式称为“Unicode”，并且直到今天仍然在 UI 中将 UTF-16LE 称为“Unicode”，就像保存框一样，尽管它完全具有误导性。

UTF-8 甚至在 Unicode 2.0 之前都没有标准化（连同扩展的字符范围和使 UTF-16 成为今天这样的代理）。那时微软已经开始使用 WinNT4，此时改变策略为时已晚。简而言之，在 Unicode 处于起步阶段的时候，微软从头开始设计一个新的操作系统是很不幸的。

【讨论】：

我不会经常说。 BMP 包含当时在以前标准的国家字符集中（Shift-JIS、Big5、GB 等）中的表意文字，因此 SMP 中的附加字符是 CJK 用户在 Unicode 3.1 之前根本无法使用的字符.这些大多是学术兴趣的历史字符，IME 不允许您直接输入它们，而且字体支持仍然很弱。

【解决方案2】：

早在 90 年代初（Windows NT 3.1 于 1993 年问世），在 Linux 还没有支持 Unicode 的概念之前，Windows 就选择使用 UTF-16 来支持 Unicode，并且随之而来的 Ascii/Unicode 功能以 WAAAAAAY 的方式 WAAAAAAY。

Linux 已经能够从在 Windows 和其他支持 Unicode 的平台上构建的最佳实践中学习。

今天很多人都会同意，由于大小原因，UTF-8 是更好的编码，除非您知道您绝对要处理大量双字节字符 - 完全是 - 其中 UTF-16 更节省空间。

【讨论】：

可能是为了更好地集成到 Windows 中。许多糟糕的设计决策的典型“好”（至少，一个非常有效的）原因。
我认为 Windows 兼容性与它有很大关系。（在 Windows 上运行时，Python 也将 UTF-16 用于 unicode-strings。）然而，Java 中的 Unicode 也有一个简单的不良设计元素：Java 在很多地方都遵循系统“默认编码”，这几乎是从来没有正确的事情。 Java 鼓励您编写易碎的、不可移植的字符集代码。
MS 选择 UTF-16 的原因是当时这意味着你有一个固定大小的字符，然后他们向 Unicode 添加了更多的东西，结果证明 16 位对于所有的代码点，所以现在 Windows 陷入了两全其美的困境，可变长度字符编码和浪费空间，以及失去与 ascii 字符串的兼容性。这意味着 Windows 最终会执行 UTF-8 -> UTF-16，反之亦然...（java 也这样做，对于所有字符串... UHG 慢，至少在 Windows 上您可以推迟转换，直到您绝对也有）
Linux 内核也不需要太多的东西来支持 UTF8（Linux 文件名可以包含除 0 以外的任何字节），除了文件名之外，内核并不真正处理文本那可能是ASCII以外的任何东西。（当然，当你想使用像 NTFS 这样的文件系统时，这会变得很棘手，你必须关心编码……因为它使用 UTF-16……而 Linux 不……）
@Michael Czardybon：实际上，Java 与 WindowsNT 相当现代。我在 1996 年底开始使用它——我认为当时的很多想法是 UTF-16 仍然是要走的路。如果您认为该语言的开发始于 1994 年左右，那是有道理的。 @spudd86：他们知道当它被创建时，16 位对于每个写入的字符来说都不够大 - 论点是它对于目前使用的绝大多数字符来说已经足够了。是的，EPIC-失败。 :-/