刨根究底字符编码之十六——Windows记事本的诡异怪事：微软为何跟联通有仇？（没有BOM，因此被误判为UTF8。“联通”两个汉字的GB内码，其第一第二个字节的起始部分分别是“110”和“10”，，

1.

当用一个软件(好比Windows记事本或Notepad++)打开一个文本文件时，它要作的第一件事是肯定这个文本文件到底是使用哪一种编码方式保存的，以便于该软件对其正确解码，不然将显示为乱码。

通常软件肯定文本文件编码方式的方法有以下三种：

• 检测文件头标识；
• 提示用户手动选择；
• 根据必定的规则自行推断。

2.

文件头标识通常指的是字节顺序标记BOM(Byte Order Mark)，位于文件的最开始。当打开一个文本文件时，就BOM而言，有以下几种情形：

• BOM为：EF BB BF ——表示编码方式为UTF-8；
• BOM为：FF FE ——表示编码方式为UTF-16LE(小端序)；
• BOM为：FE FF ——表示编码方式为UTF-16BE(大端序)；
• BOM为：FF FE 00 00 ——表示编码方式为UTF-32LE(小端序)；
• BOM为：00 00 FE FF ——表示编码方式为UTF-32BE(大端序)；
• 没有BOM ——要么显式地提示用户手动选择一种编码方式，要么隐式地由软件按规则自行推断出编码方式。

3.

接下来，是见证诡异怪事的时刻。

当你在简体中文版的Windows记事本里新建一个文件，输入“联通”两个汉字以后，保存为一个txt文件。而后关闭，再次打开该txt文件后，你会发现刚才输入并保存的“联通”两个汉字居然莫名其妙地消失了，取而代之的是几个乱码。以下图所示。

这是为何呢？难道是微软跟联通有仇吗？

原来，当你用Windows记事本新建一个文本文件时，其编码方式默认为ANSI编码(在简体中文版Windows中实际为GBK编码)，没有BOM。

(注：Windows系统中的ANSI编码指的是在区域设置中所设置的系统默认编码方式，在简体中文版Windows系统中指的是GBK，即CP936代码页，具体可参看前文《刨根究底字符编码之七——ANSI编码与代码页》）

（笨笨阿林原创文章，转载请注明出处）

在这种编码方式下，该文本文件仅仅保存了“联通”两个汉字的GB内码的四个字节，以下所示(左边为十六进制，右边为二进制)。

　　c1 　1100 0001
　　aa 　1010 1010
　　cd 　1100 1101
　　a8 　1010 1000

经过Notepad++的HEX-Editor插件可查看内码(十六进制)，以下图所示。

经过UltraEdit的“十六进制编辑”模式也可查看内码(十六进制)，以下图所示。

4.

当用记事本再次打开该文本文件时，因为没有BOM，记事本又没有提供显式地提示用户手动选择编码方式的功能，因而就只能隐式地按其推断规则自行推断，推断的结果就是被误认为了这是一个UTF-8编码方式的文件。

为何会推断错误呢？又为何会将其编码方式错误地推断为UTF-8呢？

注意，“联通”两个汉字的GB内码，其第一第二个字节的起始部分分别是“110”和“10”，第三第四个字节的起始部分也分别是“110”和“10”，这恰好符合了UTF-8编码方式里的两码元序列的编码算法规则(即与UTF-8的两码元序列“110xxxxx 10xxxxxx”中的前缀码“110”和“10”恰好是彻底一致的；详见本系列文章中《刨根究底字符编码之十二——UTF-8到底是怎么编码的》一文的介绍)。

让咱们按照UTF-8的编码算法规则，将第一个字节的前缀码110去掉，获得“00001”，将第二个字节的前缀码10去掉，获得“101010”，将二者组合在一块儿，获得“00001101010”，再去掉多余的前导的0，就获得了“0110 1010"，这正好是Unicode字符集里的U+006A，也就是小写字母“j”的码点值。

同理，以后的第三个字节与第四个字节按一样的方法用UTF-8解码以后正好是Unicode字符集里的U+0368，这个字符为“ͨ”(抱歉，这里的左双引号貌似被这个字符所影响，看起来像是半角左双引号，而没法正常显示为全角左双引号)，很像是上标的一个小c，这应该是个组合字符(组合字符是Unicode字符集中的一种特殊字符，必须与其余字符组合在一块儿以造成一个新字符，通常不单独使用，可参看本系列文章前面相关文章中的介绍)。

这就是只有“联通”两个汉字的文本文件没有办法在记事本里被正确解码显示的缘由。这里要特别说明的是，在记事本里打开时显示的不是“j”和“ͨ”，而是显示为了“��ͨ”(注意右上角是“ͨ”)。

而用UltraEdit打开，若是在设置中选择了“自动检测UTF-8文件”，显示的是“j”和“ͨ”组合在一块儿的字符“jͨ”。注意这个字符不是小写字母“j”，而是小写字母“j”上面的点变成了一个上标的小c，由于U+0368这个字符“ͨ”应该是个组合字符，与其前面的小写字母“j”组合在一块儿而造成了一个新字符——jͨ(再次提醒注意小写字母“j”上面的点变成了“c”)。

（注意：在UltraEdit的早期版本中，没有“自动检测UTF-8文件”这一选项）

5.

这里还有一个问题：既然已经推断为了UTF-8，那为何Windows记事本仍是将前两个字节，亦即本来为“联”字的GB内码的那两个字节，显示为了“��”这样的乱码，而不是显示为小写字母“j”呢？

我想主要是由于小写字母“j”属于ASCII字符，在UTF-8编码中ASCII字符属于单字节编码，出如今双字节编码中是非正常的，于是被Windows记事本认为是错误编码，而UltraEdit则做了容错处理，仍然将其解读为了小写字母“j”。

然后两个字节，亦即本来为“通”字的GB内码的那两个字节，之因此Windows记事本将其按UTF-8编码的规则解读为了字符“ͨ”，那是由于字符“ͨ”的UTF-8编码正好就是双字节编码，所以按UTF-8编码的规则去解读的话不属于错误。

（笨笨阿林原创文章，转载请注明出处）

6.

其实，用记事本默认的编码方式(ANSI)分别单独保存“联”字和“通”字为两个独立的txt文件，则：

1) 再用记事本打开时，“联”字显示的是“��”，“通”字显示的是“ͨ”；

2) 用UltraEdit打开时，

　　(1) 若是选择了“自动检测UTF-8文件”，“联”字显示的是小写字母“j”，“通”字显示的“ͨ”(不过看不清，我开始还觉得是个空格)；

　　(2) 若是没有选择“自动检测UTF-8文件”，“联”字和“通”字均能正常显示(说明这种状况下UltraEdit正确地推断出了编码方式为GBK，从这一点来看，UltraEdit比Windows记事本要强)；

3) 用NotePad++打开时，

　　(1) 若是在“格式”中选择的是“以ANSI格式编码”(亦即显式地手动选择了正确的编码方式)，“联”字和“通”字均能正常显示；

　　(2) 若是编码方式选择的是UTF-八、UTF-8无BOM、UCS-2 Big Endian或UCS-2 Little Endian时，则“联”字均显示为“xC1xAA”(有意思的是，直接复制“xC1xAA”而后粘贴到Word里，则显示为了小写字母“j”)，“通”字均显示为“ͨ”。

而若是是用记事本默认的编码方式(ANSI)保存“联统统信”四个字，则用记事本、UltraEdit(即使选择的是“自动检测UTF-8文件”的状况下)打开后均可正常显示。

这充分说明，Windows记事本在文件头没有BOM的状况下，只能自行推断，因为“联通”两个汉字保存为ANSI编码方式时，内码只有四个字节，在信息不够充足的状况下(尤为是其内码又恰好符合了UTF-8的编码算法规则)，因而被错误地推断为了UTF-8编码方式；当以ANSI编码方式保存的是“联统统信”四个汉字时，内码有八个字节，这时信息较为充足，所以被正确地推断为了ANSI编码方式(在简体中文版Windows中ANSI编码默认为GBK编码)。

7.

上面分析的是Windows系统中采用ANSI编码时没有添加BOM的状况。那么，对于采用非ANSI编码时添加了BOM的状况，是否就万事大吉了呢？其实，添加BOM来标记字符编码表面看起来貌似不错，但实际上常常会带来麻烦，由于它和不少协议、规范并不兼容。

Windows里的软件在采用非ANSI编码时，即使对于根本不存在字节序问题的UTF-8编码默认也会添加BOM(详见以前文章《刨根究底字符编码之十一——UTF-8编码方式与字节序标记》的介绍)，而像Unix、Linux、Mac OS等*nix系统对于UTF-8编码都默认不添加BOM。

既然*nix系统均可以不添加BOM，那为何Windows系统却非要添加BOM呢？这极可能是由于Windows系统有大量普通用户使用，在必须兼容传统ANSI编码的状况下，从用户体验角度考虑而没有采用显式地要求用户手动选择字符编码方式的作法，所以特别依赖于经过BOM来防止隐式地自行推断字符编码方式而出错。

微软这种为了照顾广大普通用户而从用户体验角度出发“好心办坏事”的例子其实还有不少。

8.

所以，在Windows系统中，尽可能不要使用记事原本打开并编辑文本文件，尤为是做为程序员，应使用Notepad++或UltraEdit等更为专业的文本文件编辑软件。

这一方面是能够避免出现上述这样的“诡异”错误，另外一方面也是为了不Windows记事本“画蛇添足”地添加BOM(详见下面附文中的解释)，从而给在与其余系统(好比*nix系统)交流时带来没必要要的麻烦。

 

附：Windows记事本中对经常使用编码方式自行其是的“奇葩”命名

Windows记事本中，对经常使用编码方式的命名很是“奇葩”，微软这种自行其是的非标准命名，乍一看使人费解，现解释以下。

　　1） ANSI指的是对应当前系统区域设置(即系统locale)中的默认ANSI编码，不带BOM。在简体中文版Windows系统中默认ANSI编码指的就是GBK编码，即CP936，具体可参看前文《刨根究底字符编码之七——ANSI编码与代码页》。

　　2） Unicode指的是带有BOM的小端序UTF-16(即UTF-16LE with BOM)。

　　3） Unicode big endian指的是带有BOM的大端序UTF-16(即UTF-16BE with BOM)。

　　4） UTF-8指的是带有BOM的UTF-8(即UTF-8 with BOM)。UTF-8编码方式实际上并不存在字节序的问题，之因此仍然“画蛇添足”地添加BOM，应该是因为要兼容不添加BOM的ANSI编码，从用户体验角度考虑，避免用户显式地手动选择编码方式。

　　(注：若是UTF-8编码不添加BOM，则有两种不添加BOM的编码方式，从而致使隐式地自行推断编码方式更容易出错，上文所介绍的对“联通”推断出错便是明证。固然反过来也说明了Windows记事本对于不添加BOM的UTF-8编码其实一样是支持的，而并不是简单粗暴地直接提示错误，这应该是为了兼容*nix系统不添加BOM的作法而不得不采起的策略。只是这样一来，就很难避免陷入左右为难的困境。)

（笨笨阿林原创文章，转载请注明出处）

 

（未完待续）

 

https://zhuanlan.zhihu.com/p/86871840