BOM问题引发的页面上怪异现象的分析

这几天调试PHP时,遇见一个比较怪异的问题，对病症简单描述如下：

问题病症1：页面在IE7下刚加载时显示正常，但在点击一个链接后，新页面并没有加载css，只有手动刷新一次才能正常。

问题病症2：在浏览器顶端和页面内容之间有一个空格，在IE7和IE6下存在，在FF中并没有

**解决方案1：**在调用css样式的代码前加空的script标签对可解决问题1，但是因为没有根本性的解决问题，所以无法解决问题2。

**解决方案2：**用UltraEdit软件打开代码文件，（一般是包含的公用头文件），切换到16进制编码模式下，然后保存文件为无BOM格式，该方法为治本的良方,推荐之。

对了，问题就出在它身上，Unicode规范中有一个BOM的概念。BOM——Byte Order Mark，就是字节序标记。

GOOGLE一下BOM的说明：在UCS 编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的编码是FEFF。而FEFF在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来标记文本文件的编码方式的。

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的FFFE了。

很多软件都是通过BOM来识别这个文件是否是UTF-8编码的，可是，还是有很多软件不能识别BOM。如：在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5以后的版本已经开始支持BOM了，PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符，所以保存的时候请切换到16进制编码模式下，然后保存文件为无DOM格式。