Warum sollte man das Close-Tag weglassen?

374

Ich lese weiter, es ist eine schlechte Praxis, das PHP-Close-Tag ?>am Ende der Datei zu verwenden. Das Header-Problem scheint im folgenden Kontext irrelevant zu sein (und dies ist das einzig gute Argument bisher):

Moderne Versionen von PHP setzen das Flag output_buffering in 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, das endende PHP-Tag zu überspringen?

Danidacar
quelle
3
Mögliches Duplikat von [warum lassen sie in einigen Skripten das schließende PHP-Tag weg ?>] ( stackoverflow.com/questions/3219383/… )
Gordon
@Christian - Du meinst, dass die Verwendung von output_buffering faul ist oder das Weglassen von faul ?>ist?
El Yobo
4
@ Gordon - Ich glaube nicht, dass es ein Dup ist, das OP kennt die angeblichen Gründe, will nur wissen, ob es mit der Ausgabepufferung vollständig gelöst ist.
El Yobo
5
Eine bessere Frage wäre: Warum sollte man das close-Tag einfügen? Code ist böse. Der beste Code ist überhaupt kein Code. Wenn ein Problem behoben werden kann, anstatt es mit Code zu lösen, ist dies besser als Code. In diesem Fall muss kein Problem gelöst werden. Der Code funktioniert ohne das close-Tag einwandfrei.
still_dreaming_1
19
Oh Gott, dies ist nicht der Ort für die Tabs gegen Räume Holy War, lol :)
Kevin Wheeler

Antworten:

322

Das Senden 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 , weitaus wichtiger als alle Entwicklungs- oder Testmaschinen. Und sie tendieren nicht immer dazu, den neuesten PHP-Trends sofort zu folgen.

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

  3. In Internet Explorer werden möglicherweise Fehler vom Typ "Seitenladen abgebrochen" angezeigt, selbst in den neuesten Versionen. Dies liegt daran, dass eine AJAX- Antwort / ein JSON-Include etwas enthält, das sie nicht enthalten sollte, da in einigen PHP-Dateien überschüssige Zeilenenden vorhanden sind, wie ich es vor einigen Tagen erlebt habe.

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

  5. Schließlich erfordern viele PHP-Frameworks, einschließlich Symfony , Zend und Laravel (dies wird in den Codierungsrichtlinien nicht erwähnt , folgt jedoch der Klage) und der PSR-2-Standard (Punkt 2.2) das Weglassen des schließenden Tags. PHP-Handbuch selbst ( 1 , 2 ), Wordpress , Drupal und viele andere PHP-Software, denke ich, raten dazu. Wenn Sie es sich einfach zur Gewohnheit machen, dem Standard zu folgen (und PHP-CS-Fixer für Ihren Code einzurichten ), können Sie das Problem vergessen. Andernfalls müssen Sie das Problem immer im Kopf behalten.

Bonus: ein paar Fallstricke (derzeit einer), die sich auf diese 2 Charaktere beziehen:

  1. Sogar einige bekannte Bibliotheken können nachher überschüssige Zeilenenden enthalten ?>. Ein Beispiel ist Smarty, selbst die neuesten Versionen von 2. * und 3. * haben dies. Achten Sie also wie immer auf Code von Drittanbietern . Bonus in Bonus: Ein regulärer Ausdruck zum Löschen unnötiger PHP-Endungen: Ersetzen Sie (\s*\?>\s*)$alle Dateien, die PHP-Code enthalten , durch leeren Text.
Halil Özgür
quelle
Etwas anderer Regex Ich habe die Tags mit der Netbeans-IDE für das Dialogfeld "Suchen und Ersetzen" gefunden: \?>(?s:.){0,10}\Z Kurze Erklärung: changeset.hr/blog/miscellaneous/catch-near-eof-with-regex
frnhr
@Cek, es fängt jeden Text -Inklusive Code- , die 10 Zeichen oder weniger nach ?>: zB es passt -und würde Lösch- ?> Helloin <?php echo "test"; ?> Hello. Wir möchten nur geschlossene Tags löschen.
Halil Özgür
6
Schlimmer noch, Apache 2.4.6 mit PHP 5.4 trennt tatsächlich Fehler auf unseren Produktionsmaschinen, wenn sich hinter dem schließenden Tag ein leerer Raum befindet. Ich habe nur Stunden verschwendet, bis ich den Fehler endlich mit Mühe eingegrenzt habe. Hier ist der Fehler, den Apache auslöst : [core:notice] [pid 7842] AH00052: child pid 10218 exit signal Segmentation fault (11).
Artem Russakovskii
3
@INTPnerd Oh, die Frage und die meisten Antworten beziehen sich auf die Header-Sache, also nahm ich an, dass jeder, der diesen Thread liest, eine Idee dazu haben würde. Das zugrunde liegende Problem und die eigentliche Ursache der Probleme in vielen der Antworten hier sind nicht benötigte Leerzeichen danach ?>, wodurch (wie bei jeder Ausgabe) die Header gesendet werden, sobald sie ausgegeben werden. Es gibt keine "HTML-Header" (außer dem nicht verwandten HTML5- <header>Tag).
Halil Özgür
2
Dies sollte unabhängig vom globalen Modifikator funktionieren: \ s * \?> \ S * \ Z Beachten Sie das '\ Z' am Ende. Es stellt sicher, dass Sie ein PHP-Closing-Tag genau dann erfassen, wenn es das letzte Nicht-Leerzeichen ganz am Ende der Datei ist.
Erutan409
122

Der Grund, warum Sie das PHP-Closing-Tag ( ?>) weglassen sollten, ist, dass der Programmierer nicht versehentlich zusätzliche Zeilenumbrüche sendet.

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

Also für deine Frage:

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

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

Ich werde mit einigen Argumenten abschließen, um mich nicht mit dem schließenden Tag zu beschäftigen:

  1. Menschen können immer Fehler machen, egal wie klug sie sind. Es ist eine gute Idee, sich an eine Praxis zu halten, die die Anzahl möglicher Fehler verringert (IMHO).

  2. PHP ist kein XML. PHP muss sich nicht an strenge 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. Dies ist auf die eine oder andere Weise keine festgelegte Regel.

zzzzBov
quelle
2
> Jeder Programmierer mit einem halben Verstand kann sich daran erinnern, keinen zusätzlichen Leerraum hinzuzufügen. Noch besser ist, dass jeder Entwickler mit einem halben Verstand SVC einen Pre-Commit-Hook hinzufügen kann, sodass alle nachgestellten Leerzeichen automatisch gelöscht werden: kein Aufwand, kein Muss.
BryanH
6
@BryanH, bis Sie eine Datei haben, in der nachgestellte Leerzeichen unbedingt erforderlich sind, aber das ist sehr selten.
zzzzBov
1
Du hast natürlich recht. Schauen Sie sich Marios Antwort für einige sehr coole Alternativen an.
BryanH
> "Der Grund, warum Sie das PHP-Closing-Tag nicht weglassen sollten, ist, dass es ein Ungleichgewicht in den PHP-Tags verursacht und jeder Programmierer mit einem halben Verstand daran denken kann, keinen zusätzlichen Leerraum hinzuzufügen." Unter Windows vielleicht. Auf UNIX-ähnlichen Systemen enden alle Dateien mit \ n, und Programme fügen sie für Sie hinzu. EDIT: Aha! Wie unten von @mario erwähnt, isst PHP das tatsächlich.
Andrea
2
Noch wichtiger ist, dass selbst Programmierer mit einem doppelten oder dreifachen Verstand menschlich sind und Dinge vergessen.
Sebastian Mach
57

Es handelt sich um eine Empfehlung für einen neuen Codierungsstil , die gut gemeint ist und im Handbuch empfohlen wird .

  • Eschewing ?>löst jedoch nur ein Rinnsal der häufig gesendeten Ursachen ( Rohausgabe , Stückliste , Mitteilungen usw.) und ihrer Folgeprobleme.

  • PHP enthält tatsächlich etwas Magie, um einzelne Zeilenumbrüche nach dem ?>schließenden Token zu verschlingen. Dies hat jedoch historische Probleme und lässt Neulinge immer noch anfällig für schuppige Redakteure und ungewolltes Mischen in anderen Leerzeichen ?>.

  • Stilistisch bevorzugen einige Entwickler das Anzeigen <?phpund ?>als SGML-Tags / XML-Verarbeitungsanweisungen, was die Konsistenz des Gleichgewichts eines nachgestellten Close-Tokens impliziert. (Was übrigens für abhängigkeitsverbindende Klassen nützlich ist , um ineffizientes automatisches Laden von Datei zu Datei zu ersetzen.)

  • Etwas ungewöhnlich ist, dass die Öffnung <?phpals PHPs Shebang charakterisiert ist (und per binfmt_misc vollständig durchführbar ist ), wodurch die Redundanz eines entsprechenden Close-Tags validiert wird.

  • Es gibt eine offensichtliche Diskrepanz zwischen den vorgeschriebenen klassischen PHP- Syntaxhandbüchern ?>\nund den neueren (PSR-2), die sich auf das Auslassen einigen.
    (Fürs Protokoll: Zend Framework, das übereinander postuliert, impliziert nicht seine inhärente Überlegenheit. Es ist ein Missverständnis, dass Experten von unhandlichen APIs angesprochen wurden.

  • SCMs und moderne IDEs bieten integrierte Lösungen, die vor allem die Pflege von Tags erleichtern.

Wenn Sie von der Verwendung des ?>Close-Tags abraten, verzögert sich lediglich die Erläuterung des grundlegenden PHP-Verarbeitungsverhaltens und der Sprachsemantik, um seltene Probleme zu vermeiden. Es ist immer noch praktisch für die kollaborative Softwareentwicklung, da die Teilnehmer unterschiedliche Kenntnisse haben.

Tag-Variationen schließen

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

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

    ?>\n (Unix Linefeed)

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

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

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

    Frühe PHP-Versionen hatten IIRC-Compile-Ins, die die Plattform-Agnostik etwas einschränkten (FI wurde sogar nur >als Close-Marker verwendet), was der wahrscheinliche historische Ursprung der Close-Tag-Vermeidung ist.

  • Oft übersehen, aber bis PHP7 sie entfernt , kann das reguläre <?phpÖffnungs-Token gültig mit dem selten </script>als ungerade schließende Token gepaart werden .

  • Das " Hard Close Tag " ist nicht einmal eines - hat diesen Begriff nur für eine Analogie erfunden. Konzeptionell und in Bezug auf die Verwendung __halt_compilersollte jedoch als nahes Zeichen erkannt werden.

    __HALT_COMPILER();
    ?>

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

  • Ebenso wird eine Leerereturn; in Include-Skripten selten ersetzt, wodurch alle ?>mit nachgestellten Leerzeichen nicht mehr wirksam werden.

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

    • Einfacher Abstand // ? >, um der Erkennung durch den PHPs-Tokenizer zu entgehen.

    • Oder ausgefallene Unicode-Ersatzprodukte // ﹖﹥(U + FE56 SMALL QUESTION MARK, U + FE65 SMALL ANGLE BRACKET), die ein regulärer Ausdruck erfassen kann.

    Beide bedeuten für PHP nichts , können jedoch praktische Verwendung für PHP-unbewusste oder semi-bewusste externe Toolkits haben. Wieder catkommen zusammengefügte Skripte in den Sinn, mit resultierenden // ? > <?phpVerkettungen, die den früheren Dateibereich 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). Bestimmtes:

phptags tag tidier

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

Dies kann im Allgemeinen verwendet werden, um --uncloseTags für Code von Drittanbietern zu php oder vielmehr alle (und alle) tatsächlichen Whitespace- / Stücklistenprobleme zu beheben:

  • phptags --warn --whitespace *.php

Es übernimmt auch die --longTag-Konvertierung usw. aus Gründen der Laufzeit- / Konfigurationskompatibilität.

Mario
quelle
7
Ja, stumpfe UND provokative Phrasen ziehen negative Stimmen an. Nach dem, was ich im Laufe der Zeit gelesen habe, hat das Weglassen des schließenden Tokens absolut keine Nachteile, solange Sie nicht mit Software arbeiten, die damit nicht umgehen kann. Sofern Sie nicht tatsächlich beweisen können, dass das Weglassen von Schließzeichen schlecht und eine sehr unkomplizierte Sache ist, bleibt meine Gegenstimme;)
jpeltoniemi
2
@Pichan: Ich werde es zulassen. Aber ich nehme an, Sie haben nicht ganz verstanden, was hier erzählt wird. Vermeiden und Vermeiden sind zwei verschiedene Dinge. Und Probleme, die zur Hälfte gelöst sind, sind das Ergebnis der Beratung zu Schlangenöl.
Mario
6
@ Mario: Es ist eine Empfehlung für Neulinge im Codierungsstil . Ich stimme dir nicht zu. Das gesamte Zend Framework lässt enge Tags aus. Ich denke, das ist eine sehr persönliche Entscheidung, ich ziehe es wirklich vor, mein <? Php offen zu lassen und ich fühle mich nicht als Neuling :)
Daniele Vrut
1
Was ist mit HTML? Wird es dann gebraucht? Zum Beispiel <?php if($var): ?>Hello World<?php endif; ?>??? Ich bin wirklich neugierig, da es nicht ausdrücklich erwähnt wird.
WASasquatch
1
@WASasquatch Ja. Wenn Sie zwischen HTML- und PHP-Modus wechseln, benötigen Sie auf jeden Fall nahe Token. (Nicht wirklich relevant für die ursprüngliche Frage hier.)
Mario
22

Es ist kein Tag ...

Aber wenn Sie es haben, riskieren Sie Leerzeichen danach.

Wenn Sie es dann als Include oben in einem Dokument verwenden, können Sie Leerzeichen (dh Inhalte) einfügen, bevor Sie versuchen, HTTP-Header zu senden. Dies ist nicht zulässig.

QUentin
quelle
10
Wenn es kein Tag ist, was ist es dann?
Danidacar
Können Sie bitte ein Beispiel nennen? Vielleicht ist meine PHP-Konfiguration verrückt, aber ich kann das Problem nicht reproduzieren.
Danidacar
2
file1.php: <?php $i = 1; ?> dann file2.php:<?php include 'file1.php'; header('Location: http://www.google.com');?>
Quentin
1
Die Ausgabepufferung hat auch Nachteile. Es verwendet mehr Speicher auf dem Server (da die gesamte Ausgabe bis zur Ausgabe im RAM gespeichert werden muss; ohne Pufferung geht sie sofort los). Es ist auch etwas langsamer. Beides wird in den meisten Fällen kein Problem sein, aber ich bin trotzdem faul. Warum also nicht einfach das abschließende Tag weglassen? Ich verwende, phpcsum sicherzustellen, dass das schließende Tag von jeder meiner Dateien übrig bleibt, und mache mir dann keine Sorgen um die Ausgabepufferung :)
El Yobo
1
@danip: Wenn Sie das Flag output_buffer in der PHP-Konfigurationsdatei gesetzt haben, konnten Sie dieses Problem nicht reproduzieren.
Jichao
16

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

Die Datei bleibt für PHP gültig (kein Syntaxfehler) und wie @David Dorward sagte, kann nach dem ?>.

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.

Ausnahmsweise müssen Sie faul sein, um sicher zu sein .

Shikiryu
quelle
3
Deshalb habe ich sicher in Kursivschrift gesetzt. Es verhindert Fehler, die Sie viel Zeit für einen unerwünschten Speicherplatz nach dem ?>. sicher ist hier vielleicht nicht das gute Wort. Wie auch immer, es behebt nichts (es ist kein schlechter Code für mich, um Dinge zu verhindern, und echohier wäre ein schlechter Code gewesen), aber / und es ist immer noch gültig. Beweise mir das falsch.
Shikiryu
Ich habe dich übrigens nicht abgelehnt. Aber mein Punkt ist mit Ihrem vereinbar. Es repariert nichts. Ich habe nie gesagt, dass es nicht gültig ist, also muss ich nichts beweisen.
Christian
1
Chouchenos, ich wette, Sie meinten eher sicher als sicher. IMHO ein Negativ dafür war zu viel. Brachte dich zurück auf den ersten Platz. ;-) Du hast doch nicht das Falsche gesagt. Sogar PHP-Entwicklungsrichtlinien ermutigen Sie dazu. Es ist in der Tat viel besser, sich auf das Schließen von Tags zu verlassen, als beispielsweise die Ausgabepufferung. Letzteres wäre so, als würde display_errors deaktiviert. Reines Betrügen. Und eine gute Chance, dass Ihre App nicht portabel ist. Ich denke wirklich, dass es in der Regel besser ist, sich überhaupt nicht auf die Ausgabepufferung zu verlassen.
Maraspin
1
Ich möchte keine Leute befragen, die gerne ?>am Ende einer PHP-Datei stehen. Aber mussten Sie jemals einen Fehler beheben, der durch nachgestellte Leerzeichen verursacht wurde? Außerdem sind nicht alle Server auf die gleiche Weise konfiguriert, insbesondere wenn Sie auf einen anderen Host wechseln. Das Erkennen von Fehlern ist sehr zeitaufwändig. Wenn Sie setzen möchten, ?>tun Sie es einfach, wenn Sie auch etwas nachgestellten Speicherplatz hinzufügen und Ihr Team debuggen muss, um Git die Schuld zu geben ^^
CoffeDeveloper
16

Laut den Dokumenten ist es aus folgendem Grund vorzuziehen, das schließende Tag wegzulassen, wenn es sich am Ende der Datei befindet:

Wenn es sich bei einer Datei um reinen PHP-Code handelt, sollte das PHP-Abschluss-Tag am Ende der Datei weggelassen werden. Dies verhindert, dass nach dem Schließen des PHP-Tags versehentlich Leerzeichen oder neue Zeilen hinzugefügt werden. Dies kann zu unerwünschten Effekten führen, da PHP mit der Ausgabepufferung beginnt, wenn der Programmierer nicht beabsichtigt, an diesem Punkt im Skript eine Ausgabe zu senden.

PHP-Handbuch> Sprachreferenz> Grundlegende Syntax> PHP-Tags

Asaph
quelle
10

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

Für Dateien, die nur PHP-Code enthalten, ist das schließende Tag ( ?>) niemals zulässig. Es wird von PHP nicht benötigt, und das Weglassen verhindert das versehentliche Einfügen von nachgestellten Leerzeichen in die Antwort.

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

Tawfekov
quelle
23
Dieses Tag, das "nie erlaubt" ist, ist wahrscheinlich ein Zend-Codierungsstandard, aber keine Syntaxregel für die Formatierung von PHP-Dateien.
Matt Huggins
9

Nun, es gibt zwei Sichtweisen.

  1. PHP-Code ist nichts anderes als eine Reihe von XML-Verarbeitungsanweisungen , und daher ist jede Datei mit einer .phpErweiterung nichts anderes als eine XML-Datei, die zufällig für PHP-Code analysiert wird.
  2. PHP teilt zufällig das XML-Verarbeitungsanweisungsformat für seine offenen und geschlossenen Tags. Basierend darauf können Dateien mit .phpErweiterungen gültige XML-Dateien sein, müssen es aber nicht sein.

Wenn Sie der ersten Route glauben, müssen für alle PHP-Dateien End-Tags geschlossen werden. Wenn Sie sie weglassen, wird eine ungültige XML-Datei erstellt. Andererseits haben Sie ohne eine Eröffnungserklärung <?xml version="1.0" charset="latin-1" ?>sowieso keine gültige XML-Datei ... Es ist also kein großes Problem ...

Wenn Sie der zweiten Route glauben, öffnet dies die Tür für zwei Arten von .phpDateien:

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

Auf dieser Grundlage können Nur-Code-Dateien ohne ein schließendes ?>Tag beendet werden. Es ist jedoch nicht in Ordnung, die XML-Codedateien ohne Schließen zu beenden, ?>da dies das XML ungültig machen würde.

Aber ich weiß was du denkst. Sie denken, 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 PHP-Code in ...

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 keine Tags in Bibliotheksdateien, sondern in Vorlagendateien ... Ich denke, es ist eine persönliche Präferenz (und Codierungsrichtlinie), die mehr als alles andere schwierig ist ...

ircmaxell
quelle
1
Das ist völlig falsch. PHP übersetzt diese Tags NICHT in XML und daher wird kein Ungleichgewicht erzeugt.
Drachenkatze
7
@Felicitus: Ich denke, Sie haben den Teil verpasst, der besagt: "Ich sage nicht, dass dies wichtig ist. Es ist nur eine Ansicht, die ich nicht zu oft zum Ausdruck bringe. Welchen besseren Ort gibt es also, um sie zu teilen ..." Es geht nicht um PHP Tags in XML übersetzen. Es geht darum, was passiert, wenn eine Datei in einem XML-Kontext interpretiert wird (wie HTML oder Editoren usw.) ... Aber Punkt verfehlt ...
ircmaxell
7

Zusätzlich zu allem, was bereits gesagt wurde, werde ich einen weiteren Grund einbringen, der für uns ein großes Problem beim Debuggen war.

Apache 2.4.6 mit PHP 5.4 segmentiert tatsächlich Segmentierungsfehler auf unseren Produktionsmaschinen, wenn hinter dem schließenden phpTag leerer Platz ist . Ich habe nur Stunden verschwendet, bis ich den Fehler endlich mit Mühe eingegrenzt habe .

Hier ist der Fehler, den Apache auslöst:

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

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

Sie möchten nicht versehentlich überflüssige Leerzeichen ausgeben, wenn Sie Binärausgaben, CSV- Daten oder andere Nicht-HTML-Ausgaben generieren .

user1238364
quelle
1
Ich habe einen Kunden beschweren lassen, weil sein XML-Parser unsere Ausgabe abgelehnt hat, als er am Anfang eine zusätzliche Leerzeile hatte. Schlimmer noch, es passierte nur auf einem von sieben Servern mit einer zusätzlichen Zeile nach dem schließenden Tag in einer nicht überarbeiteten Konfigurationsdatei.
Eswald
5

Vorteile

Nachteile

Fazit

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

Frosty Z.
quelle
2

Da meine Frage als Duplikat dieser Frage markiert wurde, denke ich, dass es in Ordnung ist, zu posten, warum es aus bestimmten Gründen erwünscht sein kann, das schließende Tag NICHT wegzulassen ?>.

  • Mit vollständigen Verarbeitungsanweisungen Syntax ( <?php ... ?>) PHP-Quelle 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. Die PHP-Dokumentation ist sich dessen bewusst. Auszug:

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

Natürlich ist die PHP-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. Dies ist nicht so einfach wie das einfache Ausführen von cat source1.php source2.phpInkonsistenzen, die durch das Weglassen schließender ?>Tags verursacht werden.

  • Ohne dass ?>es schwieriger ist zu sagen, ob das Dokument im PHP-Escape-Modus oder im PHP-Ignoriermodus belassen wurde (PI-Tag wurde <?phpmöglicherweise geöffnet oder nicht). Das Leben ist einfacher, wenn Sie Ihre Dokumente konsequent im PHP-Ignoriermodus belassen. Es ist wie bei gut formatierten HTML-Dokumenten im Vergleich zu Dokumenten mit nicht geschlossenen, schlecht verschachtelten Tags usw.

  • Es scheint, dass einige Editoren wie Dreamweaver Probleme mit offen gelassenem PI haben könnten [1] .

doc
quelle
0

Wenn ich die Frage richtig verstehe, hat dies mit der Ausgabepufferung und den möglichen Auswirkungen auf das Schließen / Beenden von Tags zu tun. Ich bin mir nicht sicher, ob dies eine völlig gültige Frage ist. Das Problem ist, 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 den Puffer oder den Ausgabepuffer absichtlich leeren. Ändert die Ausgabepufferoption in PHP also wirklich, wie sich das schließende Tag auf die Codierung auswirkt? Ich würde argumentieren, dass dies nicht der Fall ist.

Und vielleicht gingen die meisten Antworten deshalb auf den persönlichen Stil und die Syntax zurück.

Ruz
quelle
0

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

  1. PHP-Code wie Klassendefinition oder Funktionsdefinition
  2. Verwenden Sie PHP als Vorlagensprache (dh in Ansichten)

in Fall 1. ist das schließende Tag völlig unbenutzbar, außerdem würde ich in einem solchen Fall gerne nur 1 (ein) offenes PHP-Tag und kein schließendes Tag (Null) sehen. Dies ist eine gute Vorgehensweise, da dadurch der Code sauber und die Logik von der Präsentation getrennt wird. Für den Präsentationsfall (2.) haben einige festgestellt, dass es natürlich ist, alle Tags (auch die von PHP verarbeiteten) zu schließen, was zu Verwirrung führt, da das PHP tatsächlich zwei separate Anwendungsfälle hat, die nicht gemischt werden sollten: Logik / Kalkül und Präsentation

Daniele Cruciani
quelle