linux utf-8 ansi,Windows 记事本的 ANSI、Unicode、UTF-8 区别+BOM

最新推荐文章于 2023-11-26 18:14:28 发布

中关村88楼

最新推荐文章于 2023-11-26 18:14:28 发布

阅读量515

点赞数

文章标签： linux utf-8 ansi

该楼层疑似违规已被系统折叠隐藏此楼查看此楼

梁海，U+6211, U+7231, U+5B83

46 票，来自

Moeraki、王君櫹、winter

简答。一些细节暂无精力查证，如果说错了还请指出。

一句话建议：涉及兼容性考量时，不要用记事本，用专业的文本编辑器保存为不带 BOM 的 UTF-8。

* * *

如果是为了跨平台兼容性，只需要知道，在 Windows 记事本的语境中：

所谓的「ANSI」指的是对应当前系统 locale 的遗留(legacy)编码。[1]

所谓的「Unicode」指的是 UTF-16LE。[2]

所谓的「UTF-8」指的是带 BOM 的 UTF-8。[3]

GBK 等遗留编码最麻烦，所以除非你知道自己在干什么否则不要再用了。

UTF-16LE 理论上其实很好，字节序也标明了，但 UTF-16 毕竟不常用。

UTF-8 本来是兼容性最好的编码但 Windows 偏要加 BOM 于是经常出问题。

所以，跨平台兼容性最好的其实就是不用记事本。

建议用 Notepad++ 等正常的专业文本编辑器保存为不带 BOM 的 UTF-8。

另外，如果文本中所有字符都在 ASCII 范围内，那么其实，记事本保存的所谓的「ANSI」文件，和 ASCII 或无 BOM 的 UTF-8 是一样的。

* * *

阮

一峰那篇〈字符编码笔记：ASCII，Unicode和UTF-8〉的确很有名，但从那篇文章能看出来他其实还是没完全搞清楚 Unicode 和

UTF-8 的关系。他依旧被 Windows 的混乱措词误导。事实上，几年前我读完他那篇文章之后依旧一头雾水，最终还是自己看维基百科看明白的。

所以，那篇文章不值得推荐。

* * *

关于字符集(character set)和编码(encoding)，某几篇答案中似乎有些混淆。

对于 ASCII、GB 2312、Big5、GBK、GB 18030 之类的遗留方案来说，基本上一个字符集方案只使用一种编码方案。

比

如 ASCII 这部标准本身就直接规定了字符和字符编码的方式，所以既是字符集又是编码方案；而 GB 2312

只是一个区位码形式的字符集标准，不过实际上基本都用 EUC-CN 来编码，所以提及「GB 2312」时也说的是一个字符集和编码连锁的方案；GBK

和 GB 18030 等向后兼容于 GB 2312 的方案也类似。

于是，很多人受这些遗留方案的影响而无法理解字符集和编码的关系。

对

于 Unicode，字符集和编码是明确区分的。Unicode/UCS 标准首先是个统一的字符集标准。而 Unicode/UCS

标准同时也定义了几种可选的编码方案，在标准文档中称作「encoding form」，主要包括 UTF-8、UTF-16 和 UTF-32。

所以，对 Unicode 方案来说，同样的基于 Unicode 字符集的文本可以用多种编码来存储、传输。

所以，用「Unicode」来称呼一个编码方案不合适，并且误导。

* * *

[1] Windows 里说的「ANSI」其实是 Windows code pages，这个模式根据当前 locale 选定具体的编码，比如简中 locale 下是 GBK。把自己这些 code page 称作「ANSI」是 Windows 的臭毛病。在 ASCII 范围内它们应该是和 ASCII 一致的。

[2] 把 UTF-16LE 称作「Unicode」也是 Windows 的臭毛病。Windows

从 Windows 2000 开始就已经支持 surrogate pair 了，所以已经是 UTF-16

了，「UCS-2」这个说法已经不合适了。UCS-2 只能编码 BMP 范围内的字符，从 1996 年起就在 Unicode/ISO 标准中被

UTF-16 取代了(UTF-16 通过蛋疼的 surrogate pair 来编码超出 BMP 的字符)。都十多年了，求求大家别再误称了……

[3] 把带 BOM 的 UTF-8 称作「UTF-8」又是 Windows 的臭毛病。如果忽略 BOM，那么在 ASCII 范围内与 ASCII 一致。另请参见：「带 BOM 的 UTF-8」和「无 BOM 的 UTF-8」有什么区别？

============

BOM——Byte Order Mark，就是字节序标记

在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。

在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5以后的版本已经开始支持BOM了。现在又发现，PHP也不支持BOM。PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。

由于必须在在Bo-Blog的wiki看到，同样使用PHP的Bo-Blog也一样受到BOM的困扰。其中有提到另一个麻烦：“受COOKIE送出机制的限制，在这些文件开头已经有BOM的文件中，COOKIE无法送出(因为在COOKIE送出前PHP已经送出了文件头)，所以登入和登出功能失效。一切依赖COOKIE、SESSION实现的功能全部无效。”这个应该就是Wordpress后台出现空白页面的原因了，因为任何一个被执行的文件包含了BOM，这三个字符都将被送出，导致依赖cookies和session的功能失效。

解决的办法嘛，如果只包含英文字符(或者说ASCII编码内的字符)，就把文件存成ASCII码方式吧。用UE等编辑器的话，点文件->转换->UTF-8转ASCII，或者在另存为里选择ASCII编码。如果是DOS格式的行尾符，可以用记事本打开，点另存为，选ASCII编码。如果包含中文字符的话，可以用UE的另存为功能，选择“UTF-8 无 BOM”即可。