上善若水

最近又经常看到有询问 WordPress 在安装时候或者启用插件时遭遇错误的情况，很久很久以前我也遇到过类似的情况，在激活某个插件之后，整个页面瞬间就白了……其实这些都是某些文件在保存为 UTF-8 格式时候没有注意 BOM 的问题，根本解决方法就是不要使用太落后的编辑器，一般使用 Windows 自带的弱智记事本程序编辑的 PHP 文件基本都会自动加上 BOM 这东西，若是想在本地编辑 PHP 文件，还是建议使用先进点的编辑器，像是 EditPlus 之类的就行。昨天又有朋友询问这方面的问题，于是重新找了下资料，还是有一点收获的

Unicode 规范中有一个 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 编码了。

Windows 就是使用 BOM 来标记文本文件的编码方式的。

UTF-8 编码的文件中，BOM 占三个字节。如果用弱智记事本把一个文本文件另存为 UTF-8 编码方式之后，再用先进的 UltraEdit 打开此文件，然后切换到十六进制编辑状态就可以看到开头的 FFFE 了。这是个标识 UTF-8 编码文件的好办法，软件通过 BOM 来识别这个文件是否是 UTF-8 编码，很多软件还要求读入的文件必须带 BOM，不幸的是，还是有很多软件不能识别 BOM，最不幸的是，PHP 就不支持 BOM，于是乎，如果是 WordPress 主题出现 BOM，将会导致这三个字符直接输出，造成页面上方有一个小空行，如果是 WordPress 插件出现 BOM，将直接导致页面变白或者出现类似于下面的错误：

Warning: Cannot modify header information – headers already by (*************:1) in…….

据专家说明，受 COOKIE 送出机制的限制，在这些文件开头已经有 BOM 的文件中，COOKIE 无法送出（因为在 COOKIE 送出前 PHP 已经送出了文件头），所以登入和登出功能失效，一切依赖 COOKIE、SESSION 实现的功能全部失效。如果你遭遇了这样的问题，可以重新把你最近修改的那个文件弄出来，重新找个先进的编辑器重新存为不带 BOM 的 UTF-8 文件，推荐用 UE，我在用 Dreamweaver（不推荐用），就可以通过页面设置删去 BOM，如下图所示：

Dreamweaver 页面属性

另外，通过 WordPress 后台的编辑器修改文件是非常安全的，虽然简陋了点，难用了点……而且，一般说来，国外的插件和主题都是没什么问题的，他们大都采用 ASCII 编码，不存在 BOM 这方面的问题，只有自己修改为 UTF-8 之后才有可能出现 BOM 的问题。国人在写主题时候也要小心为妙，插件好像 I18N 之后这方面的问题也不怎么存在了……

还有好多情况下的白屏就不是由于编码问题了，比如发表文章时候白屏，就可能是由于可能是执行某个 PHP 的时候超时超内存了，从前在盘古时候，开启 Google Sitemap XML 插件就会出现这样的问题，有谁有这方面毛病的，自己检查下插件就好……