文本文件中出现的奇怪现象解析

蝎子

David Cumps曾经发现了这样一个现象：有些文本文件在记事本中会显示出奇怪的字符。

这一现象的原因是：记事本在尝试打开文本文件的时候，它必须在内部处理很多不同的字符编码，当出现一种编码它无法处理的时候，它不得不进行猜测。

举个例子

下面我们以”Hello”这一字符串来进行举例。

传统的ANSI编码：

48 65 6C 6C 6F

Unicode字符集(小端，Little-endian)，并且没有BOM：

48 00 65 00 6C 00 6C 00 6F 00

Unicode字符集(小端，Little-endian)，并且有BOM，前面的这个字节叫做BOM(FF FE)：首先，它表明这个文件是一个Unicode文本文件，然后，这两个字节的摆放顺序则表明这个文件的格式是小端。

FF FE 48 00 65 00 6C 00 6C 00 6F 00

Unicode字符集(大端，Big-endian)，并且没有BOM，请注意，记事本不支持这种编码：

00 48 00 65 00 6C 00 6C 00 6F

Unicode字符集(大端，Big-endian)，并且有BOM，请注意，前面两个字节的BOM的排列顺序和小端刚好相反：

FE FF 00 48 00 65 00 6C 00 6C 00 6F

UTF-8编码格式，前面三个字节表明这是一个UTF-8文本文件：

EF BB BF 48 65 6C 6C 6F

UTF-7编码格式，前面5个字节是UTF-7的BOM标识。记事本不支持这种格式。

2B 2F 76 38 2D 48 65 6C 6C 6F

请注意，UTF-7的BOM的字符串表示为：”+/v8-“。

有些文本文件可能恰好以这种字符串开头，虽然这比较罕见，但是，记事本确实不能区分这两种情况。

记事本支持没有任何BOM的传统ANSI编码和不带BOM的Unicode字符编码，当记事本打开一个没有特殊前缀的文本文件时，它不得不进行猜测文本文件实际使用的编码格式。

在Win32 API中有一个专门的API可以用来进行这种判断：IsTextUnicode。

这个API会读取文件的前面几个字节，然后根据一定的统计逻辑分析进行猜测。

就如这个API文档所描述的：凡事没有绝对，此API的猜测结果不保证一定是对的。

如果文本文件的内容很短，则很有可能，它的猜测结果是错误的。

总结

的确，凡事没有绝对，编程系（粤语表情），做人都系（再次粤语表情）。

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。

本文来自：《Some files come up strange in Notepad》