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

今天我在写一个JS脚本的时候又出现了BOM事故。
我在页面中插入一个外部JS，然后里面有这样一句话$.getJSON(“/my/newmsg”,function(data){alert(data);});其它浏览器都能正常的弹出内容，唯独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来标记文本文件的编码方式的。