почему в php файлах не рекомендуется ставить закрывающийся тег
Не раз видел что в файлах пхп нет закрывающегося тега ?>
С чем это связано и как правильно писать?
2 ответа 2
Если файл содержит только код PHP, предпочтительно опустить закрывающий тег в конце файла. Это помогает избежать добавления случайных символов пробела или перевода строки после закрывающего тега PHP, которые могут послужить причиной нежелательных эффектов, так как PHP начинает выводить данные в буфер при отсутствии намерения у программиста выводить какие-либо данные в этой точке скрипта.
И так и так будет правильно. Закрывающие теги обязательны для html файлов содержащих php код(хотя правильней будет сказать «php файлов содержащих html код). Но если у Вас файл только с php кодом, то закрывающий тег ставить не обязательно.
Если вдаваться в подробности, то для вывода php, серверу нужно не просто отдать браузеру файл «как есть»(как в случае с html) а вызвать php интерпретатор. PHP интерпретатор будет считывать(и выполнять) код до тех пор пока не встретит закрывающий тег или пока не встретит конец файла. Так что можете использовать и не использовать закрывающие теги.
Всё ещё ищете ответ? Посмотрите другие вопросы с метками php или задайте свой вопрос.
Связанные
Похожие
Подписаться на ленту
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.9.24.40305
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.
Почему бы опустить закрывающий тег?
Современные версии PHP устанавливают флаг output_buffering в php.ini
Если выходная буферизация включена, вы можете установить HTTP-заголовки и файлы cookie после вывода HTML-кода, потому что возвращенный код не отправляется в браузер немедленно.
Каждая книга хорошей практики и вики начинаются с этого «правила», но никто не приводит веских причин.
Есть ли еще одна веская причина пропустить конечный тег PHP?
Решение
Хотя я не могу вспомнить ни одной другой причины, отправка заголовков раньше обычного курса может иметь далеко идущие последствия. Ниже приведены лишь некоторые из них, которые пришли мне в голову в данный момент:
Хотя текущие версии PHP могут иметь буферизацию вывода, фактическая производственные серверы вы будете развертывать свой код на гораздо более важных машинах для разработки или тестирования. И они не всегда стремятся следовать последним тенденциям PHP сразу.
У вас могут быть головные боли из-за необъяснимого потеря функциональности. Скажем, вы реализуете какой-то платежный шлюз и перенаправляете пользователя на определенный URL после успешного подтверждения платежным процессором. Если произойдет какая-либо ошибка PHP, даже предупреждение или окончание лишней строки, платеж может остаться необработанным, а пользователю все равно может показаться, что счет не выставлен. Это также одна из причин, по которой ненужное перенаправление является злом, и если перенаправление должно использоваться, оно должно использоваться с осторожностью.
Вы можете получить ошибки типа «Загрузка страницы отменена» в Internet Explorer, даже в самых последних версиях. Это потому что AJAX В состав response / json include входит то, чего он не должен содержать из-за лишних окончаний строк в некоторых файлах PHP, как я встречал несколько дней назад.
Бонус: несколько ошибок (на самом деле один), связанных с этими 2 персонажами:
Другие решения
Причина, по которой вы не должны пропускать закрывающий тег php, заключается в том, что он вызывает дисбаланс в тегах php, и любой программист, не задумываясь, может забыть не добавлять лишние пробелы.
Итак, на ваш вопрос:
Есть ли еще одна веская причина пропустить заключительный тег php?
Нет не другой хорошая причина, чтобы пропустить конечные теги php.
Я закончу с некоторыми аргументами, чтобы не беспокоиться с закрывающим тегом:
Люди всегда могут совершать ошибки, независимо от того, насколько они умны.
Придерживаться практики, которая уменьшает количество возможных ошибок, — (ИМХО) хорошая идея.
PHP это не XML. PHP не должен придерживаться строгих стандартов XML, чтобы быть хорошо написанным и функциональным. Если отсутствующий закрывающий тег вас раздражает, вы можете использовать закрывающий тег, так или иначе, это не правило подстановки.
Несколько необычно открытие характеризуется как PHP притон (и полностью выполнимо за binfmt_misc ), подтверждая тем самым избыточность соответствующего закрытого тега.
СДМ и современные IDE предоставить встроенные решения в основном облегчает уход за близкими метками.
Закрыть варианты тегов
Это включает в себя еще несколько воплощений, из-за магии PHP новая линия еды:
? > \ п (Перевод строки Unix)
? > \р (Возврат каретки, классические MAC)
? > \р \ п (CR / LF, на DOS / Win)
PHP не поддерживает перевод строки Unicode NEL (U + 0085) однако.
Ранние версии PHP имели компиляции IIRC, что несколько ограничивало платформенность (FI даже только что использовал > как близкий маркер), который является вероятным историческим источником избегания близких меток.
«жесткий закрывающий тег«даже не один — просто придумал этот термин для аналогии. Концептуально и с точки зрения использования __halt_compiler однако должен быть признан близким знаком.
Тогда есть все виды мягкий / искусственный закрывать варианты тегов; менее известные и редко используемые, но обычно закомментирован лексемы:
Или модные заменители Юникода // ﹖﹥ (U + FE56 МАЛЕНЬКИЙ ВОПРОС ОЦЕНКА, U + FE65 МАЛЕНЬКИЙ УГОЛ БРЮКЕТА), который может понять регулярное выражение.
Таким образом, существуют контекстно-зависимые, но практические альтернативы упущению обязательного закрывающего тега.
тег phptags более аккуратный
https://fossil.include-once.org/phptags/
Но если он у вас есть, вы рискуете получить пробел после него.
Если вы затем используете его в качестве включения в верхней части документа, вы можете в конечном итоге вставить пробел (то есть содержимое), прежде чем пытаться отправить заголовки HTTP … что недопустимо.
не будет действительным
На этот раз вам должно быть лень быть безопасный.
Если файл представляет собой чистый код PHP, предпочтительно пропустить закрывающий тег PHP в конце файла. Это предотвращает случайные пробелы или новые строки, добавляемые после закрывающего тега PHP, что может вызвать нежелательные эффекты, потому что PHP начнет буферизацию вывода, когда программист не намерен отправлять какие-либо выходные данные в этот момент в сценарии.
Ну, есть два способа взглянуть на это.
Если вы верите первому маршруту, тогда все PHP-файлы требуют закрытия конечных тегов. Чтобы пропустить их, создаст недопустимый файл XML. Опять же, не имея открытия декларация, у вас все равно не будет действительного файла XML … Так что это не главная проблема …
Но я знаю, о чем ты думаешь. Вы думаете, что это имеет значение, вы никогда не собираетесь визуализировать PHP-файл напрямую, так кого волнует, является ли он действительным XML. Ну, это имеет значение, если вы разрабатываете шаблон. Если это допустимый XML / HTML, обычный браузер просто не будет отображать код PHP (он рассматривается как комментарий). Таким образом, вы можете макетировать шаблон без необходимости запуска кода PHP внутри …
Я не говорю, что это важно. Это просто мнение, которое я не вижу выраженным слишком часто, так что может быть лучше, чтобы поделиться этим …
Лично я не закрываю теги в файлах библиотеки, но делаю это в файлах шаблонов … Я думаю, что это личное предпочтение (и руководство по кодированию), основанное больше, чем на чем-либо сложном …
В дополнение ко всему, что уже было сказано, я добавлю еще одну причину, из-за которой нам было очень трудно отлаживать.
Каковы аргументы в пользу закрытия тегов PHP только для файлов PHP?
стандарт кодирования Zend Framework упоминает следующее:
Для файлов, содержащих только PHP-код, закрывающий тег («?>») не допускается. Это не требуется PHP, и его опущение предотвращает случайное введение конечных пробелов в ответ.
кто-нибудь знает о каких-либо проблемах (кроме проблемы с разработчиком симметрии), где вам нужно будет иметь закрывающие теги или они вообще плохая идея?
10 ответов
Если вы используете закрывающие теги PHP, вы можете легко найти файлы, которые были случайно усечены (например, не были загружены полностью).
Однако такая проблема должна быть исправлена, сделав файловую систему и передачи надежными, а не добавляя PHP «канарейки» теги 🙂
еще одна возможная причина заключается в том, что стандарты кодирования PEAR требуют этого. Они требуют этого, потому что они требуют этого, и вы не можете подвергать сомнению стандарты кодирования груши.
вы можете рассмотреть открывающий тег php для файлов только php, как своего рода строку shebang (например,#!/bin / bash), таким образом, вам не нужен закрывающий тег.
мы также следуем стандарту ZF, без закрывающего тега для файлов только php. Но я никогда не слышал о каком-либо инструменте, который не мог бы разобрать файл из-за отсутствующего закрывающего тега, и я еще не сталкивался с проблемами из-за того, что не использовал его.
Я всегда пишу закрывающий тег для файлов php и целенаправленно не следую за ним с пробелами или eol.
стандарт подразумевает, что если закрывающий тег опущен, он будет неявно предоставлен. Но это не освобождает разработчика от написания правильного html/xml.
и могут быть случаи, когда два файла объединяются вне обработки html/php, а отсутствующий тег вызовет крайнее горе.
независимо от того,» правильно «это или нет, я часто превращаю» чистые «PHP-файлы в» не чистые», и закрывающий тег чрезвычайно полезен.
Я всегда использую закрывающие теги, это просто не выглядит хорошо без них. Это также не действительная инструкция по обработке xml без них (не то, что вам все равно, если единственное, что в файле php)
мы используем Drupal, который всегда отсутствует закрывающий тег, и никогда не было никаких проблем из-за этого.
поскольку он всегда работал для Drupal (и я знал из чтения руководства, что это необязательно), я однажды создал файл конфигурации (который содержал только PHP-код) без закрывающего тега. По какой-то причине это не сработало, пока (по настоянию коллеги) я не добавил закрывающий тег. В то время мы не пытались выяснить причину.
Я всегда использовал закрытия тег в коде я пишу; он выглядит более симметричным, концептуально «закрывает» открывающий тег, и я всегда стараюсь не оставлять лишних пробелов после закрывающего тега.
проверка на ошибки в коде не работает, когда concating несколько файлов. Я использую следующую команду shell для проверки ошибок.
конечно, следующая команда все еще работает (и отображает имя файла поврежденного файла)
но этот намного медленнее.
наш офис работает с приложениями электронного обучения, встроенными во Flash, и мы обнаружили, что если закрывающий тег опущен из сценариев на стороне сервера, то он нарушает наш механизм связи с приложениями e-learnng.
одно предостережение к этому было бы то, что наш процесс debuggng сначала не попробовал его в упрощенной среде, чтобы убедиться, что это не комбинация отсутствующих закрывающих тегов и некоторых ошибочных выходных данных, поступающих из другого скрипта.
в ответ на @gabriel1836 закрывающие теги на стороне сервера не имеют значения, когда дело доходит до Flash-приложений; что актуально, так это полезная нагрузка, возвращаемая сервером в ответ на запрос удаленного взаимодействия Flash-приложением. Исключение закрывающего тега в файлах только PHP повлияет на это только в том случае, если ложные выходные данные не будут возвращены до отправки заголовков в приложение Flash.
в ответ на @CesarB, если вы не можете дать конкретный, воспроизводимый пример, все ты распространяешь ФАД. Руководство PHP очень ясно, что закрывающий тег является необязательным.
Правильные теги для PHP файлов
Закрывающий тег, который, кстати, пишется так
Закрывающий тег не является обязательным. Тем не менее, закрывающий тег может использоваться когда заканчивается PHP код и начинается, например, HTML код.
Пары могут использоваться в одном файле несколько раз, отделяя PHP код от HTML кода.
Важная вещь, которую нужно знать про закрывающий тег ?>: он выбросит вас из PHP в HTML даже если он закомментирован с помощью //. Однако комментарий /* */ справляется — тег ?> теряет своё специальное значение. Помните об этой интересной особенности, поскольку при комментировании блоков кода, вы можете столкнуться с необычной ситуацией, когда ?> продолжит работу не смотря на то, что вы этого не ожидаете.
Если вы поместите какой-то PHP код между этих тегов, то почти наверняка веб-браузер просто ничего не отобразит с новой версией PHP.
Почему не работает код в
В современных версиях PHP поддержка коротких тегов по умолчанию отключена. Причина в появлении формата XML, взгляните на следующую строку:
Эта строка содержит теги PHP, хотя на самом деле это элемент XML разметки. Чтобы избежать такой двусмысленности, сокращённые теги отключены, но их поддержку можно снова включить!
Как включить поддержку сокращённых тегов в PHP
В файле php.ini имеется директива:
Больше не работают и
Отделение PHP и HTML кода
Все, что находится вне пары открывающегося и закрывающегося тегов, игнорируется интерпретатором PHP, у которого есть возможность обрабатывать файлы со смешанным содержимым. Это позволяет PHP-коду быть встроенным в документы HTML, к примеру, для создания шаблонов.
Это работает так, как и ожидается, потому что когда интерпретатор PHP встречает закрывающие теги ?>, он просто начинает выводить все что найдёт (за исключением сразу следующего символа перевода строки) пока не встретит другой открывающий тег за исключением случая с содержащимся внутри кода условным оператором, в котором интерпретатор определяет результат условия перед принятием решения что пропустить. Ознакомьтесь со следующим примером.
Продвинутое изолирование с использованием условий:
В этом примере PHP пропускает блоки, где условие не соблюдается. Даже несмотря на то, что они находятся вне пары открывающих/закрывающих тегов, PHP пропустит их в соответствии с условием, так как интерпретатор PHP будет перепрыгивать через блоки, содержащиеся внутри условия, которое не соблюдается.
При выводе больших блоков текста выход из режима синтаксического разбора PHP обычно более эффективен, чем отправка текста с помощью функций echo или print.
Выход из HTML также применяется к другим управляющим операторам:
При выполнении приведённого выше фрагмента кода, мы получаем следующий вывод:
Разделение инструкций
Как в C или Perl, PHP требует окончания инструкций точкой запятой в конце каждой инструкции. Закрывающий тег блока PHP-кода автоматически применяет точку с запятой; т.е. нет необходимости ставить точку с запятой в конце последней строки блока с PHP-кодом. Закрывающий тег блока «поглотит» немедленно следующий за ним переход на новую строку, если таковой будет обнаружен.
Замечание: закрывающий тег PHP-блока в конце файла не является обязательным, и в некоторых случаях его опускание довольно полезно, например, при использовании include или require, так, что нежелательные пробелы не останутся в конце файла и вы все еще сможете добавить http-заголовки после подключения к ответу сервера. Это также удобно при использовании буферизации вывода, где также нежелательно иметь пробелы в конце частей ответа, сгенерированного подключаемыми файлами.
как создать только закрывающий тег xml в php
Помогите пожалуста в вопросе-буду при очень при очень многим балгодарен—как создать только.
.InnerText выдает пустоту, не видит закрывающий тег
Мне нужно получить текст в теге 222 Должен возвращать «222», но не.
Notepad++ Закрывающий тег разделителя по переходу на новую строку
Приветствую Как закрыть тег закоментированного текста при создании своего стиля? Если открывающий.
Решение
DrobyshevAlex, это тоже что и с константами 🙂
Ну так это совсем другой разговор. Где в топике про стандарт PSR-2 вообще сказано? То есть это оффтоп?
ps Proposing a Standards Recommendation
как переводится слово Recommendation?
мне одному кажется что оно не переводится как обязанность? 🙂
Вон в ПДД много что написано: на красный перебегать нельзя. А один взял и перебежал. И случилось чудо: он на другой стороне дороги. Значит можно!
Добавлено через 1 минуту
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Как заменить тег в результате на другой тег или спец символ
Здравствуйте, может кто сталкивался с такой задачей. Парсер парсит результат между тегами
CSS при последовательности *тег A тег IMG* добавить content
Здравствуйте многоуважаемые форумчане! Нуждаюсь в помощи! Итак вопрос: Возможно ли при.