utf-8的bom问题及解决方案（转贴）

问题症状 :含有 bom的 uft-8文件在 ie中源代码中会生成 ?

EditPlus通过设置可完美解决开发中因为 utf-8编码引起的 bom问题

另附上扫描指定目录下含有 bom的 utf-8文件并删除的代码

 

 

UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可 以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带 BOM。可是，还是有很多软件不能识别BOM。我在研究Firefox的时候就知道，在Firefox早期的版本里，扩展是不能有BOM的，不过 Firefox1.5以后的版本已经开始支持BOM了。现在又发现，PHP也不支持BOM。
PHP在设计时就没有考虑BOM的问题，也就是说他不 会忽略UTF-8编码的文件开头BOM的那三个字符。由于必须在<?或者<?php后面的代码才会作为PHP代码执行，所以这三个字符将会直 接输出。如果插件的文件有这个问题，将会导致在后台页面里激活或者不激活插件后显示白屏，如果是模版文件有这个问题，将会导致这三个字符直接输出，造成页 面上方有一个小空行。国外的英文插件和模版一般都是用的ASCII码的编码方式，不会有BOM，只有国内的插件和模版会由于作者的不知情造成问题。还有， 大家修改模版的时候，由于输出页面使用UTF-8编码，那么修改模版的时候如果有加入中文字符的话，必须把文件转成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”即可。请参考下面的图片：




PHP版UTF-8文件BOM自动检测移除程序

BOM信息是文件开头的一串隐藏的字符，用于让某些编辑器识别这是个UTF-8编码的文件。但PHP在读取文件时会把这些字符读出，从而形成了文件开头含有一些无法识别的字符的问题。

比如用UTF-8格式保存的生成图片的PHP文件，因为文件头隐藏的BOM信息也被下发，导致生成的图片数据不对，浏览器无法识别。

要检测一个UTF-8文件是否含有BOM信息，就是检测文件开头的字三个符，是否为0xEF, 0xBB, 0xBF。

 

软件	默认新建时是否包含 bom	打开含有 bom 文件默认处理
Zend Studio5.5	×	不处理，可手动删除
EditPlus2.31	×	多种设置 ,可自动删除
Dreamweaver8	×	不处理
UltraEdit13.10	√	不处理，另存时可选删除