在PHP中使用<?=标记是不好的做法吗?


189

我最近遇到过这个PHP标签<?= ?>,但我不愿意使用它,但是它痒得很厉害,以至于我想请您使用它。我知道使用短标签是一种不好的做法,<? ?>而应该使用完整标签<?php ?>,但是这个<?= ?>呢?

这将节省一些键入内容,并且对于代码可读性更好,IMO。所以代替这个:

<input name="someVar" value="<?php echo $someVar; ?>">

我可以这样写,它更干净:

<input name="someVar" value="<?= $someVar ?>">

使用此运算符是否会皱眉?


11
这种问题的问题在于,它是如此自以为是。“技术上”不是正确或错误的方法。有些人主张,有些人反对,它的全部偏好。因此,最终取决于您。
mseancole 2012年

如果可以,请避免使用任何形式的结束标记-即文件仅包含php代码(不包含html等)。如果您有结束标记,则其后的所有字符都会输出到浏览器(对于Web应用程序),这可能会导致很难调试的问题。更多信息:stackoverflow.com/a/4453835/49560
dharm0us

与非意见相关:请小心,因为它echo很容易导致XSS,因此您最好依赖于上下文专用的回显方法(即:使用a function html($x) { echo htmlentities($x,...); }和un html($someVar);代替JS上下文echo $someVarecho json_encode($x);用于JS上下文)。这样就使<?=标记成为一种不好的做法,因为这意味着您已经在另一个地方用HTML转义了变量内容,并且其他地方必须神奇地知道必须对该变量进行HTML转义,因为它已在HTML上下文中回显了。
Xenos

Answers:


209

历史

在错误信息提示离站太远之前,您需要了解很多有关PHP短标签的知识。

PHP的短标签的主要问题在于,PHP设法选择了<?另一种语法XML使用的标签()。

启用该选项后,您将无法在没有语法错误的情况下原始输出xml声明:

<?xml version="1.0" encoding="UTF-8" ?>

当您考虑如何常见的XML解析和管理时,这是一个大问题。

<?=

尽管<?与xml引起冲突,<?= 但不会。不幸的是,将其打开和关闭的选项与绑定在一起short_open_tag,这意味着要获得短回显标签(<?=)的好处,您必须处理短打开标签(<?)的问题。与短打开标签相关的问题远比从短回显标签带来的好处要大得多,因此您将找到一百万零八十个short_open_tag关闭建议,您应该这样做

但是,在PHP 5.4中,短回声标记已与该short_open_tag选项分开重新启用。我认为这是对便利的直接认可<?=,因为它本身本身没有任何根本上的错误。

问题是,<?=如果您尝试编写可在更广泛的PHP版本中使用的代码,则无法保证一定会拥有。

好的,现在一切都已解决

你应该使用<?=吗?

是否使用短回显标记的流程图


70
我不同意你的图表。正确答案是99.99%是,因为大多数生产环境都配置为使用短标签。假如你搞砸了,他们删除<?=在未来,你可以解决它在不到一分钟,不管成千上万的文件如何使用它,你只需要做一个项目范围的搜索和替换的<?=进行<?php echo 。我的答案是不用担心,只用它,好处就大大超过了后果。<?=不再被视为短标签,拉斯穆斯·勒多夫(Rasmus Lerdorf)亲自做出了承诺。
dukeofgaming 2012年

32
@dukeofgaming,您在哪里获取有关配置为使用短标签的生产环境的数据?禁用它们是我听说过的最常见的建议配置之一,仅次于禁用魔术引号。拥有与生产环境不同的开发环境也绝对没有意义。
zzzzBov 2012年

4
短标签默认情况下处于启用状态,直到5.3 php.net/manual/en/ini.core.php#ini.short-open-tag,我知道的大多数托管服务都毫无问题地支持它,这就是Kohana框架的原因之一曾经鼓励它。<?=将始终处于打开状态(stackoverflow.com/a/6064813/156257),并且大多数时候它们一直处于打开状态。您可以通过与您的主机进行核对来证明我错了:是否禁用了主机并使用PHP <5.3,并且不允许用户或应特殊要求覆盖该设置;如果前面的所有内容都是假的,则一定要担心<?=
dukeofgaming 2012年

6
您不必担心<?=会被删除,我也不是。其他人也可能会被删除,如果已删除,则不必使用<?=。有些人对使用某些语言功能有非理性的恐惧(例如在php中关闭结束标记)。
zzzzBov 2012年

8
这正是我的观点:无需担心。我只说“你担心吗?” -是->“继续使用它们,无需担心”。感觉就像您是在暗示关闭结束标记是一种不良习惯,事实并非如此。
dukeofgaming 2012年

28

去掉我的PHP帽子

我绝对更喜欢使用<?= $someVar ?>verbs echo(而不是更个人化)。该唯一的缺点AFAIK是谁正在运行的预5.4.0在这种情况下,用户short_open_tag必须启用php.ini中

话虽如此,如果您的项目不是OS,那么这是有争议的。如果是这样,我要么记录short_open_tag必须启用s 的事实,要么使用这两种解决方案中更具移植性的事实。


1
Nitpick:尽管<?=不受short_open_tagPHP 5.4的影响,<?但仍然如此,如果您习惯使用短格式标签,则很容易忘记哪个版本支持什么。
yannis 2012年

7
@YannisRizos最好区<?=分为“我现在正在输出变量”以进行模板样式的使用,并区<?php分为“我正在运行大量代码”。我建议从来没有使用<?,但双方<?=<?php都很好。
伊兹卡塔2012年

2
+1是因为Rasmus Lerdorf认可了速记<?=标签。我观看了他关于PHP 5.4(然后即将发布)的演讲之一。这就是为什么从PHP 5.4.0开始,<?=标记始终可用。我已经看到PHP 5.4之前的许多代码,其中<?=标记用于MVC应用程序的View中,而<?php ...?>用于非视图文件中。
程序员

@Jason我不是这个意思。“拉斯穆斯认可foo” 不是一个参数,而是 “拉斯穆斯为此而认可foo”。
扬尼斯

2
@Yannis Rizos 拉斯莫斯为此支持foo”。感谢您的指导,但我的理由是自Rasmus Lerdorf认可它以来,作为语言的创建者并仍对PHP的发展产生影响,因此进行了更改以使<?=标签始终可用。这就是我应该在原始注释中添加的内容,“因此在视图中使用<?=的做法可能会变得更加普遍。” 亲爱的,我现在需要在点上三重检查我的评论...
程序员,

21

绝对应该避免使用简写形式的标签,无论是<?还是<?=

主要的技术原因是可移植性,您永远不能确定短格式标签对每个给定的设置都适用,因为可以将其关闭,请查找short_open_tag指令。但是您始终可以肯定,长格式可以在任何地方使用。

这将节省一些键入内容,并且对于代码可读性更好,IMO。

那也是个坏习惯。我无法真正告诉您您发现什么更具可读性,但是我强烈反对以代码可读性为借口,以节省几次击键。如果您担心可读性,则应使用模板引擎,这是:

<input name="someVar" value="{someVar}">

这两个示例的可读性都更高。

最后,值得注意的是,主要的PHP项目(例如PEARZend Framework)明确禁止使用简短形式的标签。


14
为模板+1。-1为可移植性。它是服务器端语言。服务器需要重点关注的挑战是可伸缩性和安全性。花大量的时间来确保它可以在多个平台上运行,这是一个非常糟糕的主意……(以防万一!)……
riwalk 2012年

3
@ Stargazer712嗯?您唯一需要做的就是使用标准<?phpecho而不是<?and <?=,您是否认为这是严肃的时间?当您将项目移至由于某些原因禁用短标签的服务器时,会发生什么?
yannis 2012年

13
@Yannis:这几个字符看起来似乎不多,但IMO它们会增加很多噪音。
凯文·克莱恩

8
我认为应该提到PHP的最初目的是成为模板语言。在PHP之上添加另一个模板引擎(更膨胀)不会使我的金枪鱼船浮起。在将PHP和HTML混合编码时,只需遵循良好的实践(一些好的技巧在这里stackoverflow.com/questions/62617/…),就可以了。
程序员

2
@Yannis Rizos是的,应该提到,因为PHP新手可能会认为他们有义务在自己的PHP项目中使用[whizbang]模板引擎,而不考虑使用纯PHP。我应该只在Perl中执行文本处理吗,也许不是,但是我认为,到目前为止,Perl擅长于文本处理-同样在PHP和模板化中也是如此。
程序员

15

PHP的文件清楚地说,你可以放心地使用短回波标签:

5.4.0 The tag <?= is always available regardless of the short_open_tag ini setting.

尽管此版本适用于PHP 5.4及更高版本,但每个人至少应使用此版本。我希望它们仅用于模板目的。


10

使用短标签的原因:

  • 它们比较短。

使用短标签的原因:

  • 他们引入了另一个配置陷阱-虽然您通常在专业环境中确实控制服务器,但如果您打算将代码发布给公众,则短标签对于使用例如共享主机的人可能无法修复。 。
  • 它们使将未经消毒的字符串随意放入输出中变得太容易了。这很可怕,因为它可能会引入XSS漏洞。虽然长的标签什么都不做,直接防止这种情况,他们发出信号,告知也许他们在做什么是不正确的事情的程序员,他们应该开始使用模板系统,自动处理HTML编码为他们现在。输出带有长标签的动态字符串很麻烦,这是一件好事(有教益)。

这就是接受IMO的答案,即使模板也不能保证XSS一切安全(脚本的src属性中的用户数据始终不安全),而且我不知道模板机制是否知道适当的回显上下文;因此,请参见IMO。如果PHP变量最终出现在脚本标签内容中怎么办?在SVG中嵌入HTML吗?
Xenos

@Xenos显然取决于所讨论的模板系统,并且没有灵丹妙药;但是大多数方法的确可以减少错误的面,并减少需要人工努力(安全性错误的最重要的单一来源)的场景数量。“不要在脚本标记中放入动态内容”比“确保所有动态内容在任何地方都正确地进行HTML编码”更容易遵循和审核。
tdammers

4

我认为该<?=版本是一种良好/可以接受的做法,前提是您仅将其用于变量的最终输出,并避免任何与数据表示不直接相关的函数调用或三元逻辑。

它肯定比<? echo($x); ?>任何地方都好。

从长远来看,您可能希望研究诸如Smarty之类的模板引擎。


3
Smarty曾经模板引擎,但现在它是一个过时且mess肿的混乱局面,您应该真正避开它。
yannis 2012年


-3

老实说,我认为在MVC庆祝成立33周年之际,无论采用哪种方法(旧的或新的方式),都必须回显一个结果。

我会说是的,这是将传入服务器(php)数据封装在XML文档中并在您的应用程序/客户端层中进行处理的一种好习惯,从而甚至节省了使用此类标签的想法。


1
其实MVC庆祝了33年,这是第一次在概述了1979年12月提出
yannis 2012年

是的,我仍然处于2000年,我的错误:-)
sebas

1
嗯...模板...模板过时了吗?模板和MVC是否互斥?
Tim Seguine 2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.