Почему в php файлах не рекомендуется ставить закрывающийся тег

Обновлено: 07.07.2024

Я продолжаю читать, что плохой практикой является использование тега PHP close ?> в конце файла. Проблема заголовка кажется несущественной в следующем контексте (и пока это единственный хороший аргумент):

Каждая книга хорошей практики и вики начинаются с этого "правила", но никто не приводит веских причин. Есть ли еще одна веская причина пропустить заключительный тег PHP?

Хотя я не могу вспомнить ни одной другой причины, отправка заголовков раньше обычного курса может иметь далеко идущие последствия. Ниже приведены лишь некоторые из них, которые пришли мне в голову в данный момент:

Хотя в текущих выпусках PHP может быть включена буферизация вывода, фактические производственные серверы , на которых вы будете развертывать свой код, гораздо важнее, чем любые машины для разработки или тестирования. И они не всегда стремятся следовать последним PHP тенденциям сразу.

Вы можете испытывать головную боль из-за необъяснимой потери функциональности . Скажем, вы реализуете какой-то платежный шлюз и перенаправляете пользователя на определенный URL после успешного подтверждения платежным процессором. Если произойдет какая-либо ошибка PHP, даже предупреждение или окончание лишней строки, платеж может остаться необработанным, а пользователю все равно может показаться, что счет не выставлен. Это также одна из причин, по которой ненужное перенаправление является злом, и если перенаправление должно использоваться, оно должно использоваться с осторожностью.

Вы можете получить ошибки типа "Загрузка страницы отменена" в Internet Explorer, даже в самых последних версиях. Это связано с тем, что AJAX ответ/json include содержит что-то, чего не должно содержаться из-за лишних окончаний строк в некоторых PHP файлы, как я встречал несколько дней назад.

Если у вас есть загрузки файлов в вашем приложении, они тоже могут прерваться из-за этого. И вы можете не заметить этого даже спустя годы, поскольку специфическая привычка загрузки зависит от сервера, браузера, типа и содержимого файла (и, возможно, некоторых других факторов, с которыми я не хочу утомлять вас) ,.

Наконец, многие PHP фреймворки, включая Symfony , Zend и Laravel (об этом нет упоминания в руководящие принципы кодирования , но это следует примеру) и стандарт PSR-2 (пункт 2.2) требуют пропуска закрывающего тега. PHP само руководство ( 1 , 2 ), Wordpress , Drupal и многие другие PHP ПО, я думаю, советую сделать это. Если вы просто привыкли следовать стандарту (и настройке PHP-CS-Fixer для своего кода), вы можете забыть об этой проблеме. В противном случае вам всегда нужно будет помнить о проблеме.

Бонус: несколько ошибок (на самом деле один), связанных с этими двумя персонажами:

Я продолжаю читать, что использование закрывающего тега PHP ?> в конце файла - плохая практика. Проблема заголовка кажется неуместной в следующем контексте (и пока это единственный хороший аргумент):

Все хорошие практические книги и вики начинаются с этого «правила», но никто не предлагает веских причин. Есть ли еще одна веская причина пропустить закрывающий тег PHP?

Отправка заголовков раньше обычного может иметь далеко идущие последствия. Ниже приведены лишь некоторые из них, которые пришли мне в голову в данный момент:

В то время как в текущих выпусках PHP может быть включена буферизация вывода, фактические производственные серверы , на которых вы будете развертывать свой код, гораздо важнее, чем любые машины для разработки или тестирования. И они не всегда стремятся сразу же следовать последним трендам PHP.

У вас могут возникнуть головные боли из-за необъяснимой потери функциональности . Скажем, вы внедряете какой-то платежный шлюз и перенаправляете пользователя на определенный URL-адрес после успешного подтверждения обработчиком платежей. Если произойдет какая-то ошибка PHP, даже предупреждение или завершение лишней строки, платеж может остаться необработанным, и пользователю может показаться, что счет не выставлен. Это также одна из причин, почему ненужное перенаправление является злом, и если перенаправление должно использоваться, его следует использовать с осторожностью.

Вы можете получить ошибку типа «Загрузка страницы отменена» в Internet Explorer, даже в самых последних версиях. Это связано с тем, что ответ AJAX / json include содержит что-то, чего он не должен содержать из-за лишних окончаний строк в некоторых файлах PHP, с чем я столкнулся несколько дней назад.

Если в вашем приложении есть загрузки файлов , из-за этого они тоже могут прерваться. И вы можете не заметить этого даже спустя годы, поскольку конкретная привычка к прерыванию загрузки зависит от сервера, браузера, типа и содержимого файла (и, возможно, некоторых других факторов, которыми я не хочу вас утомлять) .

Наконец, многие фреймворки PHP, включая Symfony, Zend и Laravel (в рекомендации по кодированию, но он следует их примеру) и Стандарт PSR-2 (пункт 2.2) требует опустить закрывающий тег. Само руководство по PHP (1, 2), Wordpress, Drupal и многие другие программы PHP, я думаю, советуют это сделать. Если вы просто привыкли следовать стандарту (и настроили PHP-CS-Fixer для ваш код) вы можете забыть о проблеме. В противном случае вам всегда нужно будет держать эту проблему в уме.

Бонус: несколько ошибок (на данный момент одна), связанных с этими двумя персонажами:

Даже некоторые известные библиотеки могут содержать лишние окончания строк после ?> . Примером является Smarty, даже самые последние версии веток 2. * и 3. * имеют это. Итак, как всегда, следите за сторонним кодом . Бонус в качестве бонуса: регулярное выражение для удаления ненужных окончаний PHP: замените (\s*\?>\s*)$ пустым текстом во всех файлах, содержащих код PHP.

Причина, по которой вы должны оставить закрывающий тег php ( ?> ), заключается в том, чтобы программист случайно не отправил лишние символы новой строки.

Причина, по которой вы не должны оставлять закрывающий тег php, заключается в том, что он вызывает дисбаланс в тегах php, и любой программист со слабым умом может помнить, что не следует добавлять лишние пробелы.

Так что для вашего вопроса:

Есть ли еще одна веская причина пропустить конечный тег php?

Нет, нет другой веской причины пропускать конечные теги php.

Я закончу некоторыми аргументами, чтобы не беспокоиться о закрывающем теге:

Люди всегда могут ошибаться, какими бы умными они ни были. Придерживаться практики, которая снижает количество возможных ошибок, (ИМХО) - хорошая идея.

PHP - это не XML. PHP не обязательно должен придерживаться строгих стандартов XML, чтобы быть хорошо написанным и функциональным. Если отсутствующий закрывающий тег вас раздражает, вам разрешено использовать закрывающий тег, это не так или иначе неукоснительное правило.

Согласно документам, предпочтительно опустить закрывающий тег, если он находится в конце файла по следующей причине:

Если файл представляет собой чистый код PHP, предпочтительно не указывать закрывающий тег PHP в конце файла. Это предотвращает случайный пробел или добавление новых строк после закрывающего тега PHP, что может вызвать нежелательные эффекты, поскольку PHP начнет буферизацию вывода, когда программист не намерен отправлять какие-либо выходные данные в этот момент в сценарии.

Очень полезно не пропускать закрывающий ?> .

Файл остается действительным для PHP (не является синтаксической ошибкой), и, как сказал @David Dorward, он позволяет избежать пробелов / разрывов (всего, что может отправлять заголовок в браузер) после ?> .

Не будет действительным.

На этот раз вы должны быть ленивыми, чтобы быть защищенным .

Что ж, я знаю причину, но не могу ее показать:

Для файлов, содержащих только код PHP, закрывающий тег ( ?> ) никогда не разрешенный. Это не требуется для PHP, и его пропуск предотвращает случайная инъекция оставшегося белого пробел в ответ.

Что ж, есть два взгляда на это.

Код PHP - это не что иное, как набор инструкций по обработке XML, и, следовательно, любой файл с расширением .php является не чем иным, как файлом XML, который случайно анализируется на предмет наличия кода PHP.
Так получилось, что PHP использует формат инструкций по обработке XML для своих тегов open и close. Исходя из этого, файлы с расширениями .php МОГУТ быть допустимыми файлами XML, но это не обязательно.

Если вы верите в первый маршрут, то все файлы PHP требуют закрывающих закрывающих тегов. Если их пропустить, будет создан недопустимый файл XML. С другой стороны, без открывающего объявления <?xml version="1.0" charset="latin-1" ?> у вас все равно не будет действительного XML-файла . Так что это не главная проблема .

Если вы верите во второй путь, это открывает дверь для двух типов файлов .php :

Файлы, содержащие только код (например, файлы библиотеки)
Файлы, содержащие собственный XML, а также код (например, файлы шаблонов)

Исходя из этого, файлы, содержащие только код, могут заканчиваться без закрывающего тега ?> . Но файлы XML-кода не могут заканчиваться без закрытия ?> , поскольку это сделало бы XML недействительным.

Но я знаю, о чем вы думаете. Вы думаете, какое это имеет значение, вы никогда не собираетесь рендерить файл PHP напрямую, так что кого волнует, действительный ли это XML. Что ж, это имеет значение, разрабатываете ли вы шаблон. Если это действительный XML / HTML, обычный браузер просто не будет отображать PHP-код (он обрабатывается как комментарий). Таким образом, вы можете смоделировать шаблон без необходимости запускать PHP-код внутри .

Я не говорю, что это важно. Это просто точка зрения, которую я не вижу слишком часто, так что где лучше поделиться ею .

Лично я не закрываю теги в файлах библиотеки, но делаю это в файлах шаблонов . Я думаю, что это личные предпочтения (и рекомендации по кодированию), основанные больше, чем что-либо сложное .

В дополнение ко всему, что уже было сказано, я собираюсь указать еще одну причину, по которой нам было очень трудно отлаживать.

Apache 2.4.6 с PHP 5.4 на самом деле приводит к сбою сегментации на наших производственных машинах, когда за закрытием остается пустое место Тег php . Я потратил впустую часы, пока наконец не решил проблему с помощью strace.

Вот ошибка, которую выдает Apache:

«Есть ли еще одна веская причина (кроме проблемы с заголовком), чтобы пропустить конечный тег php?»

Вы не хотите непреднамеренно выводить лишние символы пробела при генерации двоичного вывода, данных CSV, или другой вывод, отличный от HTML.

Избегает головной боли при добавлении случайных пробелов после закрывающего тега, поскольку это нарушает поведение функции header () . Некоторые редакторы или FTP-клиенты / серверы также могут автоматически изменять конец файлов (по крайней мере, это их конфигурация по умолчанию). , а Zend даже запрещает это.

Вывод

Я бы сказал, что аргументы в пользу исключения тега выглядят убедительнее (помогает избежать большой головной боли с помощью header () + это «рекомендация» PHP / Zend). Я признаю, что это не самое «красивое» решение, которое я когда-либо видел с точки зрения согласованности синтаксиса, но что может быть лучше?

Поскольку мой вопрос был отмечен как дубликат этого, я думаю, что все в порядке. по некоторым причинам может быть желательно опубликовать, почему НЕ опущен закрывающий тег ?> .

С полным синтаксисом инструкций обработки ( <?php . ?> ) источником PHP является действительный документ SGML, который можно без проблем анализировать и обрабатывать с помощью синтаксического анализатора SGML. С дополнительными ограничениями он также может быть допустимым XML / XHTML.

Ничто не мешает вам написать корректный код XML / HTML / SGML. Об этом известно в документации PHP. Отрывок:

Примечание. Также обратите внимание, что если вы встраиваете PHP в XML или XHTML, вам нужно будет использовать теги , Чтобы соответствовать стандартам.

Конечно, синтаксис PHP не является строгим SGML / XML / HTML, и вы создаете документ, который не является SGML / XML / HTML, точно так же, как вы можете преобразовать HTML в XHTML, чтобы он был совместим с XML или нет.

В какой-то момент вы можете захотеть объединить источники. Это будет не так просто, как просто выполнить cat source1.php source2.php , если у вас есть несогласованность, вызванная отсутствием закрывающих тегов ?> .

Без ?> труднее определить, был ли документ оставлен в режиме выхода PHP или в режиме игнорирования PHP (тег PI <?php мог быть открыт или нет). Жизнь станет проще, если вы будете постоянно оставлять свои документы в режиме игнорирования PHP. Это похоже на работу с хорошо отформатированными HTML-документами по сравнению с документами с незакрытыми, плохо вложенными тегами и т. Д.

Похоже, что у некоторых редакторов, таких как Dreamweaver, могут возникнуть проблемы с открытием PI [1].

Если я правильно понимаю вопрос, это связано с буферизацией вывода и влиянием, которое это может иметь на закрытие / завершение тегов. Я не уверен, что это вполне обоснованный вопрос. Проблема в том, что выходной буфер не означает, что весь контент хранится в памяти перед отправкой его клиенту. Это означает, что часть контента есть.

Программист может целенаправленно очистить буфер или выходной буфер, поэтому действительно ли параметр выходного буфера в PHP влияет на то, как закрывающий тег влияет на кодирование? Я бы сказал, что это не так.

Но если он у вас есть, вы рискуете остаться после него пустым пространством.

Есть 2 варианта использования php-кода:

Код PHP, такой как определение класса или определение функции
Используйте PHP в качестве языка шаблонов (например, в представлениях)

В случае 1. закрывающий тег совершенно бесполезен, также я хотел бы видеть только 1 (один) открытый тег php и NO (ноль) закрывающий тег в таком случае. Это хорошая практика, поскольку она делает код чистым и отделяет логику от представления. Для случая презентации (2.) некоторые обнаружили, что естественно закрыть все теги (даже те, которые обрабатываются PHP), что приводит к недоразумениям, поскольку PHP фактически имеет 2 отдельных варианта использования, которые не следует смешивать: логика / исчисление. и презентация

ЭТО ВСЁ, что делается. Никаким образом невозможно записать хоть что-то в файл .php, в том числе и перед последним тегом, так как вывод обеспечивает СЕРВЕР, то есть в первую очередь надо что-то попытаться записать на сам Сервер, так как ЛЮБОЕ обращение к файлу .php никаким образом не выводит его сам и не может подключить его к записи.

Поэтому мне довольно весело читать, ТАКОЕ.

По поводу того, что есть переход на новую строку в конце файла: Поставьте их сто тысяч, от этого совсем НИЧЕГО не изменится, ИСПОЛНЯЕТСЯ всё то, что находится между тегами <?php ?>

По поводу того, что в Php многое не надо, например объявлять переменные и их свойства, и тот же конец файла .php - по поводу Первых - да, можно ничего не объявлять, но заключительный тег ставить надо обязательно, хотя бы по той причине, чтобы не НАПРЯГАТЬ сервер, когда он всё время будет не находить конец файла и сам станет его завершать по своему усмотрению (лишние ресурсы)

Алекс 777 Оракул (81730) Так Вы же смотрите ЗАЧЕМ и КТО ЭТО пишет PHP в Zend Framework'е ШИФРОВАНИЕ - вот, что это такое. ZEND уже давно шифрует .php файлы так, чтобы другие не могли распознать код. Это ТОЛЬКО их фишка, и не имеет к самому PHP ничего. Если Вы станете ШИФРОВАТЬ файлы их МЕТОДОМ, то и должны выдерживать ИХ СТАНДАРТЫ, только и всего. Если же Вы не будете ничего шифровать, а будет использовать обычные файлы php, то ни в коем случае, нельзя убирать последний тег.

Печаль. Полное не понимание концепции языка и его первичного назначения.
PHP родился как шаблонизатор. Всё, что находится вне тэгов ПХП будет просто выводится на печать во время интерпретации файла скрипта. И это стало первопричиной появления запрета на закрывающий тэг. Иначе, случайно попавшие после него пробельные символы просто вываливаются в браузер. Т.о. ломается вёрстка в IE, ломается установка заголовков.

Зенд не занимается шифрованием файлов. Область их разработок выходит за эти примитивные рамки.
Шифрованием занимается зенд-гвард. Оптимизацией занимается зенд-оптимайз. До недавнего времени оба продукта входили в один пакет и поставлялись вместе.

Когда PHP обрабатывает файл, он ищет открывающие и закрывающие теги, такие как <?php и ?> , которые указывают PHP, когда начинать и заканчивать обработку кода между ними. Подобный способ обработки позволяет PHP внедряться во все виды различных документов, так как всё, что находится вне пары открывающих и закрывающих тегов, будет проигнорировано парсером PHP.

PHP включает в себя короткий echo-тег <?= , который является сокращением для более многословного <?php echo .

1. <?php echo 'если вы хотите хранить код PHP в документах XHTML или XML,
то используйте эти теги' ; ?>

2. Вы можете использовать короткий 'echo'-тег чтобы <?= 'напечатать эту строку' ?> .
Этот тег эквивалентен такому коду
<?php echo 'напечатать эту строку' ?> .

3. <? echo 'этот код с короткими тегами, но он будет работать только если '.
'включена опция "short_open_tag"'; ?>

Короткие теги (третий пример) доступны по умолчанию, но их можно отключить с помощью директивы short_open_tag в конфигурационном файле php.ini или отключены по умолчанию, если PHP был скомпилирован с опцией --disable-short-tags.

Замечание:
Поскольку короткие теги можно отключить, рекомендуется использовать только обычные теги ( <?php ?> и <?= ?> ) для максимальной совместимости.

Если файл содержит только код PHP, предпочтительно опустить закрывающий тег в конце файла. Это помогает избежать добавления случайных символов пробела или перевода строки после закрывающего тега PHP, которые могут послужить причиной нежелательных эффектов, так как PHP начинает выводить данные в буфер при отсутствии намерения у программиста выводить какие-либо данные в этой точке скрипта.

<?php
echo "Hello world" ;

echo "Последнее выражение" ;

// Скрипт заканчивается тут без закрывающего тега PHP

User Contributed Notes 4 notes

If you want your file to be interpreted as php then your file must start and end with <?php and ?> and everything outside of that is ignored by the php parser.

<?php
php code .. //parsed
php code .. //parsed
?>
hellow..//normal test but ignred by php parser

Three types of tag are available in php
1.normal tag( <?php ?> )
2.short echo tag( <?= ?> )
3.short tag(<? ?>)

short tag are bydefault available but can be disabled by short_open_tag = Off and also disabled bydefault if php will built with --disabe--short--tags()

As short tag can be disabled so only use the normal and short echo tag.

If your file only have php code then do not use closing tag.
<?php
//php code;
//php code;
//php code;

but if you are embedding php with html then enclose php code with opening and closing tag .
< html >
< head >
</ head >
< body >
<? php
//php code;
//php code;
//php code;

If you want to just print single text or something ,you should use shorthand version . <?= $var ?>

But if you want to process something, you should use normal tag.
<?php
//$var = 3;
//$var2 = 2;
//$var3 = $var+$var2;
//if($var3)

?>

If you embedded php with html and single line, do not need to use semicolon
<html>
<head>
<body>
<?= $var ?>
</body>
</head>
</html>
but if you have multiple line, then use semicolon.
<?php
//line 1;
//line 2;
//line 3;
?>

There is no defference between normal( <?php ?> ) and short echo tag() but without uses of comments.
example:

<h1>Normal tag with c++ style oneline comment: <?php //"Normal tag"; ?> breaks php mode and return html mode </h1>

<h1>html code after (normal tag) <?php // and commnet then (closing tag) ?> breaks php mode and return html mode</h1>

but in short echo tag
<h1>html code after (short echo tag) <?php // and commnet then (closing tag) ?> breaks php mode and does not return html mode</h1>

You may want to know that removing semicolon is optional sometime but need to know the condition when it can be removed and when it can't be.
-------------------------------------------------------------------------
// Example 1: PHP script with closing tag at the end.
<?php

// you can remove semicolon
mysqli_close ( $db )
?>

// Example 2: PHP script without closing tag at the end.
<?php

// you can't remove semicolon
mysqli_close ( $db )

Everything inside a pair of opening and closing tag is interpreted by php parser. Php introduced three types of opening and closing tag.
1.Standard tags
<?php ?>
2.Short echo tag
<?= ?>
here, <?= is equivalent meaning of "<?php echo"
3.Short tag
<? ?>

Standard tag and short echo tag are alwayes available.
But short tag can be disabled either via the short_open_tag php.ini configuration file directive, or are disabled by default if PHP is built with the --disable-short-tags configuration.

If a file contains only PHP code, it is preferable to omit the PHP closing tag at the end of the file.
This prevents accidental whitespace or new lines being added after the PHP closing tag

Читайте также: