Чому варто пропустити тег закриття?

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

Сучасні версії PHP встановлюють прапор output_buffering у php.ini Якщо вихідний буфер включений, ви можете встановити заголовки та файли HTTP після виведення HTML, оскільки повернений код не надсилається в браузер негайно.

Кожна книжка та вікі з добрих практик починається з цього «правила», але ніхто не пропонує вагомих причин. Чи є ще одна вагома причина пропустити закінчуючий тег PHP?

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

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

2. У вас можуть боліти голоси через незрозумілу втрату функціоналу . Скажімо, ви реалізуєте якийсь шлюз платежів і перенаправляєте користувача до певної URL-адреси після успішного підтвердження платіжним процесором. Якщо трапляється якась помилка PHP, навіть попередження або надлишковий рядок, платіж може залишитися необробленим, а користувач може все ще здатись недійсним. Це також одна з причин того, що непотрібне перенаправлення є злом, і якщо перенаправлення потрібно використовувати, його потрібно застосовувати обережно.

3. У Internet Explorer, навіть в останніх версіях, можуть виникнути помилки типу "Скасовано завантаження сторінки". Це тому, що відповідь AJAX / json include містить щось, що не повинно містити через надлишкові закінчення рядків у деяких PHP-файлах, як я вже зустрічався кілька днів тому.

4. Якщо у вашій програмі є кілька завантажень файлів , вони також можуть зламатися через це. І ви можете цього не помітити навіть через роки, оскільки специфічна звичка завантаження залежить від сервера, браузера, типу та вмісту файлу (і, можливо, деяких інших факторів, я не хочу вас набридати) .

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

Бонус: кілька ґутів (насправді зараз один), пов'язаних із цими двома символами:

1. Навіть деякі відомі бібліотеки можуть містити надлишки закінчень рядків після ?>. Прикладом є Smarty, навіть у останніх версіях гілок 2. * і 3. * це є. Тож, як завжди, слідкуйте за стороннім кодом . Бонус в бонусі: регулярний вираз для видалення непотрібних закінчень PHP: замініть (\s*\?>\s*)$порожнім текстом у всіх файлах, що містять PHP-код.

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

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

Отже, для вашого питання:

Чи є ще одна вагома причина пропустити закінчуючий тег php?

Ні, немає ще однієї вагомої причини пропустити кінцеві теги PHP.

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

1. Люди завжди здатні робити помилки, якими б розумними вони не були. Дотримуватися практики, яка зменшує кількість можливих помилок - це (ІМХО) хороша ідея.

2. PHP не є XML. PHP не потрібно дотримуватися суворих стандартів XML, щоб бути добре написаними та функціональними. Якщо відсутній тег закриття дратує вас, ви можете використовувати тег закриття, це не правило встановлення в камінь так чи інакше.

Це рекомендація щодо стилю кодування для новачків , що має намір і радиться в посібнику .

• ?>Однак ухилення від розв’язання вирішує лише скрутну частину загальних заголовків, які вже надсилають причини (вихідні дані, BOM , повідомлення тощо) та проблеми їх подальшого спостереження.

• PHP насправді містить деяку магію, щоб поїсти поодинокі перерви після ?>закриття маркера. Хоча це має історичні проблеми і залишає новачків досі сприйнятливими до невмілих редакторів і невідомо перетасовуються в інші пробіли після ?>.

• Стилістично деякі розробники вважають за краще зору <?phpі , ?>як SGML / теги XML інструкції обробки, що передбачає узгодженість балансової задні близько маркер. (Який btw корисний для класу, що поєднує залежність, включає витіснення неефективного автозавантаження файлів за файлом.)

• Дещо нечасто отвір <?phpхарактеризується як PHPs shebang (і цілком можливо для binfmt_misc ), тим самим підтверджуючи надмірність відповідного тегу.

• Існує очевидна поради невідповідності між класичними посібниками синтаксису PHP, що мандатують, ?>\nта останніми (PSR-2), які погоджуються про пропущення.
  (Для запису: Zend Framework, що постулює один над іншим, не означає притаманної йому переваги. Помилковим є уявлення, що експерти зверталися до цільової аудиторії непростих API).

• SCM та сучасні IDE пропонують вбудовані рішення, що переважно полегшують догляд за тегами.

Відмовляння від будь-якого використання ?>тега-закриття просто затримує пояснення основних поведінки PHP-обробки та семантики мови для усунення нечастостей. Це практично все ще для спільної розробки програмного забезпечення через розбіжності в учасниках.

Закрити варіанти тегів

• Регулярний ?> закриває тег також відомий як T_CLOSE_TAG, або таким чином «закрити маркер».

• Вона включає в себе ще кілька втілень, з - за ПГПС чарівної нового рядка харчування :

  ?>\n (Unife linefeed)

  ?>\r (Повернення каретки, класичні MAC)

  ?>\r\n (CR / LF, у DOS / Win)

  PHP не підтримує комбіновану лінію Unicode NEL(U + 0085).

  Ранні версії PHP мали компіляцію IIRC, що обмежує платформа-агностицизм (FI навіть використовується лише >як закритий маркер), що є ймовірним історичним джерелом уникнення закритої теги.

• Часто не помічають, але поки PHP7 не видаляє їх , регулярний <?phpмаркер відкриття може бути дійсно парним з рідко використовуваним </script>як непарний маркер закриття .

• " Жорсткий тег закриття " навіть не один - просто склав цей термін за аналогією. __halt_compilerОднак концептуально та з використанням використання слід визнати близьким ознакою.

  __HALT_COMPILER();
  ?>

  В основному, токенізатор відкидає будь-який код або звичайний розділ HTML після цього. Зокрема, заглушки PHAR використовують це або його надлишкову комбінацію із ?>зображенням, як зображено.

• Так само недійсністьreturn; нечасто замінює сценарії включення, що робить будь-який ?>з пробілом пробілу неефективним.

• Тоді є всілякі варіації тегів / штучних закритих тегів; менш відомі та рідко використовуються, але зазвичай за маркованими коментарями :

  • Простий інтервал // ? >для ухилення від виявлення PHP-токенізатором.

  • Або вигадливі замінники Unicode // ﹖﹥(U + FE56 МАЛКА ПИТАННЯ ЗАПИТАННЯ, U + FE65 МАЛИЙ КОРОБКА КОРИСТУ), які може зрозуміти регулярний вираз

  Обидва нічого не означають для PHP , але можуть мати практичне використання для PHP, що не знає або напівінформоване, на зовнішніх наборах інструментів. Знову ж catприходять до уваги сценарії, що з'єднуються, з отриманими в результаті // ? > <?phpоб'єднаннями, які зберігають вбудований розділ файлів.

Отже, існують контекстно-залежні, але практичні альтернативи імперативному пропуску тегів.

Ручне няня ?>близьких тегів не є дуже сучасним. Для цього завжди були засоби автоматизації (навіть якщо тільки sed / awk або regex-oneliners). Зокрема:

phptags tag tidier

https://fossil.include-once.org/phptags/

Що зазвичай може використовуватися для --uncloseтегів php для стороннього коду, а точніше просто виправити будь-які (і всі) фактичні проблеми з пробілами / BOM:

• phptags --warn --whitespace *.php

Він також обробляє --longконвертацію тегів тощо для сумісності з виконанням / конфігурацією.

Це не тег ...

Але якщо у вас є, ви ризикуєте мати після нього білий простір.

Якщо потім використовувати його як включення у верхній частині документа, ви можете вставити пробіл (тобто вміст) перед тим, як спробувати надсилати заголовки HTTP…, що заборонено.

Досить корисно не допускати закриття ?> .

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

Наприклад,

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10);
    imagepng ( $img);
?>
[space here]
[break line here]

не буде дійсним.

Але

<?
    header("Content-type: image/png");
    $img = imagecreatetruecolor ( 10, 10 );
    imagepng ( $img );

буде.

Один раз ви повинні лінуватися, щоб бути захищеними .

Згідно з документами , бажано опустити тег закриття, якщо він знаходиться в кінці файлу з наступної причини:

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

PHP Керівництво> Довідник мови> Основний синтаксис> Теги PHP

Я знаю причину, але не можу її показати:

Для файлів, що містять лише PHP-код, тег завершення ( ?>) ніколи не дозволений. PHP цього не вимагає, і його опускання запобігає випадковому введенню білого простору у відповідь.

Джерело: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

Ну, є два способи на це.

1. PHP-код - це не що інше, як набір інструкцій з обробки XML , а отже, будь-який файл із a.php розширенням - це не що інше, як XML-файл, який так просто розбирається на код PHP.
2. PHP так буває, щоб поділитися форматом інструкцій з обробки XML для його відкритих і закритих тегів. Виходячи з цього, файли з .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тегом є порожнє місце . Я просто витрачав години, поки нарешті звузив помилку напругою .

Ось помилка, яку видає Apache:

[core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11)

"Чи є ще одна вагома причина (крім проблеми із заголовком), щоб пропустити закінчуючий тег php?"

Ви не хочете ненавмисно виводити сторонні символи пробілу під час генерування двійкового виводу, даних CSV чи іншого виводу, що не HTML.

Плюси

• Було б логічно закрити будь-який відкритий тег , як з іншими мовами. Не тільки теги X (HT) ML, але і фігурні дужки, дужки ...
• Менш заплутаних для початківців .

Мінуси

• Уникає головного болю при додаванні ненавмисних пробілів після закриття тегу, оскільки він порушує поведінку функції header () ... Деякі  редактори або FTP-клієнти / сервери також автоматично змінюють кінець файлів (принаймні, це їх конфігурація за замовчуванням)
• Посібник PHP говорить, що закриття тегу не є обов'язковим , а Zend навіть забороняє його .

Висновок

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

Оскільки моє запитання було позначене як дублікат цього, я думаю, що це нормально, щоб розмістити, чому НЕ пропускати тег закриття ?>може бути з певних бажаних причин.

• Повна інструкція з обробки Syntax ( <?php ... ?>) Джерелом PHP є дійсний документ SGML, який можна без проблем аналізувати та обробляти з аналізатором SGML. З додатковими обмеженнями це може бути дійсним і XML / XHTML.

Ніщо не заважає вам написати дійсний код XML / HTML / SGML. Про це знає документація PHP . Витяг:

Примітка. Також зверніть увагу, що якщо ви вбудовуєте PHP в XML або XHTML, вам потрібно буде використовувати теги <? Php?>, Щоб залишатися відповідними стандартам.

Звичайно, синтаксис 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 дійсно змінюється, як закривальний тег впливає на кодування? Я б стверджував, що це не так.

І, можливо, саме тому більшість відповідей сходили до особистого стилю та синтаксису.

Можливе використання PHP-коду:

1. PHP-код, такий як визначення класу або визначення функції
2. Використовуйте PHP як мову шаблону (тобто у переглядах)

у випадку 1. закриваючий тег є абсолютно невикористаним, також я хотів би побачити лише 1 (один) php відкритий тег та NO (нульовий) закриваючий тег у такому випадку. Це хороша практика, оскільки робить код чистим і відокремлює логіку від презентації. У випадку презентації (2.) деякі вважають, що природно закрити всі теги (навіть оброблювані PHP), що призводить до сумніву, оскільки PHP насправді має 2 окремі випадки використання, які не слід змішувати: логіка / обчислення та презентація