Unicode签名BOM引发的事故原因分析

Unicode签名BOM引发的事故原因分析 可能你这里用了包含(include)文件，通常header和footer会这么做。

打开被包含文件发现页面属性中“包括Unicode签名BOM”这一项是勾选的，那么我告诉你就是这个BOM引发的事故。

今天我在写一个JS脚本的时候又出现了BOM事故。

我在页面中插入一个外部JS，然后里面有这样一句话$.getJSON(“/my/newmsg”,function(data){alert(data);});其它浏览器都能正常的d出内容，唯独IE下没动静，我郁闷了近一个小时，我怀疑这句话写错了怀疑JSON数据格式错了怀疑我人品有问题…
后来我怀疑编码不对，于是就看到了可恶的BOM打了勾，把它一去掉神迹就从乌云底下冒了出来。

虽然我懒惰很少更新博客，但不得不上来记录一下这个事，因为真是太意外了，JS也会因为BOM引发事故 – -|

Unicode规范中有一个BOM的概念。

BOM是Byte Order Mark的简写，就是字节序标记，这个东西在普通文本编辑器下是看不到的，可以说它是文件头吗？在二进制编辑器下才可以看到？可能是这样。

在UCS 编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的编码是FEFF。

而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。

UCS规范建议我们在传输字节流前，先传输字符”ZERO WIDTH NO-BREAK SPACE”。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little- Endian的。

因此字符”ZERO WIDTH NO-BREAK SPACE”又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。

字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF。

所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。