是否可以使用PHP短标记?

不推荐使用它们,因为如果您必须将代码移动到不受支持的服务器上(并且您不能启用它),那么它就是一个pita。正如您所说,许多共享主机 做 支持短标签,但“很多”不是全部。如果您想共享脚本,最好使用完整的语法。

我同意 <? 和 <?= 对程序员来说比 <?php 和 <?php echo 但是,只要每次使用相同的表单,就可以进行批量查找和替换(并且不要将其放在空格中(例如: <? php 或 <? = )

我根本不买可读性作为理由。大多数严肃的开发人员都可以选择突出显示语法。

正如提夫马斯特在评论中提到的, as of PHP 5.4, <?= ... ?> tags are supported everywhere, regardless of shorttags settings . 这应该意味着在可移植代码中使用它们是安全的,但这也意味着对php 5.4+有依赖性。如果你想支持5.4之前的版本,并且不能保证短标签,你仍然需要使用 <?php echo ... ?> .

另外,你需要知道 ASP tags <% , %> , <%= , and script tag are removed from PHP 7 .因此,如果您希望支持长期的可移植代码,并且希望切换到最现代的工具,请考虑更改代码的这些部分。

我太喜欢 <?=$whatever?> 放手吧。从来没有问题。我会一直等到它咬到我的屁股。认真地说,85%的(我的)客户机可以访问 稀有的 有时它们被关闭。另外15%的用户使用主流主机提供商,几乎所有的主机提供商都启用了它们。我爱Em。

从php 5.4开始,echo快捷方式与短标记是一个单独的问题,因为echo快捷方式将始终处于启用状态。事实是:

• SVN Revision by Rasmus Lerdorf
• Mailing list discussion

所以回声捷径本身( <?= )现在可以安全使用。

整个讨论的问题在于使用PHP作为模板语言。没有人认为标签应该在应用程序源文件中使用。

然而,PHP的可嵌入语法允许它作为一种强大的模板语言使用,模板应该尽可能简单易读。许多人发现使用更慢的附加模板引擎(比如smarty)更容易,但是对于我们中那些要求快速呈现和纯代码库的纯粹主义者来说,PHP是编写模板的唯一方法。

反对使用短标记的唯一有效理由是,并非所有服务器都支持短标记。关于与XML文档冲突的注释是可笑的,因为您可能无论如何都不应该混合使用PHP和XML;如果是这样,则应该使用PHP输出文本字符串。安全性永远不应该是一个问题,因为如果您将敏感信息(如数据库访问凭据)放在模板文件中,那么,您就遇到了更大的问题!

现在,对于服务器支持的问题,必须认识到它们的目标平台。如果共享宿主是一个可能的目标,那么应该避免使用短标记。但是对于许多专业开发人员(比如我自己),客户机承认(实际上,这取决于事实),我们将口述服务器需求。通常我自己负责设置服务器。

而且,我们从不与一个没有给我们绝对控制服务器配置的宿主提供者合作——在这种情况下,我们可以指望运行会遇到更多的麻烦,而不仅仅是失去短标记支持。这是不可能的。

所以是的——我同意使用短标签应该仔细权衡。但是我也坚信它应该永远是一个选项,并且一个了解环境的开发人员应该可以自由地使用它们。

由于 Zend Framework 推“ PHP as a template language 在他们 default MVC configuration . 我不明白这是怎么回事,你一生中生产的大多数软件都会在你或你的公司控制的服务器上运行。只要你保持一致,就不会有任何问题。

更新

在做了很多工作之后 Magento ,采用长形。因此,我转向了长的形式:

<?php and <?php echo

结束

<? and <?=

似乎需要做少量的工作来确保互操作性。

因为它会与XML声明产生混淆。很多人 agree with 不过,你。

另外一个问题是,如果用短标记对所有内容进行编码,最终会发现最终的宿主服务器关闭了它们,那么就会产生一种痛苦……

下面是同样的精彩流程图:

来源: similiar question on Software Engineering Stack Exchange

http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php 有很多建议,包括:

当一些人发现短标签和 ASP样式的标签很方便 不太便于携带,通常不方便 推荐。

和

注意,如果要嵌入PHP 在XML或XHTML中,您需要 使用 <?php ?> 留下的标签 符合标准。

和

应避免使用短标签 在开发应用程序或 图书馆 在PHP上重新分配或部署 不在您的 控件,因为短标记可能不是 目标服务器支持。为了 可移植的可再发行代码 一定不要使用短标签。

如果有人还在关注这个…从php 5.4.0 alpha 1开始 <?= 始终可用:

http://php.net/releases/NEWS_5_4_0_alpha1.txt

所以看起来短标签(a)可以接受,(b)留在这里。至少现在……

• 在某些Web服务器(共享主机等)中,默认情况下不会打开短标记,因此 代码可移植性 如果你需要转移到其中一个问题上。

• 可读性 对一些人来说可能是个问题。许多开发人员可能会发现 <?php 作为比 <? 当您扫描一个文件时,尤其是当您使用 HTML 与PHP紧密交织。

注意:从php 5.4开始, <?= ,现在始终可用。

我在寻找这个主题的信息后阅读了这一页,我觉得有一个主要问题没有被提到:懒惰与一致性。php的“real”标记是<?PHP和?>。为什么?我真的不在乎。当它们显然用于PHP时,为什么要使用其他东西?<%和%>对我来说是ASP,并且<script…..表示javascript(在大多数情况下)。因此,为了一致性、快速学习、可移植性和简单性,为什么不坚持标准呢?

另一方面,我同意模板中的短标记(并且只在模板中)似乎很有用,但问题是我们在这里花了太多时间讨论它,以至于实际上要花很长时间输入额外的三个字符“php”!你说什么?

虽然有很多选择是不错的,但这根本不符合逻辑,它可能会导致问题。想象一下,如果每种编程语言都允许4种或更多类型的标记:javascript可以是<js或<script…。还是<%或<?JS…那会有帮助吗?在PHP的情况下,解析顺序倾向于允许这些事情发生,但是语言在许多其他方面并不灵活:它在最小的不一致性上抛出通知或错误,但是短标记经常被使用。如果在不支持短标签的服务器上使用短标签,则可能需要很长时间才能找出问题所在,因为在某些情况下不会给出错误。

最后,我不认为短标记是这里的问题:只有两种逻辑类型的PHP代码块——1)常规的PHP代码,2)模板回音。 对于前者,我坚信只有<?PHP和?>应该只允许保持所有内容的一致性和可移植性。 对于后者,<?=$var?>方法是丑陋的。为什么一定要这样?为什么不添加更符合逻辑的内容呢? &?PHP $var?gt; 这不会有任何作用(而且只有在最遥远的可能性下,它才会与某件事发生冲突),这很容易取代尴尬的局面。=语法。或者,如果这是一个问题,也许他们可以使用<?PHP= $var?&而不是担心不一致。

在有4个打开和关闭标签选项以及随机添加一个特殊的“echo”标签的情况下,php也可能在php.ini或.htaccess中有一个“自定义打开/关闭标签”标志。这样设计师就可以选择他们最喜欢的。但由于明显的原因,这是过度杀戮。为什么允许4+选项?

当您使用MVC框架或具有单独视图文件的CMS时,最好使用它们。
它速度快,代码少,对设计者来说不容易混淆。只要确保您的服务器配置允许使用它们。

有一种情况稍有不同,那就是在开发 CodeIgniter 应用。每当在模板/视图中使用PHP时,codeigner似乎都会使用短标签,否则对于模型和控制器,它总是使用长标签。在框架中,这不是一个硬性和快速的规则,但在大多数情况下,框架和许多其他用途的来源都遵循这个惯例。

我的两分钱?如果您从未计划在其他地方运行代码,那么可以根据需要使用它们。当我意识到这是一个愚蠢的想法时,我宁愿不做大规模的搜索和替换。

让我们面对现实吧。没有短标签,PHP就难看极了。

您可以在 .htaccess 如果您无法访问 php.ini :

php_flag short_open_tag on

<? 在较新版本中默认禁用。您可以像描述的那样启用此功能 Enabling Short Tags in PHP .

imho那些使用短标签的人经常忘记逃避他们的回声。最好有一个默认情况下可以逃逸的模板引擎。我相信RobA写了一个快速的黑客程序来避开Zend框架应用程序中的短标签。如果你喜欢短标签,因为它使PHP更容易阅读。那么聪明可能是更好的选择吗?

{$myString|escape}

在我看来,这比

<?= htmlspecialchars($myString) ?> 

人们必须问使用短标签有什么意义。

更快类型

MDCore说:

<?= 比打字方便多了 <?php echo

是的,是的。您可以节省在脚本中输入7个字符*x次的时间。

然而,当一个脚本需要一个小时,或者10个小时,或者更多的时间来设计、开发和编写时,在脚本的持续时间内,不在这里或那里输入这7个字符的几秒钟有多重要?

相比之下,如果短标记没有打开,或者只是打开了一个更新,或者更改了ini文件/服务器配置的人停止了它们的工作,那么一些核心或全部脚本的潜力就不起作用了,其他的潜力也不起作用。

你所获得的小好处并没有超过潜在问题的严重性,也就是说,你的网站没有工作,或者更糟的是,只有一部分不工作,因此是一个头痛的问题要解决。

易于阅读

这取决于 熟悉程度 .
我总是看到和使用 <?PHP回波 . 所以当 <?= 不难读懂,对我来说不熟悉,因此 不容易阅读 .

随着前端/后端开发人员的拆分(与大多数公司一样),前端开发人员处理这些模板会更多 熟悉的 知道 <?= 等于“php open tag and echo”?
我想大多数人会更愿意接受更符合逻辑的观点。也就是说,一个清晰的php开放标签,然后发生了什么“echo”- <?PHP回波 .

风险评估
问题=整个站点或核心脚本无法工作;

潜在的问题是 极低空 +结果的严重性是 非常高 = 高风险

结论

您在这里和那里节省了几秒钟,不必键入几个字符,但这样做的风险很大,因此也可能会失去可读性。

前端或后端编码器 熟悉的 具有 <?= 更容易理解 <?PHP回波 ,因为它们是标准的PHP东西-标准 <?php 打开标签和众所周知的“回声”。
(即使是前端编码人员也应该知道“echo”,否则他们将无法处理由框架提供服务的任何代码)。

相反,有人不太可能从逻辑上推断PHP短标记上的等号是“echo”。

为了避免可移植性问题,请使用 <?php 如果您的PHP文件是纯PHP,而不是HTML,则不需要使用结束标记。

• 如果您确定服务器将支持它,并且您的开发人员将理解它,那么可以使用短标记。
• 许多服务器不支持它,许多开发人员一次看到它就会理解它。
• 我使用完整的标签来确保可移植性,因为它并没有那么糟糕。

我的一个朋友说了这句话,支持候补队员 标准化 ASP样式标记,如 <% 而不是 <? 这是php.ini中名为asp_标记的设置。他的理由如下:

… 任意约定应该是 标准化 . 也就是说,任何时候 面对一系列的可能性 都是同等价值的-比如 奇怪的标点符号我们的程序 语言应该用来划分 本身-我们应该选择一个标准 坚持到底。这样我们 减少所有人的学习曲线 语言 公约适用于)。

听起来不错,但我认为我们谁也不能围绕这一事业兜圈子。同时,我会坚持到底 <?php .

转换 <? (没有尾随空格)to <?php (带尾随空格):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'

转换 <? (带尾随空格)to <?PHP (保留尾随空格):

find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'

我认为值得一提的是,从php 7开始:

• 短ASP PHP标记 <% … %> 消失了
• 短PHP标签 <? … ?> 如果 short_open_tag 设置为真。这是默认设置。
• 从php 5.4开始,短 打印 标签 <?=… ?> 是 总是 启用,无论 短开口标签 设置。

很好地摆脱了第一种语言,因为它干扰了其他语言。

除了个人喜好外,现在没有理由不使用短打印标签。

当然,如果您重新编写代码以与php 5的旧版本兼容,则需要遵守旧规则,但请记住,现在不支持php 5.6之前的任何内容。

见: https://secure.php.net/manual/en/language.basic-syntax.phptags.php

如果你关心 XSS 那你应该用 <?= htmlspecialchars(…) ?> 大多数时候,所以一个简短的标签不会有很大的区别。

即使你变短了 echo htmlspecialchars() 到 h() ,这仍然是一个问题,你必须记住几乎每次都添加它(并且试图跟踪哪些数据是预转义的,哪些数据是未转义的,但无害的只会使错误更容易发生)。

我用 a templating engine 默认情况下是安全的,并写入 <?php 给我的标签。

<?php ?> 因为这种编程语言的开发人员已经大量更新了他们的核心语言,所以使用起来更好。您可以看到短标签和长标签之间的区别。

短标签将突出显示为浅红色,而长标签将突出显示为较暗!

但是,回响一些东西,例如: <?=$variable;?> 很好。但更喜欢较长的标签。 <?php echo $variable;?>

不,他们是 being phased out by PHP 6 因此,如果您喜欢代码的使用寿命,请不要使用它们或 <% ... %> 标签。