简析Windows Notepad里可选的字符编码

群里 @lizheming 问到了Windows Notepad（记事本）中保存文件的编码选项都是什么意思……

这篇文章就简单测试一下Windows Notepad的行为。

▲ Windows Notepad的编码包含ANSI、Unicode、Unicode big endian和UTF-8。

警告

本文仅仅阐述一个普遍使用的软件的技术事实，不表明做者支持或反对使用该软件。
事实上做者推荐任什么时候候都不使用 Windows Notepad 来处理计算机程序代码。
本文仅在某一个简体中文版64位Windows 7的实例下验证，仅供参考。不保证在其余相同或相异系统下可以重现一致的结果。

注意

本文严格区分Unicode的编码和字节序列化。
Unicode的编码仅指使用数（一般写成16进制数）来一对一的表明字符的工做。这个数的范围仅受Unicode标准的约束，与计算机毫无关联。
Unicode的字节序列化指为了可以写入计算机存储器，而把一个Unicode标准范围内的数，表示成N个字节的工做。

测试用例

测试用例为：“锟斤拷【断行】a【断行】”。（锟斤拷是一种信仰。）

全部字符的GBK和Unicode编码为：

• 锟 GBK=EFBF Unicode=U+951F
• 斤 GBK=BDEF Unicode=U+65A4
• 拷 GBK=BFBD Unicode=U+62F7

如下ASCII字符的GBK和Unicode编码与ASCII一致：

a=0x61 CR=0x0D LF=0x0A
（Windows一个换行符占有两个字符：CR+LF）

ANSI

在简体中文系统下，ANSI就是中华人民共和国国家标准定义的GBK编码。

Windows Notepad使用ANSI存储这个文件的结果以下：

EF BF  BD EF  BF BD  0D  0A  61  0D  0A
-----  -----  -----  --  --  --  --  --

简单的使用GBK编码存储了全部的字符。最高位不是1的单字节并等同于ASCII，不然双字节。

这里要注意字节序（Endian）的问题[注A]。能够看到这里的字节序是大端在先（big-endian）的。

可是没必要特地强调“大端在先的GBK”——由于从GB2312开始，标准就规定了存储方式是大端在先的[注B]。后来的GBK和GB18030-2000向下兼容。

ANSI的麻烦就是依赖系统——其余语言系统的ANSI就不是GBK了，打开GBK的文件必然乱码。而且GBK的字符集自己也过小。
（千万不要说“我只用中文”——少了Unicode那些符号，网上那些颜文字都打不出来）

Unicode系列

Windows Notepad所说的“Unicode”、“Unicode big endian”和UTF-8，全都是一样的Unicode编码的不一样的字节序列化存储方法。

UTF-16 和 BOM

这里的Unicode指UTF-16[注C]。UTF-16是极其简单粗暴的序列化方法——绝大多数的Unicode字符都在U+0000~U+FFFF的范围内[注D]，那就每一个字符用两个字节，把Unicode编码的原始值写盘。

注意ASCII字符也必须浪费一倍的空间存储高8位的0x00——由于若是把高8位的0略了，解析时就再也没有其余的依据去断字。

对于UTF-16就存在大端和小端的问题了——UTF-16并不规定字节的大端在前仍是小端在前。但UTF-16并不包含表示字节序的信息，总不能人工看看哪一个解析是不乱码的吧……

Unicode提供的解决方式是，把一个零宽无断字空格符（U+FEFF ZERO WIDTH NO-BREAK SPACE）以UTF-16的方式序列化以后，塞到文件的最前边。这样UTF-16解析器读取文件的前两个字节，若是是FE FF就是大端在前，FF FE就是小端在前。

这个塞进去的东西就叫BOM（Byte Order Mark，字节顺序标记）。

值得一提的是，零宽无断字空格符也经常使用于充当1个有效字符，破拆各类场合的字数限制。包括SegmentFault的问答和评论内容在内。

记事本的“Unicode”和“Unicode big endian”

单写“Unicode”，根本就不是一种存储方法的完整表达。由于这只包含编码而没有字节序列化。

M$出现这种错误，我一点都不以为奇怪。死记结论就能够了：Windows Notepad的“Unicode”就是UTF-16。

Windows Notepad使用“Unicode” = 小端在先的UTF-16，存储这个文件的结果以下：

FF FE 1F 95 A4 65 F7 62 0D 00 0A 00 61 00 0D 00 0A 00
 -BOM- ----- ----- ----- ----- ----- ----- ----- ----- 
U+FEFF  951F  65A4  62F7  000D  000A  0061  000D  000A <--Unicode原始值

Windows Notepad使用“Unicode big endian” = 大端在先的UTF-16，存储这个文件的结果以下：

FE FF 95 1F 65 A4 62 F7 00 0D 00 0A 00 61 00 0D 00 0A
 -BOM- ----- ----- ----- ----- ----- ----- ----- ----- 
U+FEFF  951F  65A4  62F7  000D  000A  0061  000D  000A <--Unicode原始值

UTF-8

UTF-8是一种用1~4个字节表示1个Unicode字符的变长的字节序列化方法。具体的实现细节看这篇文章。UTF-8的好处在于：

1. 不管是IETF的推荐，仍是实际业界的执行，UTF-8都是互联网的标准。
2. 向下兼容，ASCII字符UTF-8序列化后还是原样，任何ASCII文件也是有效的UTF-8文件。
3. 没有字节序问题。UTF-8的字节序是由RFC3629定死的。

Windows Notepad使用UTF-8存储这个文件的结果以下：

EF BB BF  E9 94 9F  E6 96 A4  E6 8B B7  0D   0A   61   0D   0A
 --BOM---  --------  --------  --------  --   --   --   --   --
U+ FEFF      951F      65A4      62F7   000D 000A 0061 000D 000A <--Unicode原始值

注意UTF-8前边仍然塞进去了U+FEFF按照UTF-8序列化的结果EF BB BF，做为前边提到过的BOM字节顺序标记。Windows Notepad存储的UTF-8，是带有BOM标记的UTF-8。

可是若是仅仅对于UTF-8而言，字节序是没有意义的。由于UTF-8的字节序被规范写死，U+FEFF编码后必然获得EF BB FF，得不出其余的。没有二义性，BOM就失去了本来的意义。也许只有区别UTF-8文件和UTF-16文件的用处……

如何对待UTF-8文件的BOM，RFC3629的第6章有详细的规定，不加详述。

值得一提的是，BOM我想不少PHP程序员都经历过而且恨之入骨——PHP不认识文件中的BOM头并会将其做为HTTP Response的正文送出。这甚至在无缓冲的状况下，会致使header()等必须在Response开始前执行的函数直接失效。

因此PHP程序员老是会喜欢UTF-8 without BOM的编码方式——这基本也就宣布了Windows下的PHP开发，Windows Notepad彻底的淘汰出局，哪怕是任何一星半点代码的临时修改。

番外：Notepad++的字符编码测试

ANSI没有区别，但Notepad++支持选择多国编码的不一样ANSI编码方式（相似浏览器里选编码），能够轻松生成或读取Shift-JIS等其余字符集的文件。适合用于对付日文老游戏的README等文档。

UCS-2 Big Endian、UCS-2 Little Endian和前边UTF-16的两个例子一致。注意UTF-16的文件不提供“无BOM”的存储方法（提供了就坏了）。

UTF-8仍然表明“带有BOM标记的UTF-8”。但同时提供PHP程序员最爱的UTF-8 without BOM，就像：

E9 94 9F  E6 96 A4  E6 8B B7  0D   0A   61   0D   0A
 --------  --------  --------  --   --   --   --   --
U+ 951F      65A4      62F7   000D 000A 0061 000D 000A <--Unicode原始值

Simple and clean.

注解
[注A] 对于一个双(多)字节的数，必定会按8位截断为1字节后写盘。那么写盘时先写最低8位仍是先写最高8位，就是所谓的“字节序”（Endian）问题。例如，数0x01020304写盘时，是先写最低8位的04 03 02 01，仍是先写最高8位的01 02 03 04？
先写低8位的叫作小端在先（little-endian），先写高8位的叫作大端在先（big-endian）。实际采用何种字节序受系统环境、标准规范和软件实际编写的多方面控制，不一律而论。
[注B] 字节序若是我没弄错，是GB2312采用的EUC字符编码方法控制的。
[注C] 本文并不严格区分UTF-16与UCS-2。
[注D] Unicode的最大值实际上达到了U+10FFFF，超出了两个字节可以存储的限度。
但Unicode因为历史缘由，留下了U+D800~U+DFFF这一段永久保留不用的空缺区域。
所以对U+10000及以上的字符，UTF-16借助了这部分空缺区域，对这些编码超大的字符打破2字节16位的惯例，特别的用4字节32位去表示之。
这一部分编码值太大的字符，超出了GBK的字符集范围，所以本文将彻底忽略。若有机会再进一步测试。