基本问题是，记事本（或其他基本文本编辑器）如何存储数据。我遇到这个是因为我试图比较不同压缩技术的文件大小，并意识到有些事情不太对劲。
详细说明..
如果我保存一个包含以下内容的文本文件：
a
文件是1个字节。这个恰好是 97，即 0x61。
我创建一个包含以下内容的文本文件：
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
即0-255，即0x00到0xFF的所有字符。 这个文件是 256 字节。每个字符 1 个字节。这对我来说很有意义。
然后我将以下字符附加到上述字符串的末尾。
†
上述字符串中未包含的字符。所有 8 位字符都已使用。这个字符是 8224，即 0x2020。一个 2 字节的字符。
然而，文件大小仅从 256 字节变为 257 字节。其实上面的字符自己保存只显示1个字节
我错过了什么？
编辑：请注意，在第二个文本块中，许多字符不会出现在这里。
在
ANSIANSIWindows-1252Windows Latin-1你应该看看
ANSI所以对于
†1340x86用一个字节来编码一个字符只在表面上有意义。如果你说英语还可以，如果你说中文或日语，那就太糟糕了。今天的 Unicode 定义了 110,187 个印刷符号，并且有空间增长到 110 万个。字节不是存储 Unicode 符号的好方法，因为它只能编码 256 个不同的值。
因此，文本编辑器在将文本存储到文件时必须始终对文本进行encode。需要编码才能将 110,187 个值映射到面向字节的存储介质上。如果你说中文，不可避免地每个字符需要超过 1 个字节。
常用的编码方案有很多很多。上个世纪流行的是code pages，一种使用字符集的方案。一种特定于语言的映射，通过选择语言中可能需要的 256 个字符，尽其所能地使每个字符只需要 1 个字节的存储空间。日文、韩文和中文因为不得不使用多字节映射，其他语言使用 1。
代码页是一场巨大的灾难，程序无法正确读取以另一种语言的代码页编码的文本文件。当文本文件靠近创建它的机器时，它就起作用了，尤其是互联网打破了这种用法。日语特别容易出现这种灾难，因为它有多个通用代码页。结果称为mojibake，用户在文本编辑器中查看乱码。 Unicode 于 1992 年问世，试图解决这场灾难。一个取代所有其他标准的新标准往往会引发另一种灾难。
你遭受了那种灾难，特别是如果你使用记事本。 尝试 与过去 30 年创建的文本文件兼容的程序。谷歌“布什隐瞒事实”的一个搞笑故事。请注意当您使用“文件”>“另存为”时出现的对话框，该对话框有一个名为“编码”的额外组合框。默认值是 ANSI，这是上个世纪的破旧名称，意思是“代码页”。正如您所发现的，该字符在您机器的默认代码页中确实只需要 1 个字节。看你住哪里，西欧和美洲是1252。如果你用十六进制查看器查看文件，你会得到 0x86。
鉴于对话框为您提供了选择，您应该not 不再喜欢 ANSI 的 mojibake，而是始终喜欢 UTF-8。也许他们有一天会更新记事本，所以它使用更好的默认值，很难做到。