令人纠结BOM

什么是BOM？Bill of Material？不是！这里说的BOM是Byte Order Mark，也就是字节序标记，在UTF-16里本来是FF FE，变成UTF-8就成了EF BB BF。这个标记是可选的，因为UTF-8字节没有顺序，所以它可以被用来检测一个字节流是否是UTF-8编码的。微软做这种检测，但有些软件不做这种检测，而把它当作正常字符处理。

也就是说一个UTF-8文件可能有BOM，也可能没有BOM，那么怎么区分呢？三种方法。1，用 UltraEdit-32打开文件，切换到十六进制编辑模式，察看文件头部是否有EF BB BF。2，用Dreamweaver打开，察看页面属性，看“包括Unicode签名BOM”前面是否有个勾。3，用Windows的记事本打开，选择 “另存为”，看文件的默认编码是UTF-8还是ANSI，如果是ANSI则不带BOM。

说了这么多，为什么说bom令人纠结呢？问题在于就在于wordpress使用的是php语言，而PHP在设计时就没有考虑BOM的问题，也就是说他不会忽略UTF-8编码的文件开头BOM的那三个字符。于是问题就出现了，要么网页上会出现乱码，要么会显示空白或者错位，像前段时间我的分文网在ie6下首页就不居中显示。不过在火狐等浏览器下去显示正常，这是因为火狐可以自动过滤掉所有utf-8 bom，而ie在这方面就差强人意了。

问题的原因是找到了，因为部分php代码中含有字符，所以才会出现乱码或空白的情况，从而导致在进行w3c验证时会出现这样的警告：

Byte-Order Mark found in UTF-8 File.

网上流传的解决方法多是利用EditPlus编辑器删除其中的bom签名即可或者利用Notepad++编辑器另存文件时选择utf-8 without bom也行。不过此法的弊端是需要查看每个php文件，因为不清楚到底是哪个文件出现了问题。当然如果清楚的话，那就简单多了，逐个检查修改即可。

回到我的分文网站，在沉寂了N天之后，终于在林西老九童鞋的帮助下，顺利解决了网站首页及其他页面的bom乱码及错位。（不过后台编辑页面好像还是有问题，可见我修改的文件太多了，甚是后悔啊。）当然采用的方法是利用php判断并自动去除bom，相比之下，工作量要轻松得多了。

另外还学到一些编码的小知识：所谓的unicode保存的文件实际上是utf-16，只不过恰好跟unicode的码相同而已,但在概念上unicode与utf是两回事，unicode是内存编码表示方案，而utf是如何保存和传输unicode的方案。utf- 16还分高位在前 (LE)和高位在后(BE)两种。官方的utf编码还有utf-32，也分LE和BE。非unicode官方的utf编码还有utf-7，主要用于邮件传输。utf-8的单字节部分是和iso-8859-1兼容的，这主要是一些旧的系统和库函数不能正确处理utf-16而被迫出来的，而且对英语字符来说，也节省保存的文件空间（以非英语字符浪费空间为代价）。在iso-8859-1的时候，utf8和iso-8859-1都是用一个字节表示的，当表示其它字符的时候，utf-8会使用两个或三个字节。