UTF-8 BOM可能导致样式错乱的解决方法

UTF-8 是一种在web应用中经常使用的一种 unicode 字符的编码方式，使用 UTF-8 的好处在于它是一种变长的编码方式，对于 ANSII 码编码长度为1个字节，这样的话在传输大量 ASCII 字符集的网页时，可以大量节约网络带宽。

使用 UTF-8 编码来编写网页的时候， 往往会因为 bom (Byte Order Mark) 的问题，导致网页中经常出现一些不明的空行或者乱码字符。最近在做一个项目的时候， 出现了一个很奇怪的现象就是在火狐、Chrome等浏览器下页面都是正常的，但是在IE下面所有的页面都居左了，而且有些地方显示不太正常。

类似这些可能存在的问题都是因为UTF-8 编码方式对于 bom 不是强制的。因此 UTF-8 编码在保存文件的时候，会出现不同的处理方式。比如有的浏览器(FireFox)可以自动过滤掉所有 UTF-8 bom ， 有的 (IE) 只能过滤掉一次 bom （为什么是一次？ 当你出现 Include 多次文件时就会碰上这个问题了）。

UTF-8 BOM

UTF-8 BOM又叫UTF-8 签名,其实UTF-8 的BOM对UFT-8没有作用,是为了支援UTF-16,UTF-32才加上的BOM,BOM签名的意思就是告诉编辑器当前文件采用何种编码,方便编辑器识别,但是BOM虽然在编辑器中不显示,但是会产生输出,就像多了一个空行，而具体的显示效果就要看浏览器了。

关于UTF8文件中的BOM头

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

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UltraEdit打开这个文件，切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。我在研究Firefox的时候就知道，在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5以后的版本已经开始支持BOM了。现在又发现，PHP也不支持BOM。

PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在文件有这个问题，将会导致这三个字符直接输出，造成页面上方有一个小空行，显示效果就要看浏览器了，一般是一个空行或是一个乱码。如果使用的是ASCII码的编码方式，不会有BOM，也就不会存在所说的问题。

常用文本编辑器

几个常用的文本编辑器对BOM的处理办法是：
1） notepad ： 可以自动识别出没有带 bom 的 utf-8 编码格式文件，但不可以控制保存文件时是否添加 bom ， 如果保存文件，那么会统一添加 bom。
2） editplus ： 不能自动识别出没有 bom 的 utf-8 编码格式文件，文件保存时，选择UTF-8 格式，不会在文件头写上 BOM header。
3） NotePad++： 可以自动选择字符编码的方式。
4） UltraEdit ： 对于字符编码的功能最为强大， 可以自动识别带 bom 和不带 bom 的 utf-8 文件 （可以配置） ； 保存的时候可以通过配置选择是否添加 bom。
所以碰到类似的问题时，将出现问题的页面文件用UltraEdit打开，另存为“UTF-8 无 BOM”格式就可以了。

或者使用Notepad++，选择“格式--以UTF-8无BOM格式编码”即可。