bom——byte order mark，就是字节序标记
在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编码了。
utf- 8编码的文件中，bom占三个字节。如果用记事本把一个文本文件另存为utf-8编码方式的话，用ue打开这个文件，切换到十六进制编辑状态就可以看到开 头的fffe了。这是个标识utf-8编码文件的好办法，软件通过bom来识别这个文件是否是utf-8编码，很多软件还要求读入的文件必须带bom。可 是，还是有很多软件不能识别bom。
在firefox早期的版本里，扩展是不能有bom的，不过firefox 1.5以后的版本已经开始支持bom了。现在又发现，php也不支持bom。php在设计时就没有考虑bom的问题，也就是说他不会忽略utf-8编码的文件开头bom的那三个字符。
由 于必须在在bo-blog的wiki看到，同样使用php的bo-blog也一样受到bom的困扰。其中有提到另一个麻烦：“受cookie送出机制的限 制，在这些文件开头已经有bom的文件中，cookie无法送出（因为在cookie送出前php已经送出了文件头），所以登入和登出功能失效。一切依赖 cookie、session实现的功能全部无效。”这个应该就是wordpress后台出现空白页面的原因了，因为任何一个被执行的文件包含了bom， 这三个字符都将被送出，导致依赖cookies和session的功能失效。
解决的办法嘛，如果只包含英 文字符(或者说ascii编码内的字符)，就把文件存成ascii码方式吧。用ue等编辑器的话，点文件->转换->utf-8转 ascii，或者在另存为里选择ascii编码。如果是dos格式的行尾符，可以用记事本打开，点另存为，选ascii编码。如果包含中文字符的话，可以 用ue的另存为功能，选择“utf-8 无 bom”即可。
utf-8本来就不应该加bom，除了 让编辑器知道它是个utf-8之外什么用处都没有。实际上编辑器完全有能力在不太多的几个编码格式之间根据特征来判断一个文件是什么编码，就算不能自动识 别，编辑器也应该有设置编码的地方。所以我觉得bom对于utf-8来说是多余的东西。
utf-16才需要加bom。因为它是按unicode顺序编码，在bmp范围内是二字节，需要识别是大或小字节序。
实 际上，我觉得utf-8引入大小字节序的概念太愚蠢了，不知道那些标准委员会是怎么想的。大小字节序存在的意义，在于cpu的处理方式。如果cpu是大字 节序处理，那么对于小字节序，就必须做一层转换，这带来了效率上的下降。但是在实际应用里，谁会去关心大小字节序？文本编码引起字节序的概念，只能说那些 制定标准的人太死板了。对于utf-16，我认为只要全世界都遵循一种字节序方式，那就没什么必要用bom来标注了。
话说回来，php是不支持utf-16编码的文件的。因为例如$这个符号，在utf-8里也是两个字节，php解码器无法解析的。不知道php6内部处理引入unicode 的概念之后，对这个是否会有支持。
编 码问题是一个说起来简单，但是实际上很繁琐的东西。很多程序，都有分层编码的概念。像mysql，就分为 client->connection->storage和storage->connection->result这些概念。 storage又分为system,database,table,column。我有时候在想，有必要搞这么复杂嘛，tnnd。像mysql，谁用利用 它这些特性阿？除非允许两个client在不同的编码环境下运作，否则它把client编码分离出来根本没有什么必要。大多数情况下，直接binary in/binary out就好了
以上就介绍了utf-8与utf-8无bom的区别 ，包括了方面的内容，希望对php教程有兴趣的朋友有所帮助。