Вот информация согласно официальной документации:
There are four different pairs of opening and closing tags which can be used in PHP. Two of those,
<?php ?>and<script language = "php"> </script>, are always available. The other two are short tags and ASP style tags, and can be turned on and off from the php.ini configuration file. As such, while some people find short tags and ASP style tags convenient, they are less portable, and generally not recommended.
По моему опыту, на большинстве серверов делать включены короткие теги. Печатать
<?=
намного удобнее, чем печатать
<?php echo
Удобство программистов - важный фактор, поэтому Почему не рекомендуются?
В каком случае возникает эта проблема, означает ли это, что разработчикам сложно создавать XML с помощью PHP?
Допустим, у вас есть XML-документы, которые вы хотите сделать общедоступными, но вы хотите, чтобы документы можно было анализировать с помощью php по какой-либо причине, поэтому вы делаете .xml анализируемым вашим браузером. Вы используете короткие теги, чтобы они были включены, и внезапно XML-документ анализируется через заголовки XML, что нарушает работу. Давно сводил меня с ума, пытаясь в этом разобраться. С тех пор, как короткие коды были отключены на всех серверах, которые я запускаю, и любой команде, с которой я работал, приходилось прибегать к не коротким кодам.
Если вы строго посмотрите на случай с несколькими лишними персонажами, я бы сказал, что их нет для большинства людей, которые просматривают этот форум, учитывая типичные сценарии, в которых они находятся.
Если в документации сказано, что это не одобряется, почему в PHP 5.4.0 они теперь всегда включены?
Я помещаю это в начало своей конфигурации: if (! ini_get ('short_open_tag')) {ini_set ('short_open_tag', '1') or die («Не удалось включить короткие теги PHP!»); } Затем, если я получаю ошибку die (), я могу найти и заменить <? для <? php. Во всяком случае, просто идея.
<?= $example;?>! This is very important as the use of all other short tags is considered futile. Anyway the use of the short echo tag is encouraged from now on. It does provide for a smoother and tidier code-base - esp. in view files. So для PHP> = 5.4.0<?= ?> can be used без настройкиshort_open_tag. Please do not use the other short tags in your code. The code-Gods get very angry when you do so...
Хотя этот вопрос на самом деле не соответствует формату StackOverflow («неконструктивный»), я решил проголосовать за то, чтобы оставить его «открытым», поскольку я думаю, что этот вопрос может быть полезен для справок в будущем. Он уже получил много голосов, что (ИМО) является четким указанием на информативный вопрос.
Я собираюсь добавить это в качестве быстрого комментария, потому что длинных ответов уже слишком много: <? - это не Только, используемый в XML для открытия объявления <?xml version = "1.0" ?>; это общий синтаксис для «инструкций обработки», второй наиболее распространенный пример - <?xml-stylesheet ... ?>. <?php может фактически считаться допустимой инструкцией обработки, как и <?= (как разрешено в 5.4+), но утверждение всего <? также создает ненужный конфликт между синтаксисами.
«Не рекомендуется» не означает, что вы не можете его использовать. Если вы обнаружите, что это делает вашу жизнь лучше, во что бы то ни стало. Просто помните о предостережениях. Из всех людей, программисты должны быть довольны существованием нескольких способов делать что-то. Делайте это хорошо, когда можете. Приспосабливайтесь, когда будете осторожны.
@BorislavSabev - Интересный факт: я лично убедил команду разработчиков PHP поставить <?= в 5.4.0, как всегда включенный. При написании открытого исходного кода вы должны предположить, что для short_open_tag установлено значение «нет», но закрытый / проприетарный исходный код может быть любым. Даже до версии 5.4 я обнаружил, что написание <?php echo или <?php print до тошноты довольно раздражает и подвержено ошибкам, и во внутренних системах я включил short_open_tag только для того, чтобы получить доступ к <?=.
@CubicleSoft действительно основная потребность в short_open_tag исходит из устаревших систем с запутанным кодом. Я понимаю, что иногда его нужно использовать, но только для устаревших систем. Я все еще считаю другие короткие теги злом, которое не следует использовать :)
Из документы<script language = "php"> … </script> Этот синтаксис удален в PHP 7.0.0.






Потому что путаницу он может вызвать с объявлениями XML. Хотя многие люди соглашатьсяс вы.
Дополнительное беспокойство вызывает то, что кодировать все с помощью коротких тегов только для того, чтобы в конце узнать, что последний хост-сервер отключил их ...
Не вызовет ли объявление XML путаницы, если включен short_tags?
Таким образом, вместо того, чтобы напрямую выводить XML-объявление, PHP выдает его эхо. Это не очень хорошее опровержение.
Это не опровержение чего-либо. Это единственная реальная причина, которая, в свою очередь, является причиной другой причины «хостер выключает его», конечно, вы можете использовать его, если знаете, что делаете, как всегда.
Зачем PHP разбирает ваши XML-файлы? Это подделка.
@macek: Есть много способов сделать это с помощью коротких тегов. включить ("a.xml"); это первое, что приходит в голову.
@Vinko Vrsalovic, нет, я спросил Почему, а не как.
@Vinko, это работает, но это не то, как вы должны выводить файл в первую очередь; при использовании include или require PHP проанализирует файл. Вы можете использовать file() and fread() или file_get_contents(), чтобы просто вывести файл.
@macek: Я в курсе. Это был только первый пример, о котором я подумал. Другой: что, если вы встроите PHP в файл XML? Вы не можете сделать это напрямую. И не говорите мне также решение этой проблемы, я знаю о них. Дело в том, что PHP может анализировать XML-файл множеством способов. Вы, вероятно, можете отклонить их все с помощью обходных путей (<?='<?xml') или сказав «вы не должны этого делать», но это не устраняет тот факт, что это может произойти.
@macek: создание RSS-каналов в PHP. Генерация любого вида бэкэнда XML-данных на PHP. Существует множество причин для создания XML-файла на PHP.
@Matthew Scharley, это обсуждение посвящено Почему, который нужно проанализировать в XML-документе; а не зачем создавать XML с помощью PHP. Я до сих пор не вижу причин, по которым вы хотели бы запускать XML-файл через синтаксический анализатор PHP, а не просто читать его.
@macek: Как насчет обслуживания простого XML-документа со статической структурой, в которой некоторые значения извлекаются из базы данных? Это хорошо подходит для встраивания PHP в XML.
@vincko: следовательно, сделать файлы .xml доступными для анализа интерпретатором php? плохая идея! (свидание не смотрел, извини ...)
Какая боль от коротких тегов, если они не работают? его очень легко сделать оптом и заменить <?= на <? echo . многие текстовые редакторы могут легко справиться с этим сразу с тысячами файлов.
Короткие теги не включены по умолчанию на некоторых веб-серверах (общие хосты и т. д.), Поэтому переносимость кода становится проблемой, если вам нужно перейти на один из них.
Читаемость может быть проблемой для некоторых. Многие разработчики могут обнаружить, что <?php бросается в глаза как более очевидный маркер начала блока кода, чем <?, при сканировании файла, особенно если вы застряли в кодовой базе, в которой HTML и PHP тесно переплетены.
Короткие теги включены на 95% веб-серверов.
Я не верю аргументу «читабельности». Если вы используете PHP в качестве языка шаблонов, <?= $var ?> будет более читаемым, чем <?php echo $var ?>.
@Paulo это могло измениться с '08, но экземпляры EC2 Ubuntu и Fedora с yum install и apt-get версиями PHP по умолчанию отключили короткие теги
используйте полные теги и у вас будет 100% :)
@FrankFarmer, я думаю, он сравнивает ту, что без эха. <? против <?php.
Они не рекомендуются, потому что это PITA, если вам когда-либо придется перенести свой код на сервер, где он не поддерживается (и вы не можете его включить). Как вы говорите, многие общие хосты делать поддерживают короткие теги, но «много» - это еще не все. Если вы хотите поделиться своими сценариями, лучше всего использовать полный синтаксис.
Я согласен с тем, что <? и <?= проще для программистов, чем <?php и <?php echo, но можно выполнять массовый поиск и замену, если вы каждый раз используете одну и ту же форму (и не забрасываете пробелы (например: <? php или <? =)
Я вообще не считаю удобочитаемость поводом. У наиболее серьезных разработчиков есть возможность подсветки синтаксиса.
Как упоминает ThiefMaster в комментариях, начиная с PHP 5.4, теги <?= ... ?> поддерживаются везде, независимо от настроек коротких тегов.. Это должно означать, что их безопасно использовать в переносимом коде, но это означает, что существует зависимость от PHP 5.4+. Если вы хотите поддерживать до 5.4 и не можете гарантировать короткие теги, вам все равно нужно использовать <?php echo ... ?>.
Также вам необходимо знать, что Теги ASP <%,%>, <% = и тег скрипта удалены из PHP 7.. Поэтому, если вы хотите поддерживать долгосрочный переносимый код и хотите переключиться на самые современные инструменты, подумайте об изменении этих частей кода.
Итак, объяснение: они плохие, потому что не поддерживаются? Но почему они не поддерживаются? Потому что они не входят в спецификацию? Хорошо, но почему они не входят в спецификацию? Я немного разочарован этим ответом.
Я здесь не для того, чтобы обсуждать «важные вопросы» вроде того, почему мы здесь, как все это началось и т. д. Поддержка коротких тегов не гарантируется на общих серверах, и в следующей основной версии они будут полностью удалены. Это все, что вам нужно знать.
Если вам нужны короткие теги, это означает, что вам нужно использовать механизм шаблонов.
Обязательный PHP является шаблонизатор. :П
perl -pei "s / <? = / <? php echo /; s / <? / <? php /;" $ (найти шаблоны)
@gcb, PHP является шаблонизатор
Использование коротких тегов не прекращается. Только короткие теги в стиле ASP.
есть хосты, на которых mod_rewrite также не поддерживается. и чертовски тонна других вариантов. Не рекомендую их всех. Обычный HTML-код!
так что они ужасная заноза в заднице, но их можно удалить массовым поиском и заменой? Что он?
Это довольно плохая причина рекомендовать отключать короткие теги. Если у вас есть собственный выделенный сервер, вы полностью контролируете настройки php.ini, поэтому вы всегда можете включить короткие теги на своем сервере. Что касается аргумента о смене хостинг-провайдера, просто убедитесь, что вы переключились на хостинг-провайдера, который обеспечивает поддержку коротких тегов на своих серверах. Я предпочитаю использовать короткие теги вместо длинных, чтобы кодирование было быстрым и эффективным, а также для улучшения читаемости кода.
Они никогда не были для меня PITA до тех пор, пока PHP не попытался их «вывести из строя». Я разрабатываю PHP около 8 лет на многих хостах.
В (очень близком) будущем PHP 5.4 использование <? = Будет отделено от того, включены или отключены short_open_tags. <? = не прекращается, напротив, теперь он считается фундаментальной частью языка.
Извините, но это только оправдание, если так много серверов не включают эту опцию, сделайте ее по умолчанию. Я надеюсь, что они передумают, дело не в том, можно ли избежать использования коротких тегов, а в том, что вы получите, если они будут удалены: я могу жить с ними или без них, но почему я должен это делать лишняя работа и быть ограниченным, если нет выгоды? Я надеюсь, они удалят THE OPTION, чтобы включить / отключить их и оставить всегда включенным, например, magic_quotes, который был удален (наконец, после того, как был деактивирован по умолчанию)
Решение всех ваших проблем с виртуальным хостингом: не используйте паршивые дешёвые общие хосты.
@Oli: подумайте о том, чтобы упомянуть, что <?= (но не <? в целом) всегда поддерживается, начиная с PHP 5.4, в самом начале вашего ответа. Это вопрос №4 при поиске в Google короткие открытые теги php, поэтому очень важно рассказать об этом людям.
Этот глобальный поиск и замена, упомянутые выше, на самом деле опасны, если вы используете подготовленные операторы DBO. Предположим, вы проверяли наличие строк на основе возраста в таблице с именем list и случайно поставили пробел после вопросительного знака вместо перед: $ dbh-> prepare ("SELECT * FROM list WHERE age <?"); Глобальный поиск / замена изменит это на $ dbh-> prepare ("SELECT * FROM list WHERE age <? Php"); А также отсутствует глобальный флаг, поэтому он будет заменять его только один раз в строке.
За 30 с лишним лет веб-разработки я ни разу не встречал хостера, у которого бы еще не было или не было бы коротких тегов. Избавление от <? = Заставит многих людей придерживаться php6 намного дольше
@RidIculous Когда я писал этот пост, я недавно встречал хосты, которые блокировали короткие теги (и есть разница между <? ... ?> и <?= ... ?>. Последний поддерживается независимо от настройки коротких тегов - см. Вторую половину сообщения)
На самом деле было бы целесообразно переместить эту часть в начало ответа: «Как ThiefMaster упоминает в комментариях, начиная с PHP 5.4, теги <? = ...?> Поддерживаются везде, независимо от настроек коротких тегов. Это должно означают, что они безопасны для использования в переносимом коде ", чтобы избежать путаницы, продолжая начинать его с" Они не рекомендуются, потому что это PITA ". Esp. так как вопрос даже явно касался <?=.
Одна ситуация, которая немного отличается, - это разработка приложения CodeIgniter. CodeIgniter, кажется, использует короткие теги всякий раз, когда PHP используется в шаблоне / представлении, в противном случае с моделями и контроллерами он всегда использует длинные теги. Это не жесткое и быстрое правило во фреймворке, но по большей части фреймворк и многие источники из других применений следуют этому соглашению.
Мои два цента? Если вы никогда не планируете запускать код где-то еще, используйте их, если хотите. Я бы предпочел не проводить массовый поиск и замену, когда понял, что это глупая идея.
Я слишком люблю <?=$whatever?>, чтобы отпускать его. Никогда не было проблем с этим. Я подожду, пока он не укусит меня за задницу. Если серьезно, 85% (моих) клиентов имеют доступ к php.ini в случае, если редкий отключен. Остальные 15% пользуются услугами основных хостинг-провайдеров, и практически у всех они включены. Я люблю их.
@B Seven. Если вы попытаетесь избежать каждой теоретической проблемы, которая может возникнуть, ваш код почти наверняка будет неэффективным и ошибочным. Пока группа PHP не согласится отказаться от использования коротких тегов [не ASP-тегов], беспокойство о том, что вас укусили, гораздо меньше, а потенциальное решение гораздо проще, чем другие вещи, на «исправление» которых вы можете потратить свое время.
если он вас укусит, переходите на лучший хостинг
Я действительно не согласен с тем, чтобы что-то не использовать, потому что это мощь не поддерживается. Не следует ли нам использовать какие-либо другие функции, которые могут не поддерживаться на сервере? MYSQL против MYSQLI? Вы будете потратить свое время понемногу, снова и снова записывая длинные теги, чтобы избежать небольшого шанса потратить немного времени на переход на лучший хост.
@BSeven, Вы имеете в виду, что не используете никаких расширений PHP, кроме поставляемых по умолчанию?
Нет, и они выводится из употребления PHP 6, поэтому, если вы цените долговечность кода, просто не используйте их или теги <% ... %>.
Я видел другие сообщения в блогах, в которых говорится, что они не будут устаревать, а только короткие теги в стиле ASP.
Они постепенно отказываются от «коротких открытых тегов» (к счастью) <? ?>, Я не уверен, что это включает <? =?> (Надеюсь, что нет)
Похоже, что этот ответ неверен, согласно этой ссылке с собрания разработчиков PHP: php.net/~derick/…
ПОЧЕМУ они такие плохие, почему? Все настолько уверены в себе, что они баааааад, но никто не говорит почему.
@Josef - короткие теги также являются инструкциями по обработке XML, поэтому смешивание PHP с XML или XHTML Strict может показаться немного странным. Я бы сказал, скорее причудливый, чем плохой, но кричать на PHP популярно.
Если вы запускаете / управляете своим собственным сервером, то я не вижу проблем с использованием <? ?> в PHP, кроме случаев работы с XML-документами, в которых используются теги <? xml version = "1.0"?>. Но есть простые способы обойти это, например, использовать echo '<? Xml version?>' ;. Честно говоря, я не понимаю, почему люди придают такое большое значение коротким тегам.
ЛОЖНЫЙ. Они постепенно отказываются от тегов <%%>, как и должны. Они служат только для того, чтобы сбивать с толку. <? ?> теги не будут затронуты; но, конечно, они по-прежнему настраиваются для каждого сервера, и вы всегда должны знать требования вашей целевой платформы.
Эта информация кажется неверной и вводящей в заблуждение, и ее автор должен исправить.
Если вам важен XSS, вам следует использовать <?= htmlspecialchars(…) ?> большую часть времени, поэтому короткий тег не имеет большого значения.
Даже если вы сократите echo htmlspecialchars() до h(), это все равно проблема, которую вы должны помнить, чтобы добавлять его почти каждый раз (и попытка отслеживать, какие данные предварительно экранированы, что неэкранировано, но безвредно, только делает ошибки более вероятными).
Я использую шаблонизатор, который по умолчанию безопасен и записывает за меня теги <?php.
Если вы обнаружите, что набираете «<? Php echo htmlspecialchars ($ text, ENT_QUOTES, 'UTF-8');?> 500 раз в день, вы можете захотеть создать функцию быстрого доступа с именем« h », как в Rails ..» < ? = h ($ text)?> "намного удобнее читать при сканировании шаблона.
Это действительно лучше, но с механизмом шаблонов это может быть просто $ {text} или что-то в этом роде (и вам не нужно помнить о добавлении h ())
Сам PHP является механизмом создания шаблонов. Когда вы перестанете использовать короткие теги, это станет плохим механизмом создания шаблонов, поскольку он станет слишком многословным.
@Alexander Malfait, это хороший совет. Но <? = Не нужен. Вы можете просто заставить функцию отображать строку вместо return, тогда вы должны написать <? Php h ('hello')?> Разве мы уже не делаем этого, когда мы de i18n? <? php _e ('')?> не так уж и плохо.
Короткие теги возвращаются благодаря тому, что Zend Framework вставляет «PHP как язык шаблонов» в их конфигурация MVC по умолчанию. Я не понимаю, о чем идет речь, большая часть программного обеспечения, которое вы создадите в течение своей жизни, будет работать на сервере, который вы или ваша компания будете контролировать. Пока вы сохраняете последовательность, проблем возникнуть не должно.
ОБНОВИТЬ
После довольно большой работы с Magento, который использует длинную форму. В результате я перешел на длинную форму:
<?php and <?php echo
над
<? and <?=
Похоже, небольшой объем работы по обеспечению совместимости.
Я фрилансер, и весь мой код размещается на виртуальном хостинге, так что никакого контроля! :)
Если у вас достаточно клиентов, переходящих на вашу собственную колику, виртуальный хостинг небезопасен и нестабилен.
Короткие теги, которые Zend возвращал, по-видимому, не уловили, поскольку Zend использует длинную версию: framework.zend.com/manual/en/zend.view.scripts.html
@Gerry Я тоже недавно это читал, см. Последний комментарий к этой теме: Обновите .htaccess, чтобы включить короткие открытые теги
Вам действительно следует исправить грамматику в первом предложении после UPDATE, которое не имеет смысла в его текущей форме.
С учетом сказанного, мой друг сказал это в поддержку альтернативных тегов стандартизированный в стиле asp, таких как <%, а не <?, который является параметром asp_tags в php.ini. Вот его рассуждения:
... arbitrary conventions should be standardized. That is, any time we are faced with a set of possibilities that are all of equal value - such as what weird punctuation our programming language should use to demarcate itself - we should pick one standard way and stick with it. That way we reduce the learning curve of all languages (or whatever the things the convention pertains to).
Для меня это звучит хорошо, но я не думаю, что кто-то из нас может объезжать фургоны вокруг этого дела. А пока я бы придерживался полной версии <?php.
Давайте смотреть правде в глаза. Без коротких тегов PHP чертовски уродлив.
Вы можете включить их в файле .htaccess, если не можете получить доступ к php.ini:
php_flag short_open_tag on
Ложь. Иногда сервер настроен на запрет любого переопределения, сэр.
Верно, но если ваш хост не позволяет вам переопределить с помощью htaccess, вам действительно нужен новый хост! :)
не работает в интерфейсе командной строки, а php_flag не поддерживается постоянно
Проблема всего этого обсуждения заключается в использовании PHP в качестве языка шаблонов. Никто не утверждает, что теги следует использовать в исходных файлах приложений.
Однако встраиваемый синтаксис PHP позволяет использовать его в качестве мощного языка шаблонов, а шаблоны должны быть как можно более простыми и удобочитаемыми. Многие считают, что проще использовать гораздо более медленный дополнительный механизм шаблонов, такой как Smarty, но для тех пуристов из нас, которым требуется быстрый рендеринг и чистый код, PHP - единственный способ писать шаблоны.
ЕДИНСТВЕННЫЙ допустимый аргумент ПРОТИВ использования коротких тегов состоит в том, что они поддерживаются не на всех серверах. Комментарии о конфликтах с XML-документами смехотворны, потому что вам, вероятно, в любом случае не следует смешивать PHP и XML; и если да, то вы должны использовать PHP для вывода строк текста. Безопасность никогда не должна быть проблемой, потому что если вы помещаете конфиденциальную информацию, такую как учетные данные для доступа к базе данных, в файлы шаблонов, тогда у вас есть более серьезные проблемы!
Теперь, что касается поддержки серверов, по общему признанию, нужно знать их целевую платформу. Если виртуальный хостинг является вероятной целью, следует избегать коротких тегов. Но для многих профессиональных разработчиков (таких как я) клиент признает (и действительно, это зависит от факта), что мы будем диктовать требования к серверу. Часто я сам отвечаю за настройку сервера.
И мы НИКОГДА не работаем с хостинг-провайдером, который не дает нам абсолютного контроля над конфигурацией сервера - в таком случае мы можем рассчитывать на гораздо больше проблем, чем просто потеря поддержки коротких тегов. Этого просто не бывает.
Так что да - я согласен с тем, что использование коротких тегов следует тщательно взвешивать. Но я также твердо уверен, что это ВСЕГДА должно быть вариантом, и что разработчик, знающий о своей среде, должен свободно использовать их.
Если по какой-то причине у вас был настроен apache для передачи файлов .xml в mod_php, то <? Xml было бы головной болью с короткими тегами. Но это явно странная установка.
Язык создание шаблонов, который нельзя встроить без обходных путей в некоторые типы выходных документов, является большой ошибкой. Единственная причина, по которой у меня не должно быть шаблона XML с кодом PHP и короткими тегами, заключается в том, что он не работает, а не потому, что в нем нет смысла.
Воспользоваться преимуществами PHP как быстрого и удобного языка шаблонов - это не большая ошибка. Как я сказал ранее, нужно взвесить преимущества и недостатки и написать код таким образом, чтобы он соответствовал выбранному вами подходу. Не отказывайтесь категорически от правильного подхода только потому, что он не работает в одном конкретном сценарии (который можно легко обойти).
Я категорически не отвергаю какой-либо действительный подход (см. Мой ответ на вопрос). Вы тот, кто категорически отвергает PHP в XML, цитирую: «в любом случае не следует смешивать PHP и XML». Кроме того, большой ошибкой, о которой я говорил, было решение использовать <? в качестве короткого тега, потому что это приводит к некрасивым обходным путям в XML. Тем не менее, я согласен с тем, что это вопрос взвешивания преимуществ и недостатков, и что если вы знаете, что делаете, вы, безусловно, можете это сделать. Но это не делает <? хорошим выбором.
Я немного опоздал на вечеринку, но мне очень нравится этот ответ, и он отражает мой опыт работы с ситуацией. Хотя у нас есть некоторые разногласия по этому поводу в нашем офисе, я могу сказать, что, работая над php почти каждый день в течение многих лет, я никогда не сталкивался с этой проблемой. Когда PHP используется для генерации XML, по моему опыту, он всегда находился в контексте высокодинамичного контента, который никогда не создавался напрямую через PHP, поэтому проблема просто никогда не возникает.
Проблема в том, что ваш пользовательский вывод не экранирован должным образом, и желание сохранить код минимальным, а не правильным, усугубит это. Если вы уже делаете больше, чем просто вывод значения, вы можете добавить 7 символов.
Я прочитал эту страницу после того, как искал информацию по теме, и я чувствую, что не упоминается одна важная проблема: лень против последовательности. «Настоящие» теги для PHP - это <? Php и?>. Почему? Мне все равно. Зачем вам использовать что-то еще, если это явно для PHP? <% и%> для меня означают ASP, а <script ..... означает Javascript (в большинстве случаев). Так почему бы не придерживаться стандарта для обеспечения согласованности, быстрого обучения, переносимости и простоты?
С другой стороны, я согласен с тем, что короткие теги в шаблонах (и ТОЛЬКО в шаблонах) кажутся полезными, но проблема в том, что мы потратили так много времени на обсуждение этого здесь, что, вероятно, потребуется очень много времени, чтобы действительно потратить столько времени набирает лишние три символа «php» !!
Хотя наличие множества опций - это хорошо, это совсем не логично и может вызвать проблемы. Представьте себе, если бы каждый язык программирования допускал 4 или более типов тегов: Javascript мог бы быть <JS или <script .... или <% или <? JS .... это было бы полезно? В случае PHP порядок синтаксического анализа, как правило, в пользу разрешения этих вещей, но язык во многих других отношениях не является гибким: он выдает уведомления или ошибки при малейших несоответствиях, но короткие теги используются часто. А когда короткие теги используются на сервере, который их не поддерживает, выяснение того, что не так, может занять очень много времени, поскольку в некоторых случаях ошибка не выдается.
Наконец, я не думаю, что здесь проблема с короткими тегами: есть только два логических типа блоков кода PHP: 1) обычный код PHP, 2) эхо-шаблоны. Что касается первого, я твердо верю, что должны быть разрешены только <? Php и?>, Чтобы все было согласованным и переносимым. Для последнего метод <? = $ Var?> Уродлив. Почему так должно быть? Почему бы не добавить что-нибудь более логичное? <? php $ var?> Это ничего не сделает (и только в самых отдаленных случаях может с чем-то конфликтовать), и это может легко заменить неудобный синтаксис <? =. Или, если это проблема, возможно, они могли бы использовать вместо этого <? Php = $ var?> И не беспокоиться о несоответствиях.
Там, где есть 4 варианта открытия и закрытия тегов и случайное добавление специального тега «echo», PHP может также иметь флаг «настраиваемые теги открытия / закрытия» в php.ini или .htaccess. Таким образом дизайнеры могут выбрать тот, который им больше всего нравится. Но по понятным причинам это перебор. Так зачем допускать 4+ варианта?
ИМХО люди, которые используют короткие теги, часто забывают избежать того, что они повторяют. Было бы неплохо иметь механизм шаблонов, который по умолчанию выполняет экранирование. Я полагаю, что Роб А. написал быстрый хак, позволяющий избегать коротких тегов в приложениях Zend Frameworks. Если вам нравятся короткие теги, потому что они упрощают чтение PHP. Тогда может ли Smarty быть лучшим вариантом?
{$myString|escape}
для меня это выглядит лучше, чем
<?= htmlspecialchars($myString) ?>
Для большинства PHP-программистов второй вариант имеет больше смысла, чем первый, просто потому, что это реальная функция PHP, с которой мы знакомы, в то время как первый вариант - это псевдошаблонный код, который мы должны изучить поверх PHP. PHP уже является языком шаблонов, добавляя еще один язык шаблонов поверх него, как Smarty, является избыточным IMO.
Twig - это шаблонизатор с включенным экранированием HTML по умолчанию twig.sensiolabs.org
Начиная с PHP 5.4, ярлык эха представляет собой отдельную проблему от ярлыков, так как ярлык эха всегда будет включен. Теперь это факт:
Таким образом, сам ярлык эха (<?=) теперь безопасен для использования.
Я бы сказал, что это единственный необходимый «короткий тег». <?php можно использовать в начале всех файлов классов, а затем у вас есть <?= для ваших представлений. беспроигрышный.
So the echo shortcut itself (<?=) is safe to use ... если вам удобнее использовать PHP 5.4. Широко распространенные приложения PHP (например, wordpress) не могут позволить себе роскоши требовать 5.4, и даже продолжали предлагать поддержку PHP 4 до 2011 года - полных 7 лет после выпуска PHP 5. Если вы находитесь в таком месте, как facebook, где все установки вашего программного обеспечения напрямую управляются самой компанией, то требовать поддержки 5.4 намного проще, чем если бы вы работали над таким проектом, как wordpress.
@dukeofgaming, Ничего себе, хороший улов, не знал, что их версии SVN доступны в сети.
http://uk3.php.net/manual/en/language.basic-syntax.phpmode.php дает множество советов, в том числе:
while some people find short tags and ASP style tags convenient, they are less portable, and generally not recommended.
и
note that if you are embedding PHP within XML or XHTML you will need to use the
<?php ?>tags to remain compliant with standards.
и
Using short tags should be avoided when developing applications or libraries that are meant for redistribution, or deployment on PHP servers which are not under your control, because short tags may not be supported on the target server. For portable, redistributable code, be sure not to use short tags.
Чтобы избежать проблем с переносимостью, начинайте теги PHP с <?php, и если ваш файл PHP является чисто PHP, без HTML, вам не нужно использовать закрывающие теги.
Если кто-то все еще обращает на это внимание ... Начиная с PHP 5.4.0 Alpha 1 <?= всегда доступен:
http://php.net/releases/NEWS_5_4_0_alpha1.txt
Таким образом, похоже, что короткие теги (а) приемлемы и (б) останутся. По крайней мере, пока ...
<?= не считается коротким тегом с версии 5.4.
<? отключен по умолчанию в более новых версиях. Вы можете включить это, как описано Включение коротких тегов в PHP.
Он отключен по умолчанию и в более старых версиях, не так ли.
<? отключен по умолчанию, но <?= был включен по умолчанию 5 лет назад.
Примечание. Начиная с PHP 5.4 короткий тег <?= теперь доступен всегда.
Их удобно использовать, когда вы работаете с фреймворком MVC или CMS, у которых есть отдельные файлы представления.
Это быстро, меньше кода, не сбивает дизайнеров с толку. Просто убедитесь, что конфигурация вашего сервера позволяет их использовать.
Ниже приводится замечательная блок-схема того же:

Источник: аналогичный вопрос о Software Engineering Stack Exchange
Здесь описывается, следует ли использовать короткий эхо-тег, а не то же самое, что короткие теги <?, упомянутые в вопросе (хотя он использовал тот же параметр конфигурации до 5.4)
Фактически, это должен быть ответ, который может понять каждый, хотя обстоятельства на самом деле не объясняются, почему вы не хотите использовать короткие теги во многих случаях (например, не можете изменить файл php.ini в системе общего хостинга)
Возникает вопрос, в чем смысл использования коротких тегов.
Быстрее набирать
MDCore сказал:
<?=is far more convenient than typing<?php echo
Да, это так. Вы избавляетесь от необходимости вводить 7 символов * X раз во всех сценариях.
Однако, когда для разработки, разработки и написания сценария требуется час, 10 часов или более, насколько актуальны несколько секунд времени, когда не набираются эти 7 символов здесь и там на протяжении всего сценария?
По сравнению с возможностью того, что некоторые основные или все сценарии не работают, если короткие теги не включены или включены, но обновление или изменение конфигурации ini-файла / сервера останавливает их работу, другие возможности.
Небольшая выгода, которую вы получаете, даже близко не перевешивает серьезность потенциальных проблем, то есть ваш сайт не работает или, что еще хуже, не работает только его часть и, следовательно, головная боль, которую нужно решать.
Легче читать
Это зависит от знакомство.
Я всегда видел и использовал <?php echo. Так что, хотя <?= нетрудно читать, он мне не знаком и, следовательно, не легче читать.
А с разделением фронтенд / бэкэнд-разработчиков (как и в большинстве компаний) будет ли фронтенд-разработчик, работающий над этими шаблонами, более знакомый, зная, что <?= равнозначно «PHP open tag and echo»?
Я бы сказал, что большинству будет удобнее выбрать более логичный вариант. То есть явный открытый тег PHP и потом происходящее «эхо» - <?php echo.
Оценка рисков
Проблема = весь сайт или основные скрипты не работают;
Потенциал проблемы - очень низко + серьезность результата - очень высоко = высокий риск
Заключение
Вы экономите несколько секунд здесь и там, не набирая несколько символов, но сильно рискуете из-за этого и, вероятно, в результате теряете удобочитаемость.
Внешние или внутренние кодеры знакомый с <?= с большей вероятностью поймут <?php echo, поскольку они являются стандартными вещами PHP - стандартным открытым тегом <?php и очень известным "echo" .
(Даже фронтенд-программисты должны знать «эхо», иначе они просто не будут работать с кодом, обслуживаемым фреймворком).
В то время как обратное маловероятно, вряд ли кто-то логически придет к выводу, что знак равенства в коротком теге PHP - это «эхо».
Это не имеет ничего общего с набором текста. Он короче и, следовательно, может быть проще читать. Человек, привыкший читать <?=, будет читать <?= легче, чем человек, привыкший читать <?php echo, читая <?php echo.
@Pacerier Shorter не просто = легче читать. Все мы разные. Вы имеете в виду, что для ты легче читать. Когда я вставляю свой ответ, поскольку я привык к <?php, я вижу, что весь код во много раз более знаком мне, чем <?= - знакомство облегчает задачу - но не обязательно лучше.
Нет, я не сравниваю вас и меня, я говорю, что человек, привыкший читать <?=, будет читать <?= лучше, чем человек, привыкший читать <?php echo, читать <?php echo. Это означает, что если у нас есть две идентичные копии человека X, и мы изменяем их только в том аспекте, в котором одна используется для чтения <?=, а другая - для чтения <?php echo, первая копия может достичь значения читаемости x при чтении с использованием его желаемый синтаксис, тогда как вторая копия может достичь значения читаемости y при чтении его желаемого синтаксиса, где x >= y.
Нет, вы упускаете суть. Я имею в виду потенциал системы, который не имеет ничего общего с конкретным человеком. Вы можете сказать, что люди, привыкшие печатать с помощью qwerty-клавиатуры, будут печатать быстрее с помощью qwerty, тогда как люди, которые привыкли печатать с помощью dvorak, будут печатать быстрее с dvorak, но факт не меняет тот факт, что две системы имеют разные возможности.
<?php ?> намного удобнее использовать, поскольку разработчики этого языка программирования значительно обновили свой базовый язык. Вы можете увидеть разницу между короткими и длинными тегами.
Короткие теги будут выделены светло-красным цветом, а более длинные - темнее!
Однако, повторяя что-то, например: <?=$variable;?> в порядке. Но предпочитаю более длинные ярлыки. <?php echo $variable;?>
Преобразуйте <? (без пробела в конце) в <?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'
Я подумал, что стоит упомянуть, что начиная с PHP 7:
<% … %> исчезли<? … ?> по-прежнему доступны, если для short_open_tag задано значение true. Это значение по умолчанию.<?=… ?> включены всегда, независимо от настройки short_open_tag.Скатертью к первому, так как он мешал другим языкам.
Теперь нет причин не использовать короткие теги для печати, кроме личных предпочтений.
Конечно, если вы пишете код, совместимый с устаревшими версиями PHP 5, вам нужно будет придерживаться старых правил, но помните, что все, что было до PHP 5.6, теперь не поддерживается.
См .: https://secure.php.net/manual/en/language.basic-syntax.phptags.php
Если я не ошибаюсь, ваш первый пункт неверен. В документе говорится, что теги ASP, а не короткие теги PHP, исчезли с PHP 7.0.0.
@reformed Вы абсолютно правы. Отредактирую свой ответ. Спасибо
Короткие теги всегда доступны в php. Таким образом, вам не нужно повторять первый оператор в вашем скрипте.
пример:
$a =10;
<?= $a;//10
echo "Hellow";//
echo "Hellow";
?>
Внезапно вам нужно использовать для одного скрипта php, тогда вы можете используй это. пример:
<html>
<head>
<title></title>
</head>
<body>
<p>hellow everybody<?= hi;?></p>
<p>hellow everybody </p>
<p>hellow everybody </p>
</body>
</html>
По состоянию на 2019 год я не согласен с некоторыми ответами здесь. Рекомендую использовать длинные теги
<?php /* code goes here */ ?>
или короткие эхо-теги
<?= /* code goes here */ ?>
Причина: они рекомендованы Базовый стандарт кодирования PSR-1
Использование других коротких тегов, таких как <? /* code goes here */ ?>, не рекомендуется.
В спецификации говорится:
PHP code MUST use the long tags or the short-echo tags; it MUST NOT use the other tag variations.
В php доступны 3 тега:
<?php ?> не требует указания каких-либо настроенных<? ?> доступен, если опция short_open_tag в
php.ini включен<?=, так как php 5.4.0 он всегда доступениз php 7.0.0 asp и тег скрипта удалены
Это не ответ на вопрос.
Чтобы ответить на вопрос
why, я бы процитировал руководство по сертификации Zend PHP 5: «Короткие теги какое-то время были стандартом в мире PHP; однако у них есть главный недостаток, заключающийся в конфликте с заголовками XML и, следовательно, несколько упал на обочину ".