我一直在读,在文件末尾使用PHP关闭标记?>是不好的做法。在下面的上下文中,头文件的问题似乎无关紧要(这是目前为止唯一一个好的参数):

现代版本的PHP在PHP .ini中设置了output_buffering标志 如果启用了输出缓冲,则可以在输出HTML后设置HTTP报头和cookie,因为返回的代码不会立即发送到浏览器。

每一本好的实践书籍和维基都以这个“规则”开始,但没有人提供好的理由。 还有其他好的理由跳过PHP结束标记吗?


当前回答

这不是标签……

但如果你有了它,你就有可能在它后面留下空白。

如果你把它作为一个包含在文档的顶部,你可能会在你试图发送HTTP头之前插入空白(即内容),这是不允许的。

其他回答

根据文档,如果关闭标记位于文件末尾,出于以下原因,最好省略它:

如果文件是纯PHP代码,最好省略文件末尾的PHP结束标记。这可以防止在PHP结束标记之后意外地添加空白或新行,这可能会导致不必要的影响,因为当程序员在脚本中不打算发送任何输出时,PHP将启动输出缓冲。

PHP手册>语言参考>基本语法> PHP标签

php代码有两种可能的用法:

PHP代码,如类定义或函数定义 使用PHP作为模板语言(例如在视图中)

在情形1中。关闭标签是完全没用的,我也想看到只有1(一个)php打开标签和NO(零)关闭标签在这种情况下。这是一个很好的实践,因为它使代码清晰,并将逻辑与表示分开。 对于表示情况(2.),有些人发现关闭所有标签(甚至是PHP处理的标签)是很自然的,这导致了混乱,因为PHP实际上有2个独立的用例,不应该混合在一起:逻辑/微积分和表示

这是一个新手编码风格的建议,出于善意,并由手册建议。

Eschewing ?> however solves just a trickle of the common headers already sent causes (raw output, BOM, notices, etc.) and their follow-up problems. PHP actually contains some magic to eat up single linebreaks after the ?> closing token. Albeit that has historic issues, and leaves newcomers still susceptible to flaky editors and unawarely shuffling in other whitespace after ?>. Stylistically some developers prefer to view <?php and ?> as SGML tags / XML processing instructions, implying the balance consistency of a trailing close token. (Which btw, is useful for dependency-conjoining class includes to supplant inefficient file-by-file autoloading.) Somewhat uncommonly the opening <?php is characterized as PHPs shebang (and fully feasible per binfmt_misc), thereby validating the redundancy of a corresponding close tag. There's an obvious advise discrepancy between classic PHP syntax guides mandating ?>\n and the more recent ones (PSR-2) agreeing on omission. (For the record: Zend Framework postulating one over the other does not imply its inherent superiority. It's a misconception that experts were drawn to / target audience of unwieldy APIs). SCMs and modern IDEs provide builtin solutions mostly alleviating close tag caretaking.

不鼓励使用?>结束标记只是延迟解释基本的PHP处理行为和语言语义,以避免不常见的问题。由于参与者的熟练程度不同,它对于协作软件开发仍然是实用的。

关闭标签的变化

The regular ?> close tag is also known as T_CLOSE_TAG, or thus "close token". It comprises a few more incarnations, because of PHPs magic newline eating: ?>\n (Unix linefeed) ?>\r (Carriage return, classic MACs) ?>\r\n (CR/LF, on DOS/Win) PHP doesn't support the Unicode combo linebreak NEL (U+0085) however. Early PHP versions had IIRC compile-ins limiting platform-agnosticism somewhat (FI even just used > as close marker), which is the likely historic origin of the close-tag-avoidance. Often overlooked, but until PHP7 removes them, the regular <?php opening token can be validly paired with the rarely used </script> as odd closing token. The "hard close tag" isn't even one -- just made that term up for analogy. Conceptionally and usage-wise __halt_compiler should however be recognized as close token. __HALT_COMPILER(); ?> Which basically has the tokenizer discard any code or plain HTML sections thereafter. In particular PHAR stubs make use of that, or its redundant combination with ?> as depicted. Likewise does a void return; infrequently substitute in include scripts, rendering any ?> with trailing whitespace noneffective. Then there are all kinds of soft / faux close tag variations; lesser known and seldomly used, but usually per commented-out tokens: Simple spacing // ? > to evade detection by PHPs tokenizer. Or fancy Unicode substitutes // ﹖﹥ (U+FE56 SMALL QUESTION MARK, U+FE65 SMALL ANGLE BRACKET) which a regexp can grasp. Both mean nothing to PHP, but can have practical uses for PHP-unaware or semi-aware external toolkits. Again cat-joined scripts come to mind, with resulting // ? > <?php concatenations that inline-retain the former file sectioning.

因此,对于强制的关闭标记省略,有依赖于上下文但实用的替代方法。

手动照看?>结束标记也不是很现代。一直都有自动化工具(即使只有sed/awk或regex-oneliners)。特别是:

Phptags标签更整洁 https://fossil.include-once.org/phptags/

通常可以用来为第三方代码打开php标签,或者只是修复任何(和所有)实际的空白/BOM问题:

Phptags——warn——whitespace *.php

它还处理——长标签转换等运行时/配置兼容性。

由于我的问题被标记为这个问题的重复,我认为可以发布为什么不省略结束标签?>可能是出于某些原因。

具有完整的处理指令语法(<?php……?>) PHP源代码是有效的SGML文档,可以用SGML解析器毫无问题地解析和处理。在附加的限制下,它也可以是有效的XML/XHTML。

没有什么可以阻止您编写有效的XML/HTML/SGML代码。PHP文档意识到了这一点。摘录:

注意:还要注意,如果要在XML或XHTML中嵌入PHP,则需要使用< ? PHP ?>标记以保持与标准兼容。

当然,PHP语法不是严格的SGML/XML/HTML,您创建的文档不是SGML/XML/HTML,就像您可以将HTML转换为XHTML以符合XML或不符合XML一样。

At some point you may want to concatenate sources. This will be not as easy as simply doing cat source1.php source2.php if you have inconsistency introduced by omitting closing ?> tags. Without ?> it's harder to tell if document was left in PHP escape mode or PHP ignore mode (PI tag <?php may have been opened or not). Life is easier if you consistently leave your documents in PHP ignore mode. It's just like work with well formatted HTML documents compared to documents with unclosed, badly nested tags etc. It seems that some editors like Dreamweaver may have problems with PI left open [1].

这不是标签……

但如果你有了它,你就有可能在它后面留下空白。

如果你把它作为一个包含在文档的顶部,你可能会在你试图发送HTTP头之前插入空白(即内容),这是不允许的。