今天在写php代码的时候，出现一个特郁闷的问题那就是两个一模一样的文件，在IE下显示有一个文件却出显了一个空白行，如地址所示http://www.kuomart.com/blog/my_ex/bom_utf8.htm
以上出现空白行的页面是用php的require('t.htm')导入模板输出的，而我的php文件和htm文件都是用的记事本写的，然后保存为utf-8编码的，这样之后就出现了用nodepad保存utf8文件自动添加bom到文件的开始，起先自己测试用nodepad,dw,edplus打开文件都看不到bom内容，而用windows写字板以及zend studio打开就可以看到bom字节的东西，由于一直对utf8没有深入的了解，只知道utf8可以表示很多种语言的编码，他通用三个字节表示一个字符，如gb码用两个字节表示一个汉字，而用utf8表示一个汉字，则一个汉字要占三个字节。但是对BOM却一无所知，最后实在无技可施便到csdn上求助，可是csdn上半天没一个高手能解决，也于我在web版发的问题版块发得不对吧（晕，我是WEB开发遇到的问题啊），无赖之下又在phpchina去发贴，终于得aultoale的帮助热心解答，如贴http://www.phpchina.com/bbs/thread-23423-1-1.html
在网上也找到以下详解
Wordpress中要注意的UTF-8的BOM问题
很早就遇到过一个问题，就是安装某个插件后，点激活后会出现白屏。一直没有搞明白是由于什么原因，以前的解决办法是，如果是不包含中文字符的，直接把文件转存成ASCII码方式，一般都能解决。今天给弟弟弄Blog的时候，又出现了这种情况。研究了半天，终于找到了答案。
Unicode规范中有一个BOM的概念。BOM——Byte Order Mark，就是字节序标记。在这里找到一段关于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来标记文本文件的编码方式的。
另外unicode网站的FAQ-BOM详细介绍了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的话，将会造成在页面上输出这三个字符，显示效果就要看浏览器了，一般是一个空行或是一个乱码。
在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”即可。请参考下面的图片：
根据Bo-Blog的wiki的说明：Editplus需要先另存为gb，再另存为UTF-8。不过这样做要小心，所有GBK编码中不包含的字符就会都丢了。如果有一些非中文的字符在文件里的话还是不要用这种办法了。(从这一个小方面来看，UE——UltraEdite-32确实比Editplus好很多，Editplus太轻量级了)
另外我发现了一个办法，就是利用Wordpress提供的文件编辑器。这个办法不受限制，不需要去下载专门的编辑器，毕竟大家都在用Wordpress嘛。先在ftp里把要编辑的文件的写入权限打开，然后进入Wordpress后台->管理->文件编辑器，输入要编辑文件的路径，点编辑文件。在显示出来的编辑界面中，你是看不到开头的那三个字符的，不过没关系，把光标定位在整个文件的第一个字符前，按一下Backspace键。OK了，点更新文件吧，在ftp里刷新一下，可以看到文件小了3字节，大功告成。
最后说一下，这是个大问题，所有要自己写插件的，编辑别人的插件自己用的，需要修改模版的(这条估计每个人都需要吧)，最好了解一下上面的知识，免得出现问题时不知所措。
官方网站信息如下http://www.unicode.org/faq/utf_bom.html?或者?PHP后面的代码才会作为PHP代码执行，所以这三个字符将会直接输出。如果插件的文件有这个问题，将会导致在后台页面里激活或者不激活插件后显示白屏，如果是模版文件有这个问题，将会导致这三个字符直接输出，造成页面上方有一个小空行。国外的英文插件和模版一般都是用的ASCII码的编码方式，不会有BOM，只有国内的插件和模版会由于作者的不知情造成问题。还有，大家修改模版的时候，由于输出页面使用UTF-8编码，那么修改模版的时候如果有加入中文字符的话，必须把文件转成UTF-8编码才能正常显示，这个时候如果所使用的编辑器自动加上了BOM的话，将会造成在页面上输出这三个字符，显示效果就要看浏览器了，一般是一个空行或是一个乱码。BR>