记事本(notepad.exe)编码的解惑

---

前言

为什么将一个二进制文件用记事本读取后点击保存，或者用各种编码的另存，都无法存为原文件大小的文件，且以原二进制文件的打开方式再也无法打开。本期就是为了讨论这一问题，问题的核心就是文本编码。

一、为什么会出现记事本以各种编码的另存都无法存为原文件大小的文件，且以原二进制文件的打开方式再也无法打开的现象？

这个问题的关键是，对于记事本解读文件的编码方式的理解。
notepad，即记事本本身是一个文本文档解读的程序，不论底层各种编码方式的另存怎样，都要确保其解释出来的文本看起来是一样的。
因此，当用一串字节被以一种方式的解码让文本文档解读，又以同样的编码方式编码为另一串字节，这前后两串字节仅能保证文本形式看起来一样。实际上，底层却可能会出现差异。
下面的讨论会展开得明白起来。

二、记事本的默认解码方式

网上很多都会显示，记事本的默认编码方式是ANSI，在我们的环境中即GB2312，然后在特定区间单字节编码为ASCII。这样就中英双管齐下，齐全了。但实际上，还会遇到比如说，两个字节编码出来的一个日汉字，但在uncode编码方式中也无法对应其编码。
如下图所示，这里8852处被解码为了“圧”，在GB2312中实际上没有这个字。这也不在GB2312所编码的区间中，但却用了两个字节。


实际上，经过查询这应该是GBK或GB18030中编码方式的一种。如下图所示。

因此记事本的默认编码方式实际为GBK或GB18030中的一种。

三、为什么会不一样的解释

先对照两张截图，前一张是原始的二进制文件，后一张是解码为文本文档后再进行ANSI编码后的样子。

可以看到，0x00已被转为了0x20，记事本为0x00标识的空字符腾出了空的位置，但在编码为字节时，将这个空的位置当作了空格来编码。不过最后，在文本文档的显示中，这两者看起来一样。
然后可以看到，在两个图片分别展示的448个字节当中，最后已经有一个字节的错位了。
这是因为0xD7FF会被GB2312解码为?，而?又被GB2312编码为0x3F。因此少了一个字节。如下图所示。


还有很多诸如此类的现象，因此以ANSI编码存储时，文件占用的空间会小一点，且因为底层二进制字节的改变，再以二进制文件运行已无法成功。
以其他编码无法成功的原因也是这样。

---

总结

归根到底，会有记事本以各种编码的另存都无法存为原文件大小的文件，且以原二进制文件的打开方式再也无法打开的现象，就是因为，对于任何一种文本编码而言，其文本形式和底层字节不是一一对应的关系。一些底层字符对应文本形式一样，而相应文本形式解码的字节却只有一种。