Закрывающийся тег php ?>
Если файл содержит только код PHP, предпочтительно опустить закрывающий тег в конце файла. Это помогает избежать добавления случайных символов пробела или перевода строки после закрывающего тега PHP, которые могут послужить причиной нежелательных эффектов, так как PHP начинает выводить данные в буфер при отсутствии намерения у программиста выводить какие-либо данные в этой точке скрипта.
Отслеживать
122k 24 24 золотых знака 124 124 серебряных знака 299 299 бронзовых знаков
ответ дан 23 янв 2013 в 16:29
7,418 17 17 серебряных знаков 22 22 бронзовых знака
И так и так будет правильно. Закрывающие теги обязательны для html файлов содержащих php код(хотя правильней будет сказать «php файлов содержащих html код). Но если у Вас файл только с php кодом, то закрывающий тег ставить не обязательно.
Если вдаваться в подробности, то для вывода php, серверу нужно не просто отдать браузеру файл «как есть»(как в случае с html) а вызвать php интерпретатор. PHP интерпретатор будет считывать(и выполнять) код до тех пор пока не встретит закрывающий тег или пока не встретит конец файла. Так что можете использовать и не использовать закрывающие теги.
Отслеживать
ответ дан 23 янв 2013 в 16:36
3,724 13 13 серебряных знаков 16 16 бронзовых знаков
То есть в современном PHP 8+ нет нужды опускать закрывающий тег, как это расписано здесь stackoverflow.com/questions/4410704/… ?
Как скрыть PHP код на сервере при условии что надо его править?
Есть PHP скрипты, классы, конфиги. Все это добро взаимосвязано, мне нужно дать доступ к серверу человеку чтобы он работал (запускал под рутом) с этими скриптами, при этом меняя только файлы конфигов, и чтобы не было возможности посмотреть исходный код.
Нашел разные обсфукаторы бесплатные превращающие код в нечто такое
ldc_aa08cb10($xol_e8b7be43[0],$xol_e8b7be43[1]);$krc_5bf7f45b[]=$uic_c59361f8;>catch(Exception $wky_efda7a5a)1. Как быть, если файлы конфигов имеют названия переменных и получается что при обсфукации основного рабочего кода переменные имеют другие названия? Не заставлять же каждый раз пользователя прогонять через обсфукацию поправленный конфиг? Пока что такой вариант видится единственным.
2. Есть ли возможность внутри сервера под Ubuntu как-то ограничить возможность копирования или просмотра или скачивания определенных файлов или сделать какие-то другие методы защиты-скрытия, но при этом с возможность запуска этого кода. Была мысль спрятать код где-нибудь в недрах папок файловой системы, обозвав рандомными названиями, а запускать как-нибудь через симлинки по названию файлов или что-нибудь в таком духе. Возможно ли?
3. Вариант не предоставлять root доступ к серверу, а осуществлять запуск через браузер, дать доступ только к FTP для заливки конфига в отдельную папку. Но тут есть ряд моментов — все скрипты выполняются вплоть до недели, и должны быть выполнены под root. Как это решить?
- Вопрос задан более трёх лет назад
- 2261 просмотр
[PHP] Закрыть тег
Я знал, что закрывающий тег важен, но когда я искал в Google, закрывающий тег требовался при его использовании с HTML, но когда был только PHP-код, закрывающий тег был необязательным, но необязательным.
Хотя это необязательно, но если разработчик случайно включает файл с пробелами после закрывающего тега, лучше опустить закрывающий тег для файлов, содержащих только код PHP, поскольку загрузка файлов с использованием заголовков вызовет ошибку или добавит ненужные пробелы. Это способ.
Ниже приводится контент, взятый с php.net.
Вы можете опустить закрывающий тег блока PHP в конце файла, что иногда бывает полезно.
Если вы используете include или require, вы можете добавить дополнительные заголовки ответов позже, убедившись, что нежелательные пробелы не помещаются в конец файла.
Это также полезно при использовании буферизации вывода, поскольку вы можете избежать нежелательных пробелов в конце каждой части во включенных файлах.
Закрывающий тег PHP?> В документе PHP не является обязательным для анализатора PHP.
Однако наличие пробелов после закрытого тега может привести к нежелательному выводу, ошибкам PHP или пустым страницам, которые не отображают последние, независимо от того, были ли они загружены разработчиком, пользователем или приложением FTP.
По этой причине все файлы PHP должны опускать закрывающий тег PHP и заканчиваться одной пустой строкой.
Стоит ли закрывать теги PHP-кода?
Даже те, кто скромно разбирается в PHP, знают, что код должен быть заключен в специальные теги .
примечание: альтернативные теги PHP
Вы также можете знать, что код PHP может быть разделен с помощью менее используемых тегов и . Если short_open_tag включен в php.ini, вы можете использовать хотя их следует избегать, если вы встраиваете код в XHTML или XML. Наконец, вы можете использовать теги в стиле ASP, если asp_tags установлен в php.ini.
Однако, если ваш файл содержит только PHP – и не содержит экранированного HTML-кода – закрывающий тег?> Не является обязательным. Многие разработчики утверждают, что ненужный код должен быть удален, но есть еще одна причина, по которой вы можете рассмотреть удаление закрывающего тега. Предположим, у нас есть библиотека функций PHP с именем library.php :
Библиотека включена в наш основной входной файл index.php :
End of index.php file.
К сожалению, при загрузке этой страницы появляются 2 предупреждения с одним и тем же сообщением:
Предупреждение: невозможно изменить информацию заголовка - заголовки уже отправлены
Или хуже, если вы могли бы работать в реальной среде, где предупреждения были отключены, и сообщение не появляется. В любом случае, ни заголовок, ни cookie не установлены, и это может вызвать критические проблемы приложения. Что вызывает ошибку? Вы не можете видеть это, но после закрывающего символа есть пробел?> В файле library.php. Когда он находится в верхней части index.php, это пространство отправляется в браузер как содержимое страницы вместе со всеми необходимыми заголовками HTTP. После отправки первого блока содержимого невозможно установить дополнительные заголовки или файлы cookie.
примечание: выходная буферизация PHP
Современные версии PHP устанавливают флаг output_buffering в php.ini. Это буферизует ваш вывод HTML и отправляет его, когда ваш PHP-код был обработан или когда буфер достигает предела (например, 4096 байт). Вы также можете использовать PHP ob_start() ob_end_flush() Даже если вы уверены, что буферизация всегда включена, рекомендуется установить заголовки HTTP и файлы cookie перед отправкой содержимого страницы.
Ваше PHP-приложение может включать в себя десятки файлов библиотек или классов. Как вы можете себе представить, может быть трудно найти дополнительные пробелы, возврат каретки или любые другие символы после закрытия?>. К счастью, это легко исправить. Если вы пропустите закрытие?> Во всех ваших файлах кода только для PHP, ошибка просто не может произойти – парсер будет игнорировать пробелы. Это решение, но вы бы его использовали? Это заставляет меня чувствовать себя немного грязным … Вы уже опускаете закрывающий тег?>? Примешь ли ты практику? Или это просто неправильно?