Windows 7 UTF-8 和 Unicode

Question

有人可以解释一下 Windows 7 (Pro 64-bit) 有什么变化吗？

详细信息：以前我使用的是 Windows XP，并且有一些 CSV 格式的翻译文件（UTF-8 编码）。我能够在记事本和 Excel 中查看字体。升级到 Windows 7 后，当我打开这些文件时——我看到的只是方框（你知道，如果我在浏览器中打开它们——我能够看到所有的翻译）。如果我用 Unicode 保存这些文件，一切似乎都很好。

那么，究竟发生了什么？为什么 Windows 7 使用 Unicode 而不是 UTF-8？

Answer 1

为什么 Windows 7 使用 Unicode 而不是 UTF-8？

术语

Unicode和UTF-8不是同一种东西：Unicode 是一个字符集，它定义一组字符（一个曲目）并为每个字符分配数字（代码点）。UTF?8 是可用于表示磁盘上或传输中的 Unicode 字符流的几种编码之一。例如，相同的 Unicode 字符流也可以编码为 UTF?16、UTF?32 或 UTF?7。

但是，你“编码”选项，包括记事本提供ANSI，Unicode，Unicode big-endian和UTF-8。编写本文的 Microsoft 开发人员使用了错误的术语。当他们说“Unicode”时，他们很可能是指“ UTF-16 little-endian ”。当他们说“ANSI”时，他们指的是代码页 1252 (CP-1252)。

微软记事本

我相信 Microsoft 的记事本使用字节顺序标记 ( BOM )编写 UTF-16，并且记事本在读取文本文件时会查找 BOM。BOM 告诉应用程序该文件是 UTF-16 并指示它是大端还是小端。

如果记事本没有找到 BOM，它会调用一个库函数IsTextUnicode，它会查看数据并尝试猜测使用的编码。有时（不可避免地）它猜测不正确。有时它会猜测“ANSI”文件是“Unicode”。尝试将 UTF-16 或 UTF-8 文件解释为代码页 1252 会导致它显示错误的字形并且无法找到字形来呈现某些 8 位值——这些将显示为正方形。

正如harrymc 在他的回答中所说，记事本有更好的替代品。但是记事本允许您在打开文件时明确选择编码（而不是让记事本尝试猜测）。

字节顺序标记

根据 Unicode 联盟，字节顺序标记 (BOM) 是可选的。但是，Windows 依靠 BOM 来区分某些编码。

简而言之，也许您的文件由于某种原因缺少 BOM？也许 BOM 在升级过程中丢失了？

如果您仍然有显示为正方形的原始文件，您可以对它们进行十六进制转储，以查看它们是否包含 BOM。

纯文本文件标准

问题是实际上没有——没有针对纯文本文件的通用标准。相反，我们有许多不兼容和未知数。

• 行尾是如何标记的？一些平台使用控制字符回车 (CR) 后跟换行符 (LF)，一些单独使用 CR，一些单独使用 LF。

• 以上是终止符还是分隔符？这会在文件末尾产生影响，并且已知会导致问题。

• 制表符和其他控制字符的处理。我们可能假设制表符用于从行的开头对齐 8 个标准字符宽度的倍数，但实际上并不确定。许多程序允许更改选项卡位置。

• 字符集和编码？没有通用的标准来指示文件中的文本使用了哪些。我们最接近的是寻找 BOM 的存在，该 BOM 表明编码是用于 Unicode 的编码之一。读取文件的程序可以从 BOM 值区分 UTF-8 和 UTF-16 等，以及 UTF-16 的 Little-Endian 和 Big-Endian 变体等。以任何其他流行的编码方式进行编码，例如 CP-1252 或 KOI-8。

等等。上述元数据均未写入文本文件 - 因此最终用户在读取文件时必须通知程序。最终用户必须知道任何特定文件的元数据值，否则他们的程序可能会使用错误的元数据值。

布什隐瞒事实

在 Windows XP 上试试这个。

• 打开记事本。
• 将字体设置为 Arial Unicode MS。（您可能需要先安装它；如果您没有在菜单中看到它，请单击“显示更多字体”。）
• 输入文本“布什隐藏了事实”。
• 选择Save As。从Encoding菜单中，选择ANSI。
• 关闭记事本。
• 重新打开文档（例如，使用Start, My Recent Documents）。
• 你会看见 ？？？？？？？？？而不是“布什隐瞒事实”。

这说明IsTextUnicode记事本使用的函数错误地猜测 ANSI（真正的 Code?Page 1252）文本是没有 BOM 的 Unicode UTF-16LE。保存为ANSI.

Windows 7的

在 Windows 7 中，Microsoft 进行了调整，IsTextUnicode以免发生上述情况。在没有 BOM 的情况下，现在更有可能猜测 ANSI (CP 1252) 而不是 Unicode (UTF-16LE)。因此，对于 Windows-7，我预计您更有可能遇到相反的问题：包含代码点大于 255 的 Unicode 字符但没有 BOM 的文件现在更有可能被猜测为 ANSI - 因此显示不正确。

防止编码问题

目前，最好的方法似乎是在任何地方都使用 UTF-8。理想情况下，您会将所有旧文本文件重新编码为 UTF-8，并且只将文本文件保存为 UTF-8。有诸如recode和iconv 之类的工具可以帮助解决这个问题。