我一直在读,在文件末尾使用PHP关闭标记?>是不好的做法。在下面的上下文中,头文件的问题似乎无关紧要(这是目前为止唯一一个好的参数):
现代版本的PHP在PHP .ini中设置了output_buffering标志 如果启用了输出缓冲,则可以在输出HTML后设置HTTP报头和cookie,因为返回的代码不会立即发送到浏览器。
每一本好的实践书籍和维基都以这个“规则”开始,但没有人提供好的理由。 还有其他好的理由跳过PHP结束标记吗?
我一直在读,在文件末尾使用PHP关闭标记?>是不好的做法。在下面的上下文中,头文件的问题似乎无关紧要(这是目前为止唯一一个好的参数):
现代版本的PHP在PHP .ini中设置了output_buffering标志 如果启用了输出缓冲,则可以在输出HTML后设置HTTP报头和cookie,因为返回的代码不会立即发送到浏览器。
每一本好的实践书籍和维基都以这个“规则”开始,但没有人提供好的理由。 还有其他好的理由跳过PHP结束标记吗?
当前回答
不让结束语?>进入是非常有用的。
该文件对PHP是有效的(不是语法错误),正如@David Dorward所说,它允许避免在?>后面有空格/换行符(任何可以向浏览器发送头信息的东西)。
例如,
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10);
imagepng ( $img);
?>
[space here]
[break line here]
无效。
But
<?
header("Content-type: image/png");
$img = imagecreatetruecolor ( 10, 10 );
imagepng ( $img );
会的。
就这一次,为了安全,你必须偷懒。
其他回答
嗯,有两种方式来看待它。
PHP代码只不过是一组XML处理指令,因此任何具有. PHP扩展名的文件都只不过是一个恰好被解析为PHP代码的XML文件。 PHP恰好为它的打开和关闭标记共享XML处理指令格式。基于此,扩展名为.php的文件可能是有效的XML文件,但它们不一定是。
如果您相信第一种方法,那么所有PHP文件都需要结束标记。省略它们将创建一个无效的XML文件。然后,没有开口<?xml version="1.0" charset="latin-1" ?>声明,你将不会有一个有效的xml文件…所以这不是一个大问题……
如果你相信第二种方法,那么就会出现两种类型的.php文件:
只包含代码的文件(例如库文件) 包含原生XML和代码的文件(例如模板文件)
基于此,只有代码的文件可以在没有?>结束标记的情况下结束。但是XML代码文件不使用?>结束是不合适的,因为它会使XML无效。
但我知道你在想什么。你会想,这有什么关系,你永远不会直接呈现PHP文件,所以谁会关心它是否是有效的XML。如果您正在设计一个模板,那么这确实很重要。如果它是有效的XML/HTML,普通浏览器将不会显示PHP代码(它被视为注释)。所以你可以模拟出模板,而不需要运行PHP代码…
我不是说这很重要。这只是一个我不经常看到的观点,所以还有什么更好的地方来分享它呢?
就我个人而言,我不关闭库文件中的标签,但在模板文件中这样做…我认为这是基于个人喜好(和编码指南)的。
除了已经说过的所有内容之外,我还将提出另一个原因,这对我们的调试来说是一个巨大的痛苦。
Apache 2.4.6和php5.4实际上在我们的生产机器上,当关闭PHP标记后面有空白时,分割错误。我只是浪费了好几个小时,直到我终于用strace缩小了虫子的范围。
下面是Apache抛出的错误:
[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)
如果我正确理解这个问题,它与输出缓冲以及这可能对结束/结束标记的影响有关。我不确定这是一个完全合理的问题。问题是输出缓冲区并不意味着所有内容在发送到客户机之前都保存在内存中。意思是有些内容是。
程序员可以故意刷新缓冲区或输出缓冲区那么PHP中的输出缓冲区选项真的会改变结束标记对编码的影响吗?我认为不是这样的。
也许这就是为什么大多数答案都回到了个人风格和语法。
嗯,我知道原因,但我不能说出来:
对于只包含PHP代码的文件,永远不会出现结束标记(?>) 允许的。PHP并不要求它, 省略它可以防止 意外注入尾白 空格变成响应。
来源:http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
比正常进程更早地发送头文件可能会产生深远的后果。下面是我当时碰巧想到的其中一些:
While current PHP releases may have output buffering on, the actual production servers you will be deploying your code on are far more important than any development or testing machines. And they do not always tend to follow latest PHP trends immediately. You may have headaches over inexplicable functionality loss. Say, you are implementing some kind payment gateway, and redirect user to a specific URL after successful confirmation by the payment processor. If some kind of PHP error, even a warning, or an excess line ending happens, the payment may remain unprocessed and the user may still seem unbilled. This is also one of the reasons why needless redirection is evil and if redirection is to be used, it must be used with caution. You may get "Page loading canceled" type of errors in Internet Explorer, even in the most recent versions. This is because an AJAX response/json include contains something that it shouldn't contain, because of the excess line endings in some PHP files, just as I've encountered a few days ago. If you have some file downloads in your app, they can break too, because of this. And you may not notice it, even after years, since the specific breaking habit of a download depends on the server, the browser, the type and content of the file (and possibly some other factors I don't want to bore you with). Finally, many PHP frameworks including Symfony, Zend and Laravel (there is no mention of this in the coding guidelines but it follows the suit) and the PSR-2 standard (item 2.2) require omission of the closing tag. PHP manual itself (1,2), Wordpress, Drupal and many other PHP software I guess, advise to do so. If you simply make a habit of following the standard (and setup PHP-CS-Fixer for your code) you can forget the issue. Otherwise you will always need to keep the issue in your mind.
额外的:一些与这两个角色有关的陷阱(实际上目前只有一个):
甚至一些知名的库可能在?>之后包含多余的行尾。一个例子是Smarty,甚至是这两个版本的最新版本。*和3。*分支有这个。因此,与往常一样,要注意第三方代码。额外的奖励:一个用于删除不必要的PHP结尾的正则表达式:在所有包含PHP代码的文件中将(\s*\?>\s*)$替换为空文本。