这已经是 WordPress 2.6 小技巧系列的第3篇了，前面两次我们分别介绍了如何在 Windows 主机下继续使用永久链接，以及如何关闭如同鸡肋的文章版本管理功能。今天，我们再来给大家介绍一个新的问题, Cannot modify header information, 以及对应的解决方案。

在 WordPress 2.5 的时候，我们曾经专门介绍过这个问题。但是，在 WordPress 2.6 的时候，依然有网友存在类似的问题。不过对 WordPress 2.6 的时候，情况简单了很多，发生错误的文件主要集中在 wp-config.php 文件上。下面是网友 assad 留下的错误信息：

Warning: Cannot modify header information - headers already sent by (output started at /home/xxx/public_html/wp-config.php:1) in /home/xxx/public_html/wp-includes/pluggable.php on line 770

错误的由来：UTF 8 编码的困局

从上面的错误信息来看，是 wp-config.php 文件的第一行出现了问题。实际上是第一行被网友所使用的文本编辑器插入了一个看不见的字符，导致了这个错误。这个字符就是 UTF8 的标志。

绝大多数网友并不了解文件的编码问题，更不了解 UTF 8 编码；当然平时用不到，也确实没有了解的必要。这里我简单地给大家介绍一下 UTF8 编码。我们都知道，计算机使用编码系统来表示不同的字符集。比如最为基本的 ASCII 编码，共包括127个常用字符，可用于处理英语以及其他西欧语言。我们国家则采用 gb2312, gbk, 以及后来 gb18030 等编码系统来处理汉字。其他国家也都分别制定了相应的编码系统，来表示他们自己的文字。所有的这些编码系统，统称为 ANSI 编码。也就是说，在简体中文系统下，ANSI 编码代表简体中文 gb2312 编码；在日本操作系统下，ANSI 编码则代表其常用的编码。

这样，各个国家使用不同的文字，也就有不同的编码系统，不便交流弊病就诞生了。假如你在国内使用 gb2312 编码的系统，发了一封情意绵绵的 email 发给了远在美国留学的女友，如果她所使用的电脑没有 gb2312 编码系统的话，她所看到的将只是一篇乱码。

因此，为了解决全世界各种语言的编码问题，人们提出了 UNICODE 编码，支持全世界 650 多种语言。这样，全世界的计算机上都将安装上这一套编码系统，可以方便地支持不同语言进行书面交流。UTF 8 编码是 UNICODE 编码的一个分支；除了 UTF8 之外，UNICODE 还有 UTF 16, UTF 32 等各种不同的编码方式。

UTF 8 编码比较简单，因为它是用单字节作为编码单元；但是对于 UTF 16 和 UTF 32 而言，则分别使用双字节和四字节作为编码单元，这就涉及到一个编码顺序的问题。例如收到一个“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。那么对于 UTF 16 编码系统而言，4E59 究竟是“奎”还是“乙”？这就需要 BOM （Byte Order Mark）来标记字节顺序。

对于 UTF 8 而言，它只有一个字节，显然不必要使用 BOM 来标记字节顺序。但是 BOM 可以用来表明，这是一个 UTF 8 编码的文件。Windows 系统的记事本就喜欢在 UTF 8 文件里面添加一个 BOM 标记。但是，对于包括记事本在内的绝大多数编辑器而言，不管你是 UTF8 with BOM 还是 UTF8 no BOM 编码，都可以正常打开。

看起来晴空万里，但远处却飘来一朵乌云。如果所有的事情都像上面这样一帆风顺的话，那么也就没有必要絮絮叨叨说这么多了。问题的关键在于，WordPress 所使用的动态语言，PHP，在设计的时候没有考虑 UTF8 编码的问题。因此如果是 UTF 8 no BOM 的文件，它可以正常识别；但是如果遇到一个 UTF 8 with BOM 的文件，也就无法识别在文件开头的 BOM 标志。

中文版的疏忽与记事本的缺憾

对于 WordPress 而言，唯一可能需要用户修改的文件，就是 wp-config-sample.php 文件。这是 WordPress 重要配置文件，里面包含了 WordPress 的数据库信息，以及其他的一些参数。在官方发布的英文版中，这个文件使用的 ANSI 编码。但是在我们发布的 WordPress 中文版中，尽管该文件不涉及输出的中文信息，我们还是将这个文件和其他文件一起，保存成了 UTF8 no BOM 格式的文件。

这种格式本身并没有任何问题。但问题在于，大部分网友使用的编辑器，可能都是 Windows 操作系统所自带的记事本程序（Notepad.exe），而这个程序所支持的编码格式只有 ANSI, UTF8, Unicode 和 Unicode big endian 四种。因此，当用户修改为 wp-config-sample.php 文件，另存为 wp-config.php 文件的时候，原本的 UTF8 no BOM 格式，就是自动保存为 UTF8 ( with BOM )格式。记事本给文件自动添加 BOM （字节顺序标志），因此 wp-config.php 第一行就多出了一个 php 无法识别的标志，因此也就带来了上述的困扰。

受困扰的用户群和对应方案

从前面的分析来看，容易受到此问题迷惑的，主要是第一次安装 WordPress，并且使用记事本或者其他不区分 UTF8 with BOM 和 UTF8 no BOM 的编辑器保存 wp-config.php 的网友。而升级安装，以及通过在线填写数据库信息，自动生成 wp-config.php 文件的网友，则未受影响。

那么对于这个问题，我们也在这里提供几个不同的解决方案：

1. 使用 emeditor 或者其他能够区分 UTF8 with BOM 和 UTF8 no BOM 的编辑器，来编辑 wp-config.php 文件，将其保存为 UTF8 no BOM 编码格式；

2. 使用记事本或者其他无法区分 UTF8  with BOM 和 UTF8 no BOM 的编辑器，来编辑 wp-config.php 文件，将其保存为 ANSI 或者 gb2312 编码格式；

3. 如果你的主机支持写目录权限，那么也可以通过在线的方式，来自动生成 wp-config.php 配置文件。

当然，这个疏漏的最根本的原因，是我们在发布中文版的是时候有些自作聪明。虽然并非错误，却也给大家带来了不便，在这里我们向所有的 WordPress 用户道歉。我们也将在近期推出一个修正版，准备重新将 wp-config-sample.php 重新保存为 ANSI/gb2312 编码，彻底解决这个问题。