带bom的utf8php文件偶尔出现乱码的问题..

有没有人遇到过类似的情形呢？

因为不是一直出现，而且尝试过最简单的代码也出问题，就没往代码方面去想，一直在纠结是不是php扩展出了问题。

后来同事把bom去掉就好了，惊喜之余更多的是郁闷。。。太丢人了

虽然问题解决了，但具体是什么原因呢？

回复内容：

有没有人遇到过类似的情形呢？

因为不是一直出现，而且尝试过最简单的代码也出问题，就没往代码方面去想，一直在纠结是不是php扩展出了问题。

后来同事把bom去掉就好了，惊喜之余更多的是郁闷。。。太丢人了

虽然问题解决了，但具体是什么原因呢？

Unicode是唯一的，但Unicode的编码方式不是唯一的。编码方式可能是唯一的，但大端小端在前还不一定是唯一的。光说打开一个“Unicode”文件，其实不太容易做。

BOM就是把一个Unicode保留字符U+FEFF，按照文件存储者的编码方式编码后，塞到文件内容的最前边。这样用不同的Unicode编码去解析文件头，就可以得知文件的编码方式和大小端顺序。结果就是文件头部多出来了两三个字节。

有了BOM所有的程序都必须为BOM作出修改，这无疑是一个“大折腾”的行为。所以一般不认为BOM是个好主意。BOM引发的问题，我能想起来两个：

• PHP无法指定header（因为有BOM相当于开启输出）
• UNIX可执行脚本的Shabang标记（#!）不能识读

任何时候都采用无BOM的UTF-8编码的Unicode，绝对是一个引发麻烦最少的最实用策略。UTF-8是Unicode的最佳实践，没有之一。

必须指出的是，何弃疗的微软经常做出非要DOM不可的行为，最典型的例子就是那个记事本（存盘就加DOM）。所以任何时候，都千万别偷懒用记事本编辑PHP。华语骄傲Notepad++是Windows下的不二之选。

永远不要忘记：微软是技术落后，并且只会对超过自己的开源界冷嘲热讽，从不肯真正改正自己问题的业界毒瘤。话下的狠了点，不过就算没到这程度，也差不了多少。从一点一滴开始远离微软，让生活变得轻松些。

BOM: Byte Order Mark

UTF-8 BOM 又叫 UTF-8 签名，其实 UTF-8 的 BOM 对 UFT-8 没有作用，是为了支援 UTF-16，UTF-32 才加上的 BOM ，BOM 签名的意思就是告诉弱编辑器（记事本）当前文件采用何种编码，方便编辑器识别。

PHP 在设计之初，没有考虑到 BOM 头的问题，因此很容易因为 BOM 头引发诡异的问题，比如编码转换失败，样式错乱等等问题，而且此问题相当隐蔽，很难确定发生问题的文件（试想在没有工具的情况下从上万的工程文件中找到哪个文件带有 BOM 头）。

BOM 头是隐藏字符，非编辑字符，就像普通空文件一样，当我们写

{BOM头}

当 file.php 被其他文件包含时，由于 BOM 头在 php 标签外，会当作输出内容输出到浏览器，然后引发问题。

少年，珍爱生命，远离 BOM 。

一般的编辑器，是侦测不到utf8+bom的， 诸如记事本、写字板等等。 须使用editplus、ultraedit等文本编辑器进行侦测， 然后另存为utf8 no bom格式。

出现问题的原因可能是您用过记事本类的弱文本编辑器编辑过。