微软记事本所谓的“编码格式” 和文件头

记事本的“编码格式” 

实验发现，用记事本程序打开记事本创建的ANSI格式的文件，用ue 16进制查看，显示的确是ASCII码。但是，在记事本的ANSI格式下打开fatfs创建（非记事本创建）的文件时（文件中只有ASCII的字符），打开的是乱码！！

举例：

文件A：记事本创建的ANSI格式的文件，文件内容为“2010”

文件B：fatfs创建（非记事本创建）的文件，文件内容为“2010”

文件        ue 16进制显示                   WPS word显示            记事本ANSI格式下显示        经记事本ANSI格式显示后，ue 16进制显示  

A             0x32 0x30 0x31 0x30        2010                              2010                                      0x32 0x30 0x31 0x30   

B             0x32 0x30 0x31 0x30        2010                             乱码                                        乱码

引发的问题是：为什么记事本程序在ANSI格式下能正常显示他自己创建的ASCII文件，却错误显示非记事本创建的ASCII文件呢？

解答：http://www.zhihu.com/question/20650946#draft

其中摘录两个Answer，其他的见原网址 ↑ or 维基百科。

Answer 1：

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

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

• 所谓的「ANSI」指的是对应当前系统 locale 的遗留（legacy）编码。[1]  （ysmz4：问题的真正原因！！见注释[1]）
  
• 所谓的「Unicode」指的是带有 BOM 的小端序 UTF-16。[2]
  
• 所谓的「UTF-8」指的是带 BOM 的 UTF-8。[3]
  

GBK 等遗留编码最麻烦，所以除非你知道自己在干什么否则不要再用了。
UTF-16 理论上其实很好，字节序也标明了，但 UTF-16 毕竟不常用。
UTF-8 本来是兼容性最好的编码但 Windows 偏要加 BOM 于是经常出问题。

所以，跨平台兼容性最好的其实就是不用记事本。
建议用 Notepad++ 等正常的专业文本编辑器保存为不带 BOM 的 UTF-8。

另外，如果文本中所有字符都在 ASCII 范围内，那么其实，记事本保存的所谓的「ANSI」文件，和 ASCII 或无 BOM 的 UTF-8 是一样的。（ysmz4：文件头不一样，且字符占用字节数也不一样。）


阮一峰那篇〈字符编码笔记：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] 把带有 BOM 的小端序 UTF-16 称作「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」有什么区别？

Answer2:

其实前面他自己的回答已经很完善了。我补充一些细节就可以。

ANSI 确实是遗留编码，在不同语言的系统中编码不同，这一部分在微软的术语中叫 code page。比如所谓 GBK 编码，实际上更多地被叫做 CP936。这个术语是从 IBM 早期的一些工作中继承下来的，现在也没改变。但是，代码页这个概念在引入更大的字符集时已经遇到了问题，比如当初 GBK 扩展到 GB18030 时，它无法自然地用同一个代码页解决问题，不得不使用非常复杂的映射技术在几个代码页中切换才最终达到目的。

所谓微软的 Unicode，确实是 UTF-16LE。这个问题上 MSDN 文档在术语运用上有很多前后矛盾的地方，所以很多程序员都不太了解。再加上微软 SDK 默认的 WCHAR 是两个字节，进一步加剧了混乱程度。事实上时至今日，微软的默认编码不一定是两字节了，因为 Unicode 早已超过了 65536 个字符。

如果是为了跨平台，那么最有效的办法确实是坚持使用 UTF-8。不过是否使用 BOM 则未必真的需要很纠结。事实上现代的编辑器都可以很好地处理 BOM，比如 VIM。在 UNIX 环境下不适合使用 BOM 的场合有两个：一个是 XML，另一个是老旧的 shell 脚本。前者是因为规范里就没有 BOM 的位置，而后者则是因为历史原因而不能很好支持。而更大范围内的应用，比如 Python 脚本，则可以很好地处理 BOM。

——————————————————————————————————————————————————————————————————

微软记事本的文件头

http://blog.csdn.net/xmsheji/article/details/6954973                                    

字符编码                                             文件头           数字     数字编码             汉字          汉字编码

utf-8(有三个Byte):                       EF BB BF     1       0x31                  我          0xE6 0x88 0x91      

 

Unicode(二个Byte):                    FF FE            1      0x31 0x00          我          0x11 0x62

 

Unicode-Big endian(二个Byte)    FE FF           1      0x00 0x31          我          0x62 0x11

 

ANSI:无文件头标记                          无             1      0x31                   我          0xCE 0xD2