Warum sollte man das Close-Tag weglassen?

Question

Ich lese immer wieder, dass es schlechte Praxis ist, den PHP-close-Tag zu verwenden ?> am Ende der Datei. Das Kopfzeilenproblem scheint in folgendem Zusammenhang irrelevant zu sein (und dies ist bisher das einzige gute Argument):

Moderne PHP-Versionen setzen das output_buffering-Flag in php.ini Wenn die Ausgabepufferung aktiviert ist, können Sie HTTP-Header und Cookies nach der HTML-Ausgabe setzen, da der zurückgegebene Code nicht sofort an den Browser gesendet wird.

Jedes gute Praxisbuch und jedes Wiki beginnt mit dieser "Regel", aber niemand liefert gute Gründe dafür. Gibt es einen weiteren guten Grund, den abschließenden PHP-Tag auszulassen?

Answer 1

Die vorzeitige Übermittlung von Kopfzeilen kann weitreichende Folgen haben. Im Folgenden sind nur einige davon aufgeführt, die mir gerade in den Sinn gekommen sind:

1. Während in aktuellen PHP-Versionen die Ausgabepufferung eingeschaltet sein kann, ist die eigentliche Produktionsserver auf denen Sie Ihren Code bereitstellen werden, sind weitaus wichtiger als Entwicklungs- oder Testrechner. Und diese neigen nicht immer dazu, den neuesten PHP-Trends sofort zu folgen.

2. Sie haben vielleicht Kopfschmerzen wegen unerklärlicher Funktionsverlust . Angenommen, Sie implementieren eine Art Zahlungs-Gateway und leiten den Benutzer nach erfolgreicher Bestätigung durch den Zahlungsprozessor zu einer bestimmten URL um. Wenn ein PHP-Fehler, sogar eine Warnung oder ein übermäßiges Zeilenende auftritt, kann die Zahlung unbearbeitet bleiben und der Benutzer scheint immer noch nicht bezahlt zu haben. Dies ist auch einer der Gründe, warum eine unnötige Umleitung von Übel ist, und wenn eine Umleitung verwendet werden soll, muss sie mit Bedacht eingesetzt werden.

3. Es kann vorkommen, dass Sie im Internet Explorer die Fehlermeldung "Page loading canceled" erhalten, selbst in den neuesten Versionen. Dies liegt daran, dass eine AJAX response/json include enthält etwas, das es nicht enthalten sollte, wegen der übermäßigen Zeilenenden in einigen PHP-Dateien, so wie ich es vor ein paar Tagen erlebt habe.

4. Wenn Sie etwas haben Datei-Downloads in Ihrer Anwendung, können sie deshalb auch kaputt gehen. Und es kann sein, dass Sie es nicht bemerken, selbst nach Jahren nicht, da die spezifische Abbruchgewohnheit eines Downloads vom Server, dem Browser, dem Typ und dem Inhalt der Datei (und möglicherweise einigen anderen Faktoren, mit denen ich Sie nicht langweilen möchte) abhängt.

5. Schließlich sind viele PHP-Frameworks, darunter Symfony , Zend und Laravel (es gibt keinen Hinweis darauf in der Kodierungsrichtlinien aber er folgt dem Anzug) und die PSR-2-Norm (Punkt 2.2) erfordern das Weglassen des schließenden Tags. Das PHP-Handbuch selbst ( 1 , 2 ), Wordpress , Drupal und viele andere PHP-Programme raten dazu, dies zu tun. Wenn Sie es sich einfach zur Gewohnheit machen, den Standard (und das Setup PHP-CS-Fixer für Ihren Code) können Sie das Problem vergessen. Andernfalls müssen Sie das Problem immer im Hinterkopf behalten.

Bonus: ein paar Probleme (derzeit eines) im Zusammenhang mit diesen beiden Charakteren:

1. Sogar einige bekannte Bibliotheken können überflüssige Zeilenenden nach ?> . Ein Beispiel ist Smarty, auch die neuesten Versionen der 2.* und 3.* Zweig haben diese. Also, wie immer, auf den Code von Dritten achten . Bonus im Bonus: Eine Regex zum Löschen unnötiger PHP-Endungen: replace (\s*\?>\s*)$ mit leerem Text in allen Dateien, die PHP-Code enthalten.

Answer 2

Der Grund, warum Sie den abschließenden php-Tag weglassen sollten ( ?> ) dient dazu, dass der Programmierer nicht versehentlich zusätzliche Zeilenumbrüche sendet.

Der Grund, warum man das php-Schließungs-Tag nicht weglassen sollte, ist, dass es ein Ungleichgewicht in den php-Tags verursacht, und jeder Programmierer, der halbwegs bei Verstand ist, kann sich daran erinnern, keinen zusätzlichen Leerraum hinzuzufügen.

Also zu Ihrer Frage:

Gibt es einen anderen guten Grund, den abschließenden php-Tag zu überspringen?

Nein, es gibt keine eine andere ein guter Grund, die abschließenden php-Tags zu überspringen.

Abschließend möchte ich noch einige Argumente anführen, die dafür sprechen, sich nicht um den abschließenden Tag zu kümmern:

1. Menschen sind immer in der Lage, Fehler zu machen, egal wie klug sie sind. Sich an eine Praxis zu halten, die die Anzahl möglicher Fehler reduziert, ist (IMHO) eine gute Idee.

2. PHP ist nicht XML. PHP muss sich nicht an die strengen Standards von XML halten, um gut geschrieben und funktional zu sein. Wenn Sie sich über einen fehlenden schließenden Tag ärgern, dürfen Sie einen schließenden Tag verwenden, das ist keine feststehende Regel.

Answer 3

Es ist ein Empfehlung für Einsteiger in die Codierung , gut gemeint und beraten nach dem Handbuch .

• Verzicht auf ?> löst jedoch nur ein Rinnsal der gemeinsamen bereits gesendete Kopfzeilen verursachen (Rohausgabe, STÜCKLISTE Mitteilungen usw.) und deren Folgeprobleme.

• PHP enthält einen Zauber, der einzelne Zeilenumbrüche nach der ?> Schlusszeichen. Allerdings hat das historische Fragen und macht Neulinge immer noch anfällig für fehlerhafte Editoren und das unbewusste Einfügen anderer Leerzeichen nach ?> .

• Stilistisch bevorzugen einige Entwickler die Ansicht <?php y ?> als SGML-Tags / XML-Verarbeitungsanweisungen, was die Gleichgewichtskonsistenz eines abschließenden Tokens impliziert. (Was im Übrigen, nützlich ist für die Verbindung von Klassen-Includes in Abhängigkeiten, um das ineffiziente automatische Laden von einzelnen Dateien zu ersetzen).

• Etwas unüblich ist die Eröffnung <?php wird als PHPs bezeichnet shebang (und vollständig durchführbar per binfmt_misc ), wodurch die Redundanz eines entsprechenden Close-Tags bestätigt wird.

• Es gibt eine offensichtliche Beratungsdiskrepanz zwischen klassische PHP-Syntax-Anleitungen Beauftragung von ?>\n und die mehr die jüngsten (PSR-2) Einvernehmen über die Unterlassung.
  (Für das Protokoll: Die Tatsache, dass Zend Framework das eine dem anderen vorzieht, bedeutet nicht, dass es von Natur aus überlegen ist. Es ist ein Missverständnis, dass Experten auf / Zielgruppe von unhandlichen APIs gezogen wurden).

• SCMs und moderne IDEs eingebaute Lösungen anbieten was vor allem die Pflege von Anhängern erleichtert.

Abraten von jeglicher Verwendung des ?> close-Tag verzögert lediglich die Erklärung des grundlegenden PHP-Verarbeitungsverhaltens und der Sprachsemantik, um selten auftretende Probleme zu vermeiden. Es ist praktisch noch für die kollaborative Softwareentwicklung aufgrund der unterschiedlichen Fähigkeiten der Teilnehmer.

Tag-Variationen schließen

• En regelmäßig ?> close-Tag ist auch bekannt als T_CLOSE_TAG oder auch "close token".

• Es umfasst einige weitere Inkarnationen, wegen PHPs Magie Newline-Essen :

  ?><strong>\n</strong> (Unix-Zeilenvorschub)

  ?><strong>\r</strong> (Carriage Return, klassische MACs)

  ?><strong>\r</strong><strong>\n</strong> (CR/LF, unter DOS/Win)

  PHP unterstützt den Unicode Combo Linebreak nicht <a href="http://en.wikipedia.org/wiki/Newline" rel="noreferrer">NEL</a> (U+0085) jedoch.

  Frühe PHP-Versionen hatten IIRC Compile-Ins, die die Plattformunabhängigkeit etwas einschränkten (FI benutzte sogar nur > als close marker), was der wahrscheinliche historische Ursprung der close-tag-avoidance ist.

• Oft übersehen, aber bis PHP7 beseitigt sie die regelmäßige <code><?php</code> Das Eröffnungs-Token kann sein gültig gepaart mit dem selten verwendeten <code></script></code> als ungerades Schlusszeichen .

• Die " Tag hart schließen " ist nicht einmal eine - ich habe diesen Begriff nur als Analogie erfunden. Konzeptionell und von der Verwendung her __halt_compiler sollten jedoch als naheliegende Token erkannt werden.

  __HALT_COMPILER();
  ?>

  Das bedeutet, dass der Tokenizer alle nachfolgenden Code- oder reinen HTML-Abschnitte verwirft. Insbesondere PHAR-Stubs machen davon Gebrauch, oder von der redundanten Kombination mit ?> wie abgebildet.

• Ebenso ist eine void return; selten in Include-Skripten ersetzt werden, so dass alle ?> mit nachgestelltem Leerzeichen unwirksam.

• Dann gibt es alle Arten von weich / faux Close-Tag-Varianten; weniger bekannt und selten verwendet, aber in der Regel per auskommentiert Spielsteine:

  • Einfache Abstände <code>// ? ></code> um die Erkennung durch PHPs Tokenizer zu umgehen.

  • Oder ausgefallene Unicode-Ersatzzeichen <code>// </code> (U+FE56 KLEINES FRAGEZEICHEN, U+FE65 KLEINER WINKELBOGEN), die ein regexp erfassen kann.

  Beide bedeutet nichts für PHP aber für externe Toolkits, die keine oder nur eine geringe PHP-Kompatibilität aufweisen, kann dies von praktischem Nutzen sein. Wiederum cat -verbundene Skripte in den Sinn kommen, mit dem Ergebnis // ? > <?php Verkettungen, die die frühere Aufteilung der Datei inline beibehalten.

Es gibt also kontextabhängige, aber praktikable Alternativen zu einer zwingenden Auslassung des Close-Tags.

Manuelles Babysitting von ?> close tags ist so oder so nicht sehr zeitgemäß. Dafür gab es schon immer Automatisierungswerkzeuge (und sei es nur sed/awk oder regex-oneliners). Im Besonderen:

phptags Tag ordentlicher

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

Die im Allgemeinen verwendet werden können, um --unclose php-Tags für den Code von Drittanbietern, oder beheben Sie einfach alle aktuellen Whitespace/BOM-Probleme:

• phptags --warn --whitespace *.php

Es behandelt auch --long Tag-Konvertierung usw. für Laufzeit-/Konfigurationskompatibilität.

Answer 4

Es ist keine Markierung

Aber wenn Sie ihn haben, riskieren Sie, dass nach ihm ein weißer Platz kommt.

Wenn Sie es dann als Include am Anfang eines Dokuments verwenden, könnte es passieren, dass Sie Leerraum (d.h. Inhalt) einfügen, bevor Sie versuchen, HTTP-Header zu senden was nicht erlaubt ist.

Answer 5

Selon le die Dokumente ist es aus folgendem Grund besser, den schließenden Tag am Ende der Datei wegzulassen:

Handelt es sich bei einer Datei um reinen PHP-Code, ist es besser, den PHP-Schließtag am Ende der Datei wegzulassen. Dadurch wird verhindert, dass nach dem PHP-Schließtag versehentlich Leerzeichen oder neue Zeilen eingefügt werden, was zu unerwünschten Effekten führen kann, weil PHP mit der Ausgabepufferung beginnt, obwohl der Programmierer an dieser Stelle des Skripts keine Ausgabe beabsichtigt.

PHP Manual > Sprachreferenz > Grundlegende Syntax > PHP-Tags