当前位置:首页 >> 网页制作

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

可能你这里用了包含(include)文件,通常header和footer会这么做。打开被包含文件发现页面属性中“包括Unicode签名BOM”这一项是勾选的,那么我告诉你就是这个BOM引发的事故。

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来标记文本文件的编码方式的。