webentwicklung-frage-antwort-db.com.de

Warum sollte man das enge Etikett weglassen?

Ich lese weiter, es ist keine gute Praxis, das PHP close tag ?> am Ende der Datei. Das Header-Problem scheint im folgenden Kontext irrelevant zu sein (und dies ist das einzige gute Argument, das wir bisher anführen):

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

Jedes gute Übungsbuch und Wiki beginnt mit dieser "Regel", aber niemand bietet gute Gründe. Gibt es einen weiteren guten Grund, die Endung PHP tag? zu überspringen?) ==

361
danidacar

Das Versenden von Headern vor dem normalen Kurs kann weitreichende Konsequenzen haben. Im Folgenden sind nur einige davon aufgeführt, die mir gerade in den Sinn gekommen sind:

  1. Während in aktuellen PHP) Versionen möglicherweise die Ausgabepufferung aktiviert ist, sind die tatsächlichen Produktionsserver , auf denen Sie Ihren Code bereitstellen, weit entfernt wichtiger als alle Entwicklungs - oder Testmaschinen und sie folgen nicht immer sofort den neuesten PHP) - Trends.

  2. Möglicherweise haben Sie Kopfschmerzen wegen unerklärlichem Funktionsverlust . Angenommen, Sie implementieren ein Zahlungsgateway und leiten den Benutzer nach erfolgreicher Bestätigung durch den Zahlungsprozessor zu einer bestimmten URL weiter. Wenn eine Art PHP Fehler, sogar eine Warnung oder ein übermäßiges Zeilenende auftritt, bleibt die Zahlung möglicherweise unbearbeitet und der Benutzer scheint immer noch nicht in Rechnung gestellt zu sein. Dies ist auch einer der Gründe für die unnötige Umleitung ist böse und wenn Umleitung verwendet werden soll, muss mit Vorsicht vorgegangen werden.

  3. Möglicherweise werden in Internet Explorer auch in den neuesten Versionen Fehler vom Typ "Das Laden der Seite wurde abgebrochen" angezeigt. Dies liegt daran, dass ein [~ # ~] ajax [~ # ~] response/json include etwas enthält, das es wegen des Überschusses nicht enthalten sollte Zeilenenden in einigen PHP Dateien, so wie ich es vor ein paar Tagen erlebt habe.

  4. Wenn Sie einige Dateidownloads in Ihrer App haben, können diese aus diesem Grund ebenfalls unterbrochen werden. Und Sie werden es vielleicht auch nach Jahren nicht bemerken, da die spezifische Abbruchgewohnheit eines Downloads vom Server, dem Browser, der Art und dem Inhalt der Datei (und möglicherweise einigen anderen Faktoren, mit denen ich Sie nicht langweilen möchte) abhängt. .

  5. Schließlich gibt es viele PHP Frameworks, einschließlich Symfony , Zend und Laravel (darüber wird nichts erwähnt) In den Codierungsrichtlinien , aber es folgt der Anzug) und PSR-2-Standard (Punkt 2.2) muss das schließende Tag weggelassen werden. PHP = manuell selbst ( 1 , 2 ), Wordpress , Drupal und viele andere PHP Software Ich denke, raten Sie dazu. Wenn Sie sich einfach daran gewöhnen, den Standard (und Setup PHP-CS-Fixer für Ihren Code) zu befolgen, können Sie das Problem vergessen müssen immer das Thema im Kopf behalten.

Bonus: ein paar Fallstricke (aktuell einer) im Zusammenhang mit diesen 2 Charakteren:

  1. Sogar einige bekannte Bibliotheken enthalten möglicherweise überschüssige Zeilenenden nach ?>. Ein Beispiel ist Smarty, selbst die neuesten Versionen von 2. * und 3. * haben dies. Achten Sie daher wie immer auf den Code eines Drittanbieters . Bonus in Bonus: Ein regulärer Ausdruck für das Löschen unnötiger PHP Endungen: Ersetze (\s*\?>\s*)$ mit leerem Text in allen Dateien, die PHP code enthalten.
314
Halil Özgür

Der Grund, warum Sie das PHP-schließende Tag weglassen sollten (?>), damit der Programmierer nicht versehentlich zusätzliche Zeilenumbrüche sendet.

Der Grund, warum Sie das PHP-schließende Tag nicht auslassen sollten, ist, dass es ein Ungleichgewicht in den PHP-Tags verursacht und jeder Programmierer mit halbem Verstand daran denken kann, keinen zusätzlichen Leerraum hinzuzufügen.

Also für deine Frage:

Gibt es einen weiteren guten Grund, das End-PHP-Tag zu überspringen?

Nein, es gibt keinen weiteren guten Grund, die endenden PHP-Tags zu überspringen.

Abschließend möchte ich einige Argumente dafür anführen, dass ich mich nicht mit dem schließenden Tag beschäftige:

  1. Menschen können immer Fehler machen, egal wie klug sie sind. Das Festhalten an einer Praxis, die die Anzahl möglicher Fehler reduziert, ist (meiner Meinung nach) eine gute Idee.

  2. PHP ist kein XML. PHP muss sich nicht an die strengen XML-Standards halten, um gut geschrieben und funktionsfähig zu sein. Wenn Sie ein fehlendes schließendes Tag stört, dürfen Sie ein schließendes Tag verwenden. In-Stone-Regel auf die eine oder andere Weise.

120
zzzzBov

Es ist eine Empfehlung für den Codierungsstil von Neulingen , die gut gemeint und empfohlen ist im Handbuch .

  • Eschewing ?> Löst jedoch nur ein Rinnsal der allgemeinen Header, die bereits gesendet wurden, verursachen (Rohausgabe, - BOM , Hinweise usw.) und deren Folgeprobleme.

  • PHP enthält tatsächlich etwas Magie, um einzelne Zeilenumbrüche nach dem schließenden Token ?> Aufzuzehren. Allerdings hat das historische Probleme und lässt Neuankömmlinge immer noch anfällig für schuppige Editoren und unbewusst in anderen Leerzeichen nach ?> Mischen.

  • Stilistisch bevorzugen einige Entwickler die Anzeige von <?php Und ?> Als SGML-Tags/XML-Verarbeitungsanweisungen, was die Balance-Konsistenz eines nachgestellten Close-Tokens impliziert. (Welches übrigens ist nützlich für abhängigkeitsbezogene Klassen, um ineffizientes Datei-für-Datei-Autoloading zu ersetzen.)

  • Etwas ungewöhnlich ist die Eröffnung <?php Als PHPs Shebang (und vollständig durchführbar per binfmt_misc ) gekennzeichnet, wodurch die Redundanz eines entsprechenden Abschlusses validiert wird Etikett.

  • Es gibt eine offensichtliche Diskrepanz zwischen klassische PHP - Syntaxhandbücher?>\n Und den mehr neueren (PSR-2) Einigkeit über die Auslassung.
    (Um es festzuhalten: Das Postulieren von Zend Framework übereinander impliziert nicht seine inhärente Überlegenheit. Es ist ein Irrtum, dass Experten unhandliche APIs angesprochen haben).

  • SCMs und moderne IDEs stellen integrierte Lösungen bereit erleichtern meistens die Pflege in enger Nachbarschaft.

Das Ablehnen der Verwendung des Close-Tags ?> Verzögert lediglich die Erklärung des grundlegenden PHP Verarbeitungsverhaltens und der Sprachsemantik, um seltene Probleme zu vermeiden. Es ist immer noch praktisch für die kollaborative Softwareentwicklung, da sich die Kenntnisse der Teilnehmer unterscheiden.

Tag-Variationen schließen

  • Die reguläre  ?> Close-Tag wird auch als T_CLOSE_TAG oder somit als "Close-Token" bezeichnet.

  • Es enthält ein paar weitere Inkarnationen, weil PHPs magisches Newline-Essen :

    ?>\n (Unix-Zeilenvorschub)

    ?>\r (Wagenrücklauf, klassische MACs)

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

    PHP unterstützt den Unicode-Combo-Zeilenumbruch nicht NEL (U + 0085) jedoch.

    Frühe PHP Versionen hatten IIRC-Compile-Ins, die den Plattform-Agnostizismus etwas einschränkten (FI hat sogar gerade > Als Close-Marker verwendet), was der wahrscheinliche historische Ursprung der Close-Tag-Vermeidung ist.

  • Oft übersehen, aber bis PHP7 entfernt sie , die reguläre <?php Eröffnungstoken kann gültig mit dem selten verwendeten gepaart werden </script> als ungerades schließendes Token .

  • Das " Hard-Close-Tag " ist nicht einmal eines - nur dieser Begriff wurde für eine Analogie gut gemacht. Konzeptionell und in Bezug auf die Verwendung __halt_compiler sollte jedoch als nahes Zeichen erkannt werden.

    __HALT_COMPILER();
    ?>
    

    Im Grunde genommen verwirft der Tokenizer danach Code oder einfache HTML-Abschnitte. Insbesondere PHAR-Stubs nutzen dies oder die abgebildete redundante Kombination mit ?>.

  • Ebenso wird ein ungültiges return; in Include-Skripten selten ersetzt, wodurch jedes ?> Mit nachgestelltem Leerzeichen unwirksam wird.

  • Dann gibt es alle Arten von Soft/Faux Close-Tag-Variationen; weniger bekannt und selten verwendet, aber normalerweise per auskommentiertem Token:

    • Einfacher Abstand // ? > Erkennung durch PHPs Tokenizer zu entgehen.

    • Oder ausgefallene Unicode-Substitute // ﹖﹥ (U + FE56 KLEINES FRAGEZEICHEN, U + FE65 KLEINES WINKELHALTER), das ein Regexp erfassen kann.

    Beide haben für PHP keine Bedeutung, können jedoch für externe Toolkits, die PHP nicht oder nur teilweise kennen, praktische Anwendungen haben. Wiederum kommen cat -verbundene Skripte in den Sinn, mit resultierenden // ? > <?php Verkettungen, die die vorherige Dateischnitte inline beibehalten.

Es gibt also kontextabhängige, aber praktische Alternativen zu einer zwingenden Auslassung von engen Tags.

Das manuelle Babysitten von ?> Engen Tags ist in beiden Fällen nicht sehr zeitgemäß. Dafür gab es schon immer Automatisierungstools (auch wenn es sich nur um Sed/Awk- oder Regex-Oneliners handelt). Speziell:

phptags tag tidier

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

Was im Allgemeinen verwendet werden könnte, um --unclose PHP-Tags für Code von Drittanbietern zu erstellen, oder um einfach alle (und alle) tatsächlichen Whitespace-/BOM-Probleme zu beheben:

  • phptags --warn --whitespace *.php

Aus Gründen der Laufzeit-/Konfigurationskompatibilität werden auch --long - Tag-Konvertierungen usw. ausgeführt.

55
mario

Es ist kein Tag ...

Aber wenn Sie es haben, riskieren Sie Leerzeichen danach.

Wenn Sie es dann als Include am Anfang eines Dokuments verwenden, können Sie Leerzeichen (d. H. Inhalte) einfügen, bevor Sie versuchen, HTTP-Header zu senden. Dies ist nicht zulässig.

21
Quentin

Es ist ziemlich nützlich, das Schließen nicht zuzulassen ?> im.

Die Datei bleibt gültig für PHP (kein Syntaxfehler)) und wie @David Dorward sagte, können Leerzeichen/Zeilenumbrüche (alles, was einen Header an den Browser senden kann) danach vermieden werden das ?>.

Zum Beispiel,

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

wird nicht gültig sein.

Aber

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

werden.

Diesmal musst du faul sein, um sicher zu sein.

16
Shikiryu

Laut the docs ist es aus folgendem Grund vorzuziehen, das schließende Tag wegzulassen, wenn es am Ende der Datei steht:

Wenn es sich bei einer Datei um reinen PHP Code handelt, sollte das schließende Tag PHP am Ende der Datei weggelassen werden. Dadurch wird verhindert, dass versehentlich Leerzeichen oder neue Zeilen eingefügt werden Nach dem schließenden Tag PHP, was zu unerwünschten Effekten führen kann, da PHP) die Ausgabepufferung startet, wenn der Programmierer nicht beabsichtigt, eine Ausgabe zu senden Punkt im Skript.

PHP Manual> Sprachreferenz> Grundlegende Syntax> PHP tags

14
Asaph

Nun, es gibt zwei Sichtweisen.

  1. PHP-Code ist nichts anderes als eine Reihe von XML-Verarbeitungsanweisungen , und daher ist jede Datei mit der Erweiterung .php Nichts anderes als eine XML-Datei, die zufällig für PHP Code.
  2. PHP teilt zufällig das XML-Verarbeitungsanweisungsformat für seine Open- und Close-Tags. Auf dieser Grundlage können Dateien mit den Erweiterungen .php Gültige XML-Dateien sein, müssen dies aber nicht.

Wenn Sie der ersten Route glauben, müssen alle PHP - Dateien End-Tags schließen. Wenn Sie sie nicht angeben, wird eine ungültige XML-Datei erstellt. Andererseits haben Sie ohne eine öffnende <?xml version="1.0" charset="latin-1" ?> - Deklaration sowieso keine gültige XML-Datei ... Es ist also kein großes Problem ...

Wenn Sie der zweiten Route glauben, öffnet sich die Tür für zwei Arten von .php - Dateien:

  • Dateien, die nur Code enthalten (z. B. Bibliotheksdateien)
  • Dateien, die natives XML und auch Code enthalten (z. B. Vorlagendateien)

Auf dieser Grundlage können Code-only-Dateien ohne schließendes ?> - Tag beendet werden. Die XML-Codedateien können jedoch nicht ohne ein schließendes ?> Beendet werden, da dies die XML ungültig machen würde.

Aber ich weiß, was du denkst. Sie überlegen, worauf es ankommt, Sie werden niemals eine PHP - Datei direkt rendern. Wen interessiert es also, ob es sich um gültiges XML handelt? Nun, es ist wichtig, ob Sie eine Vorlage entwerfen. Wenn es sich um gültiges XML/HTML handelt, zeigt ein normaler Browser den PHP - Code einfach nicht an (er wird wie ein Kommentar behandelt). So können Sie die Vorlage verspotten, ohne den Code PHP innerhalb von ...

Ich sage nicht, dass das wichtig ist. Es ist nur eine Ansicht, die ich nicht allzu oft sehe. Welchen besseren Ort gibt es also, um sie zu teilen?.

Persönlich schließe ich Tags nicht in Bibliotheksdateien, sondern in Vorlagendateien ... Ich denke, es ist eine persönliche Präferenz (und Codierungsrichtlinie), die mehr als alles andere auf Schwierigkeiten beruht ...

9
ircmaxell

Nun, ich kenne den Grund, aber ich kann es nicht zeigen:

Für Dateien, die nur PHP Code enthalten, wird das schließende Tag (?>) ist niemals erlaubt. Sie wird von PHP nicht benötigt und verhindert, dass versehentlich Leerzeichen in die Antwort eingefügt werden.

Quelle: http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

8
tawfekov

Zusätzlich zu allem, was bereits gesagt wurde, werde ich einen weiteren Grund anführen, der uns das Debuggen sehr schwer machte.

Apache 2.4.6 mit PHP= 5.4 tatsächlich Segmentierungsfehler auf unseren Produktionsmaschinen, wenn hinter dem schließenden Tag php ein leerer Platz ist. Ich habe nur Stunden verschwendet bis Endlich habe ich den Fehler mit strace eingegrenzt.

Hier ist der Fehler, den Apache auslöst:

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

Msgstr "Gibt es einen anderen guten Grund (außer dem Header - Problem), das End - PHP - Tag zu überspringen?"

Sie möchten beim Generieren von Binärausgaben, CSV Daten oder anderen Nicht-HTML-Ausgaben keine ungewollten Leerzeichen ausgeben.

6
user1238364

Vorteile

Nachteile

Fazit

Ich würde sagen, dass die Argumente für das Weglassen des Tags strenger aussehen (vermeidet große Kopfschmerzen mit header () + es ist PHP/Zend "Empfehlung" ). Ich gebe zu, dass dies nicht die "schönste" Lösung ist, die ich je in Bezug auf Syntaxkonsistenz gesehen habe, aber was könnte besser sein?

5
Frosty Z

Da meine Frage als Duplikat dieser Frage markiert wurde, denke ich, dass es sich um O.K. handelt. um zu posten, warum [~ # ~] nicht [~ # ~] das schließende Tag weglässt ?> kann aus bestimmten Gründen gewünscht sein.

  • Mit vollständiger Verarbeitungsanweisung Syntax (<?php ... ?>) PHP source ist ein gültiges SGML-Dokument, das ohne Probleme mit dem SGML-Parser analysiert und verarbeitet werden kann. Mit zusätzlichen Einschränkungen kann es auch gültiges XML/XHTML sein.

Nichts hindert Sie daran, gültigen XML/HTML/SGML-Code zu schreiben. PHP-Dokumentation ist sich dessen bewusst. Auszug:

Hinweis: Beachten Sie auch, dass Sie, wenn Sie PHP in XML oder XHTML einbetten, die Tags <? Php?> Verwenden müssen, um den Standards zu entsprechen.

Natürlich ist PHP die Syntax nicht streng SGML/XML/HTML und Sie erstellen ein Dokument, das nicht SGML/XML/HTML ist, genauso wie Sie HTML in XHTML umwandeln können, um XML-kompatibel zu sein oder nicht .

  • Irgendwann möchten Sie möglicherweise Quellen verketten. Das wird nicht so einfach sein wie cat source1.php source2.php wenn Sie Inkonsistenzen haben, die durch das Weglassen von Closing ?> Stichworte.

  • Ohne ?> Es ist schwerer zu sagen, ob das Dokument im PHP Escape-Modus oder PHP Ignorier-Modus (PI-Tag <?php wurde möglicherweise geöffnet oder nicht). Das Leben ist einfacher, wenn Sie Ihre Dokumente konsequent im PHP ignorieren) -Modus belassen. Es ist genau so, als würden Sie mit gut formatierten HTML-Dokumenten arbeiten, verglichen mit Dokumenten mit nicht geschlossenen, schlecht verschachtelten Tags usw.

  • Es scheint, dass einige Editoren wie Dreamweaver Probleme mit PI haben, wenn sie offen bleiben [1] .

2
doc

Wenn ich die Frage richtig verstehe, hat dies mit der Ausgabepufferung und den Auswirkungen auf das Schließen/Beenden von Tags zu tun. Ich bin mir nicht sicher, ob das eine völlig gültige Frage ist. Das Problem besteht darin, dass der Ausgabepuffer nicht bedeutet, dass der gesamte Inhalt im Speicher gespeichert ist, bevor er an den Client gesendet wird. Es bedeutet, dass ein Teil des Inhalts ist.

Der Programmierer kann absichtlich den Puffer oder den Ausgabepuffer leeren, also ändert die Ausgabepufferoption in PHP wirklich, wie sich das schließende Tag auf die Codierung auswirkt? Ich würde argumentieren, dass dies nicht der Fall ist.

Und vielleicht ist das der Grund, warum die meisten Antworten auf persönlichen Stil und Syntax zurückgingen.

0
Ruz

Es gibt 2 mögliche Verwendung von PHP-Code:

  1. PHP-Code wie Klassendefinition oder Funktionsdefinition
  2. Verwenden Sie PHP als Vorlagensprache (d. H. In Ansichten)

in fall 1. das schließende tag ist völlig unbrauchbar, auch ich möchte in einem solchen fall nur 1 (ein) php open tag und NO (null) schließendes tag sehen. Dies ist eine gute Vorgehensweise, da dadurch der Code sauber und die Logik von der Präsentation getrennt wird. Für Präsentationsfall (2.) haben einige festgestellt, dass es natürlich ist, alle Tags (auch die mit PHP verarbeiteten) zu schließen, was zu Verwirrung führt, da der PHP) tatsächlich 2 separate Anwendungsfälle hat, das sollte nicht gemischt werden: Logik/Kalkül und Präsentation

0