使用 utf-8 编码来编写网页的时候， 往往会因为 bom (Byte Order Mark) 的问题，导致网页中经常出现一些不明的空行或者乱码字符。 这些都是因为 utf-8 编码方式对于 bom 不是强制的。因此 utf-8 编码在保存文件的时候，会出现不同的处理方式。比如有的浏览器(FireFox)可以自动过滤掉所有 utf-8 bom ， 有的 (IE) 只能过滤掉一次 bom （为什么是一次？ 当你出现 Include 多次文件时就会碰上这个问题了）。


使用editplus或其他编辑器删除掉文件中的BOM签名，重新刷新页面，样式正常了。

在这里找到一段关于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编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。我在研究Firefox的时候就知道，在Firefox早期的版本里，扩展是不能有BOM的，不过Firefox 1.5以后的版本已经开始支持BOM了。现在又发现，PHP也不支持BOM。

PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在<?或者<?php后面的代码才会作为PHP代码执行，所以这三个字符将会直接输出。如果插件的文件有这个问题，将会导致在后台页面里激活或者不激活插件后显示白屏，如果是模版文件有这个问题，将会导致这三个字符直接输出，造成页面上方有一个小空行。国外的英文插件和模版一般都是用的ASCII码的编码方式，不会有BOM，只有国内的插件和模版会由于作者的不知情造成问题。还有，大家修改模版的时候，由于输出页面使用UTF-8编码，那么修改模版的时候如果有加入中文字符的话，必须把文件转成UTF-8编码才能正常显示，这个时候如果所使用的编辑器自动加上了BOM的话，将会造成在页面上输出这三个字符，显示效果就要看浏览器了，一般是一个空行或是一个乱码。

以上就是【UTF-8 BOM 可能导致样式错乱的解决方法】的全部内容了,欢迎留言评论进行交流!