2

我的 WordPress 网站出现错误（XML 解析错误），因为<DOCTYPE>. 这可能是由 PHP 开始标记之前<?php或结束标记之后的主题或插件文件之一中的空行引起的?>。我已经检查了一些文件（主题index.php、、和一些插件） header.php，functions.php但没有找到原因。

是否有一个聪明的技巧来检查所有文件在 php 标签之前或之后是否有任何空行？也许一些正则表达式？或者以其他方式检查哪个主题文件或插件文件输出此行的任何方法？

4

3 回答 3

4

我不认为那只是

  • DOS/Windows 行终止 - 回车\r加上换行\n对，或
  • 一个 UNIX 行终止符 - 只有一个换行符\n

文件顶部是问题。这些空白字符通常会被忽略。

我想您已将文件创建为开头带有字节顺序标记(BOM) 的UTF-8 编码文件。文本编辑器和 IDE 不显示 Unicode 编码文件的 BOM。

UTF-8 BOM 是 0xEF 0xBB 0xBF，如果文本编辑器会显示它们，则使用 Windows-1252 代码页显示为 。文本编辑器 UltraEdit 允许在使用File - Open并在文件打开对话框中选择ASCII on Open 作为选项以将 UTF-8 编码文件打开为 ASCII/ANSI 文件时覆盖自动 Unicode 检测。在文本编辑模式下也可以看到带有 BOM 的 UTF-8 编码的 Unicode 文件开头的 UTF-8 BOM。

查找顶部带有 UTF-8 BOM 的文件的一个非常简单的搜索是搜索包含字符串的文件。或者，如果您不想依赖代码页，请使用表达式运行 Perl 正则表达式搜索\xEF\xBB\xBF。

使用空字符串作为替换字符串应该会导致从所有文件中删除 UTF-8 BOM。

\R可用于匹配 DOS/Windows 或 UNIX 或 MAC 行终止。换句话说\R，等于(?:\r\n|\n|\r)或更短(?:\r?\n|\r)

但是，由于我的字节顺序标记怀疑，我建议用作搜索字符串

(?:\xEF\xBB\xBF\s*|\s+)(?=<\?php)

解释：

(?:... )... OR 表达式的非标记组。

\xEF\xBB\xBF\s*...附加了零个或多个空格的 UTF-8 BOM。

|... 表示或。

\s+...一个空格字符一次或多次。

(?=<\?php)...一个积极的前瞻来检查下一个字符是否<?php没有真正匹配它们。

该搜索字符串不限于文件的开头。但也许它仍然足以满足您的需要，找到带有 UTF-8 BOM 或 PHP 文件开头有空行的文件。

于 2014-12-07T15:42:11.660 回答
1

通常，此问题出现在 Wordpress 生成的 XML 文档中，例如 RSS 和 atom 提要以及 XML 站点地图。在这种情况下，该错误不是 UTF-8 文档中的异常 BOM，而是由于 PHP 倾向于将关闭“？>”之后的所有内容视为要发送到输出的数据而导致的问题。结束 '?>' 标记之后的空行将被解释为将 LF 发送到输出文档的指令。如果这发生在文档本身被缓冲之前，则结果是一个 XML 文档，在 xml 声明之前有一个 LF（空行），从而使其无效 XML。当您在浏览器中检查 xml 输出时，您将看到类似这样的内容：

此页面包含以下错误：

第 2 行第 6 列的错误：仅在文档开头允许 XML 声明

推荐的解决方案是查看 Wordpress 主题中的所有 PHP 文件，查看是否存在任何关闭的 '?>' PHP 标记后有换行符或回车符，然后将其删除以进行修复。不幸的是，考虑到主题中的文件数量以及核心 Wordpress 安装，这说起来容易做起来难，其中任何一个都可能存在错误。

我最初的解决方案是一个小的 Perl 脚本，它检查 /usr/share/wordpress 下的每个 PHP 文件是否存在这个问题。然而，我后来在http://wejn.org/stuff/wejnswpwhitespacefix.php.html找到了 Michal "Wejn" Jirků 的一个非常优雅的纯 PHP 解决方案，以及由 Eric Auer 提供的其他调试信息。作者提供了一个小脚本 (wejnswpwhitespacefix.php)，该脚本在调用时将自身插入到输出链中，并解析传递给它的所有内容以获取有效标题。如果找到有效内容，脚本会通过调用 ob_start() 创建一个新的 PHP 输出缓冲区，并缓冲此内容以供最终输出。这个解决方案的关键是 PHP ob_start 函数，它在调用时会创建一个新的输出缓冲区。PHP 输出缓冲区是可堆叠的并且是嵌套的，因此实际输出按照缓冲区的创建顺序发生。如果内容无效，例如单个换行符，则会被拒绝。

因为实际的额外 LF 错误可能发生在从主题自己的 PHP 文件（通常是 functions.php）到 index.php 的输出链中的任何地方，或者在链上到核心 WP 文件，例如 wp-settings.php、wp-config .php、wp-load.php 等，建议在每个阶段插入文件，看看是否解决问题。如果是这样，则意味着错误存在于该阶段，因此定位有问题的空白并修复它变得更加简单。这通常是解决问题的更好方法，而不是仅将文件插入到可以工作的地方并将其保留在那里，因为在这种情况下，问题并没有得到解决，而是得到了解决。

于 2015-07-28T23:20:29.787 回答
0

我在 Netbeans 中使用 "\?>\s*\Z" [删除引号] 在文件末尾找到额外的行。

诺埃尔

于 2020-05-28T11:19:31.543 回答