PHP短标签可以接受使用吗？
这是根据官方文件的信息：
有四种不同的开关标签可以在PHP中使用。 其中两个
<?php ?>和<script language="php"> </script>，总是可用的。 另外两个是短标签和ASP样式标签，可以从php.iniconfiguration文件打开和closures。 因此，虽然有些人发现短标签和ASP样式标签方便，但便携性较差， 一般不推荐使用 。
根据我的经验，大多数服务器都启用了短标签。 打字
<?=
比打字方便得多
<?php echo
程序员的方便是一个重要的因素，那么为什么他们不推荐？
不推荐使用它们，因为如果您不得不将代码移到不受支持的服务器（并且无法启用它），那么它就是PITA。 正如你所说，很多共享主机确实支持短标签，但“批”不是全部。 如果你想分享你的脚本，最好使用完整的语法。
我同意<? 和<?=在<?php和<?php echo比程序员更容易，但只要每次使用相同的forms（并且不要在空格中进行查找），就可以执行批量查找和replace。 ： <? php或<? = ）
作为一个理由，我不会购买可读性。 最严肃的开发人员可以select语法突出显示给他们。
正如ThiefMaster在评论中提到的那样，从PHP 5.4开始，无论采用短标签设置，都支持<?= ... ?>标签 。 这应该意味着它们在可移植代码中的使用是安全的，但这确实意味着PHP 5.4+的依赖。 如果你想支持5.4之前版本，并且不能保证短标签，你仍然需要使用<?php echo ... ?> 。
此外，您需要知道ASP标记<％，％>，<％=和脚本标记从PHP 7中删除 。 所以如果你想支持长期的可移植的代码，并想切换到最现代的工具考虑改变代码的部分。
我太喜欢<?=$whatever?>放手。 从来没有一个问题。 我会等到它咬我的屁股。 非常严肃的是，85％的（我的）客户在罕见的情况下都可以访问php.ini。 其他15％使用主stream托pipe服务提供商，几乎所有这些都启用。 我爱他们。
从PHP 5.4开始，回显快捷方式与短标签是分开的问题，因为总是启用回显快捷方式。 现在是事实：
- SVN由Rasmus Lerdorf修改
- 邮件列表讨论
所以echo快捷方式本身（ <?= ）现在可以安全使用。
整个讨论的问题在于使用PHP作为模板语言。 没有人认为应该在应用程序源文件中使用标签。
但是，PHP的可embedded语法允许将其用作强大的模板语言，并且模板应尽可能简单易读。 许多人发现使用像Smarty这样慢得多的附加模板引擎更容易，但对于那些需要快速渲染和纯代码库的纯粹主义者来说，PHP是编写模板的唯一方法。
反对使用短标签的唯一有效参数是它们在所有服务器上都不受支持。 有关与XML文档冲突的评论是可笑的，因为你可能不应该混合使用PHP和XML; 如果你是，你应该使用PHP来输出文本string。 安全性不应该成为一个问题，因为如果你在模板文件里面放置了诸如数据库访问凭证这样的敏感信息，那么问题就更大了！
那么，至于服务器支持的问题，无可否认，人们必须意识到他们的目标平台。 如果共享主机是一个可能的目标，那么应该避免使用短标签。 但是对于许多专业开发人员（比如我自己），客户承认（事实上取决于事实），我们将决定服务器的需求。 我经常负责自己设置服务器。
而且我们从来没有与一个不能完全控制服务器configuration的托pipe服务提供商合作 – 在这种情况下，我们可以指望运行更多的麻烦，而不仅仅是失去短标签支持。 这只是不会发生。
所以是的 – 我同意使用短标签应该仔细权衡。 但是我也坚信，这应该总是一个select，而一个意识到自己的环境的开发者应该可以随意使用它们。
由于Zend Framework在默认MVCconfiguration中推送“ PHP作为模板语言 ”，所以短标签又回来了。 我不明白这个辩论是什么，在你一生中产生的大多数软件都会在你或你公司控制的服务器上运行。 只要你保持一致，就不会有任何问题。
UPDATE
在与Magento做了很多工作之后，它使用了很长的forms。 因此，我已经转向了长长的forms：
<?php and <?php echo
过度
<? and <?=
看起来像less量的工作来确保互操作性。
因为它可以用XML声明产生混淆。 不过，很多人同意你的看法 。
另一个值得关注的问题是，如果使用短标签来编码所有东西，只会发现最终的托pipe服务器已closures它们，所以会产生一些麻烦。
以下是同样的精彩stream程图：
来源： 程序员堆栈交换类似的问题
http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php有很多的build议，包括：;
而有些人发现短标签和ASP样式标签方便，便携性较差，一般不推荐。
和
请注意，如果您将PHPembedded到XML或XHTML中，您将需要使用
<?php ?>标记来保持与标准兼容。
和
在开发应用程序或库时，应避免使用短标签，因为在目标服务器上可能不支持短标签，因此在开发应用程序或库时，要重新分发或部署在不受您控制的PHP服务器上。 对于便携式，可再发行的代码，请务必不要使用短标签。
如果有人仍然关注这个…从PHP 5.4.0开始Alpha 1 <?=始终可用：
http://php.net/releases/NEWS_5_4_0_alpha1.txt
所以看起来短标签是（a）可以接受的，（b）留在这里。 至less现在…
-
在某些networking服务器（共享主机等）中，短标签默认不打开，因此，如果您需要移动到其中一个，则代码可移植性成为一个问题。
-
可读性可能是一些问题。 许多开发人员可能会发现
<?php作为代码块开始的一个更明显的标志比<?当你扫描一个文件，特别是如果你坚持与HTML和PHP紧密交织的代码库。
注意：从PHP 5.4开始，短标记<?=现在始终可用。
我在看了这个主题的资料后，看了这个页面，觉得还有一个主要的问题没有提到：懒惰与一致性。 PHP的“真实”标签是<？php和？>。 为什么？ 我真的不在乎 为什么你想要使用别的东西时，这些是明确的PHP？ <％和％>对我来说意味着ASP，<script …..意味着Javascript（在大多数情况下）。 所以为了一致性，快速学习，便携性和简单性，为什么不坚持标准呢？
另一方面，我同意模板中的短标签（仅在模板中）似乎有用，但问题是我们在这里花了很多时间来讨论它，实际上可能需要很长时间才会浪费那么多的时间input额外的三个字符的“PHP”！
虽然有很多select是好的，但这完全不合逻辑，并且可能会导致问题。 试想一下，如果每种编程语言都允许4种或更多types的标签：Javascript可以是<JS或<script ….或<％或<？ JS ….会有帮助吗？ 在PHP的情况下，parsing顺序往往倾向于允许这些事情，但是这种语言在很多其他方面并不灵活：它会在稍有不一致的情况下抛出通知或错误，而经常使用短标签。 而当在不支持它们的服务器上使用短标签时，可能需要很长时间才能找出错误，因为在某些情况下不会出现错误。
最后，我不认为短标签是这里的问题：只有两种逻辑types的PHP代码块 – 1）常规PHP代码，2）模板回声。 对于前者，我坚信只有<？php和？>应该被允许，以保持一切的一致性和便携性。 对于后者，<？= $ var？>方法是丑陋的。 为什么一定要这样呢？ 为什么不添加更合乎逻辑的东西？ 这不会做任何事情（只有在最遥远的可能性可能会冲突的东西），这可以很容易地取代尴尬的<？=语法。 或者如果这是一个问题，也许他们可以使用<？php = $ var？>而不用担心不一致。
在开放和closures标签有4个选项和随机添加一个特殊的“回声”标签的地方，PHP也可能在php.ini或.htaccess中有一个“自定义打开/closures标签”标志。 这样devise师可以select他们最喜欢的一个。 但是由于显而易见的原因，这是过分的。 那为什么要让4个以上的选项？
当您使用具有独立视图文件的MVC框架或CMS时，最好使用它们。
它速度快，代码less，不会让devise人员感到困惑。 只要确保你的服务器configuration允许使用它们。
一个有点不同的情况是开发一个CodeIgniter应用程序。 每当在模板/视图中使用PHP，CodeIgniter似乎都会使用短标签，否则模型和控制器总是使用长标签。 这个框架并不是硬性规定，但大部分框架和其他用途的来源都遵循这个约定。
我的两分钱？ 如果你从来没有计划在其他地方运行代码，那么如果你愿意的话可以使用它们。 当我意识到这是一个愚蠢的想法时，我宁愿不必进行大规模的search和replace。
面对现实吧。 PHP是丑陋的，没有短标签。
如果您无法访问php.ini则可以在.htaccess文件中启用它们：
php_flag short_open_tag on
<? 在新版本中被默认禁用。 您可以按照描述启用PHP在PHP中启用短标签 。
使用短标签的恕我直通人员往往会忘记逃避他们的回应。 有一个默认转义的模板引擎会很好。 我相信Rob A在Zend Frameworks应用程序中写了一个简短的标签。 如果你喜欢短标签，因为它使PHP更易于阅读。 那么Smarty会是更好的select吗？
{$myString|escape}
对我来说，看起来比
<?= htmlspecialchars($myString) ?>
人们不得不问一下使用短标签的意义。
更快键入
MDCore说：
<?=比input<?php echo要方便得多
是的。 您不必在整个脚本中键入7个字符* X次。
然而，当一个脚本需要花费一个小时，或者十个小时甚至更多的时间来devise，开发和编写时，在脚本的持续时间里，在这里和那里不input这些7个字符的几秒钟的时间有多相关？
如果短标签没有打开，或者打开了一个更新，或者某人改变了ini文件/服务器configuration，它们会停止工作，则潜在的潜在的一些核心或全部的脚本无法工作。
你获得的小好处并不会超过潜在问题的严重程度，也就是说你的网站无法工作，或者更糟的是，只有部分工作不能正常工作，因此很难解决。
更容易阅读
这取决于熟悉度 。
我一直看到和使用<?php echo 。 所以虽然<?=不难阅读，但对我来说并不熟悉，因此不易阅读 。
与前端/后端开发人员分离（与大多数公司一样），在这些模板上工作的前端开发人员会更熟悉 <?=等于“PHP open tag and echo”？
我会说最符合逻辑的会更舒适。 也就是说，清晰的PHP打开标签，然后发生什么“回声” – <?php echo 。
风险评估
问题=整个站点或核心脚本无法工作;
问题的可能性非常低 +结果的严重程度非常高 = 高风险
结论
您在这里和那里节省了几秒钟的时间，而不必input几个字符，但会冒很大风险，并且可能会因此而导致可读性受损。
熟悉 <?=前端或后端编码器更可能理解<?php echo ，因为它们是标准的PHP事物 – 标准的<?php开放标记和非常着名的“回声”。
（甚至前端编码人员应该知道“回声”，或者他们根本不会在任何由框架服务的代码上工作）。
而反过来不太可能，有人不太可能从逻辑上推断出PHP短标签上的等号是“回声”。
为了避免可移植性问题，请使用<?php启动PHP标记，如果您的PHP文件纯粹是PHP，没有HTML，则不需要使用结束标记。
- 如果您确定服务器支持它，并且您的开发人员能够理解，则可以使用短标签。
- 许多服务器不支持它，许多开发人员在看到它之后会理解它。
- 我使用完整的标签，以确保可移植性，因为它真的不是那么糟糕。
这样说，我的一个朋友说，这支持替代标准化的 ASP风格的标签，如<%而不是<? ，这是一个名为asp_tags的php.ini中的设置。 这是他的推理：
任意公约应该标准化 。 也就是说，只要我们面对一系列具有同等价值的可能性 – 比如我们的编程语言应该用什么奇怪的标点来标定自己 – 我们应该select一种标准的方式并坚持下去。 这样我们就减less了所有语言的学习曲线（或者任何公约所涉及的东西）。
听起来对我很好，但我不认为我们中的任何一个人都可以围绕这个事业围绕货车。 同时，我会坚持完整的<?php 。
转换<? （没有尾随空格） <?php （带尾随空格）：
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\?(?!php|=|xml|mso| )/<\?php /g'
转换<? （尾随空格）为<?php （保留尾部空格）：
find . -name "*.php" -print0 | xargs -0 perl -pi -e 's/<\? /<\?php /g'
如果你关心XSS，那么你应该在大多数情况下使用<?= htmlspecialchars(…) ?> ，所以一个简短的标签并没有太大的区别。
即使将echo htmlspecialchars()缩短为h() ，仍然存在一个问题，那就是你必须记住几乎每次都要添加它（并且试图跟踪哪些数据是预先转义的，而这些数据是非转义的，错误更可能）。
我使用默认安全的模板引擎 ，并为我写<?php标签。
因为这种编程语言的开发人员已经大量更新了他们的核心语言，所以<?php ?>要好得多。 您可以看到短标签和长标签之间的区别。
短标记将突出显示为浅红色，而较长的标记将突出显示为较暗！
但是，回显一些东西，例如： <?=$variable;?>没有问题。 但更喜欢较长的标签。 <?php echo $variable;?>
No, and they're being phased out by PHP 6 so if you appreciate code longevity, simply don't use them or the <% ... %> tags.
