在 PHP 开始或结束标记之前检查空行答案

【问题标题】：Checking for blank lines before PHP opening or closing tag在 PHP 开始或结束标记之前检查空行
【发布时间】：2020-05-28 19:19:31
【问题描述】：

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

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

【问题讨论】：

grep 如果您可以访问命令行并且在您的服务器上使用 unix，则该命令将执行此操作
我无法访问（也没有经验）我服务器上的命令行，但我在本地拥有所有文件（因此我可以在我的 Windows 环境中为文件运行任何命令）
您更喜欢使用 PHP 来执行此操作吗？
好吧，我有一个功能强大的 IDE (JetBrains phpStorm) 以及各种搜索和正则表达式搜索工具，所以也许正确的正则表达式足以确定原因。如果您有任何可用的 PHP 解决方案，也非常欢迎！
您能否提供一些外观示例数据？

标签： regex wordpress search blank-line

【解决方案1】：

我不这么认为

DOS/Windows 行终止符 - 回车 \r 加上换行符 \n 对，或
UNIX 行终止 - 仅换行 \n

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

我假设您已将文件创建为 UTF-8 编码文件，开头带有 byte order mark (BOM)。文本编辑器和 IDE 不显示 Unicode 编码文件的 BOM。

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

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

使用空字符串作为替换字符串应该会导致从所有文件中删除 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* ... 附加了零个或多个 whitespaces 的 UTF-8 BOM。

| ... 表示或。

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

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

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

【讨论】：

【解决方案2】：

这个问题通常出现在 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等，建议在每个阶段插入文件，看看是否解决问题。如果是这样，则意味着错误存在于该阶段，因此定位有问题的空白并修复它变得更加简单。这通常是解决问题的更好方法，而不是仅仅将文件插入到它可以工作的地方并将其留在那里，因为在这种情况下，问题并没有得到解决，而是得到了解决。

【讨论】：

【解决方案3】：

我在 Netbeans 中使用 "\?>\s*\Z" [删除引号] 来查找文件末尾的多余行。

诺埃尔

【讨论】：