PHP-Parse-/Syntax-Fehler; und wie kann man sie lösen?

Was sind die Syntaxfehler?

PHP gehört zu den C-artigen und imperativen Programmiersprachen. Es hat starre Grammatikregeln, von denen es sich nicht erholen kann, wenn es auf falsch platzierte Symbole oder Bezeichner stößt. Sie kann Ihre Kodierungsabsichten nicht erraten.

Wichtigste Tipps

Es gibt ein paar grundlegende Vorsichtsmaßnahmen, die Sie immer treffen können:

• Verwenden Sie eine korrekte Code-Einrückung, oder nehmen Sie einen erhabenen Kodierungsstil an. Die Lesbarkeit verhindert Unregelmäßigkeiten.
• Verwenden Sie einen IDE oder Editor für PHP mit Syntax-Hervorhebung. Diese helfen auch bei der Klammerung von Klammern. Erwartet: Semikolon
• Lesen Sie die Sprachreferenz und die Beispiele im Handbuch. Zweimal, um einigermaßen geübt zu werden.

  Wie man Parser-Fehler interpretiert

  Eine typische Syntaxfehlermeldung lautet: Parse error: syntax error, unexpected T_STRING, expecting ';' in file.php on line 217 Hier wird der mögliche Ort eines Syntaxfehlers aufgeführt. Siehe den genannten Dateinamen und die Zeilennummer. Ein moniker wie T_STRING erklärt, welches Symbol der Parser/Tokenizer letztendlich nicht verarbeiten konnte. Dies ist jedoch nicht unbedingt die Ursache für den Syntaxfehler. Es ist wichtig, auch die vorherigen Codezeilen zu untersuchen. Oft handelt es sich bei Syntaxfehlern nur um Pannen, die früher passiert sind. Die Fehlerzeilennummer ist nur die Stelle, an der der Parser endgültig aufgegeben hat, das Ganze zu verarbeiten.

  Behebung von Syntaxfehlern

  Es gibt viele Ansätze, um Syntaxfehler einzugrenzen und zu beheben.

• Öffnen Sie die genannte Quelldatei. Schauen Sie sich die erwähnte Codezeile an.
  • Bei ausufernden Zeichenketten und falsch platzierten Operatoren finden Sie hier normalerweise den Übeltäter.
  • Lesen Sie die Zeile von links nach rechts und stellen Sie sich vor, was die einzelnen Symbole bedeuten.
• Regelmäßiger müssen Sie sich auch die vorangehenden Zeilen ansehen.
  • Insbesondere fehlen ; Semikolons an den vorhergehenden Zeilenenden/Anweisungen. (Zumindest aus stilistischer Sicht. )
  • Wenn { Codeblöcke } falsch geschlossen oder verschachtelt sind, müssen Sie vielleicht noch weiter oben im Quellcode nachforschen. Verwenden Sie die richtige Code-Einrückung, um dies zu vereinfachen.
• Achten Sie auf die Syntaxfärbung!
  • Strings, Variablen und Konstanten sollten alle unterschiedliche Farben haben.
  • Die Operatoren +-*/. sollten ebenfalls unterschiedlich eingefärbt sein. Andernfalls könnten sie im falschen Kontext stehen.
  • Wenn Sie sehen, dass die Einfärbung von Zeichenketten zu weit oder zu kurz reicht, dann haben Sie eine nicht abgeschlossene oder fehlende abschließende " oder ' Zeichenkettenmarkierung gefunden.
  • Zwei gleichfarbige Interpunktionszeichen nebeneinander zu haben, kann auch ein Problem bedeuten. Normalerweise sind Operatoren einsam, wenn nicht ++, -- oder Klammern auf einen Operator folgen. Zwei direkt aufeinander folgende Zeichenfolgen/Kennungen sind in den meisten Zusammenhängen nicht korrekt.
• Leerzeichen sind Ihr Freund*. Befolgen Sie jeden* Kodierungsstil. Belästigen wir Neulinge hier aber nicht mit PSR-x, K? -->
• Brechen Sie lange Zeilen vorübergehend auf.
  • Sie können zwischen Operatoren oder Konstanten und Strings beliebig Newlines einfügen. Der Parser wird dann die Zeilennummer für Parsing-Fehler konkretisieren. Anstatt sich den sehr langen Code anzusehen, können Sie das fehlende oder falsch platzierte Syntaxsymbol isolieren.
  • Teilen Sie komplexe "wenn"-Anweisungen in einzelne oder verschachtelte "wenn"-Bedingungen auf.
  • Verwenden Sie anstelle von langen mathematischen Formeln oder logischen Ketten temporäre Variablen, um den Code zu vereinfachen. (Bessere Lesbarkeit = weniger Fehler.)
  • Fügen Sie Zeilenumbrüche zwischen:
    1. Dem Code, den Sie leicht als korrekt identifizieren können,
    2. Die Teile, bei denen Sie unsicher sind,
    3. Und die Zeilen, über die sich der Parser beschwert.
       Das Aufteilen langer Codeblöcke hilft wirklich dabei, den Ursprung von Syntaxfehlern ausfindig zu machen.
• Kommentieren Sie den fehlerhaften Code aus.
  • Wenn Sie die Problemquelle nicht eingrenzen können, beginnen Sie damit, Codeblöcke auszukommentieren (und damit vorübergehend zu entfernen).
  • Sobald Sie den Parsing-Fehler losgeworden sind, haben Sie die Problemquelle gefunden. Schauen Sie dort genauer hin.
  • Manchmal wollen Sie ganze Funktions-/Methodenblöcke vorübergehend entfernen. (Im Falle von nicht übereinstimmenden geschweiften Klammern und falsch eingerücktem Code).
  • Wenn Sie das Syntaxproblem nicht lösen können, versuchen Sie, die auskommentierten Abschnitte von Grund auf neu zu schreiben.
• Als Neuling sollten Sie einige der verwirrenden Syntaxkonstrukte vermeiden.
  • Der ternäre ? : Bedingungsoperator kann den Code verdichten und ist in der Tat nützlich. Aber er trägt nicht in allen Fällen zur Lesbarkeit bei. Bevorzugen Sie einfache `if'-Anweisungen, wenn Sie nicht versiert sind.
  • PHP's alternative Syntax (if:/elseif:/endif;) ist für Vorlagen üblich, aber wohl weniger leicht zu verstehen als normale { Code }-Blöcke.
• Die häufigsten Fehler für Neulinge sind:
  • Fehlende Semikolons ; zur Beendigung von Anweisungen/Zeilen.
  • Nicht übereinstimmende Anführungszeichen für " oder ' und nicht abgeschlossene Anführungszeichen darin.
  • Vergessene Operatoren, insbesondere für die Verkettung der Zeichenkette ..
  • Unausgewogene ( Klammern ). Zählen Sie sie in der gemeldeten Zeile. Gibt es eine gleiche Anzahl von ihnen?
• Vergessen Sie nicht, dass das Lösen eines Syntaxproblems das nächste aufdecken kann.
  • Wenn Sie ein Problem beseitigen, aber ein anderes in einem späteren Code auftaucht, sind Sie meistens auf dem richtigen Weg.
  • Wenn nach der Bearbeitung ein neuer Syntaxfehler in derselben Zeile auftaucht, dann war Ihre versuchte Änderung möglicherweise ein Fehlschlag. (Allerdings nicht immer.)
• Stellen Sie eine Sicherungskopie des zuvor funktionierenden Codes wieder her, wenn Sie den Fehler nicht beheben können.
  • Führen Sie ein Versionsverwaltungssystem für den Quellcode ein. Sie können immer einen "Unterschied" zwischen der fehlerhaften und der letzten funktionierenden Version sehen. Das könnte aufschlussreich sein, was das Syntaxproblem ist.
    
• Unsichtbare Unicode-Zeichen: In einigen Fällen müssen Sie einen Hexeditor oder einen anderen Editor/Viewer für Ihren Quelltext verwenden. Manche Probleme lassen sich nicht einfach durch einen Blick in den Code finden.
  • Versuchen Sie grep --color -P -n "\[\x80-\xFF\]" file.php als erste Maßnahme, um Nicht-ASCII-Zeichen zu finden.
  • Insbesondere BOMs, Leerzeichen mit Null-Breite oder nicht umgebrochene Leerzeichen und intelligente Anführungszeichen können regelmäßig ihren Weg in den Quellcode finden.
• Achten Sie darauf, welche Arten von Zeilenumbrüchen in Dateien gespeichert werden.
  • PHP honoriert nur \n Zeilenumbrüche, nicht \r Wagenrückläufe.
  • Dies ist gelegentlich ein Problem für MacOS-Benutzer (sogar unter OS  X für falsch konfigurierte Editoren).
  • Es tritt oft nur auf, wenn einzeilige // oder # Kommentare verwendet werden. Mehrzeilige /*...*/ Kommentare stören den Parser nur selten, wenn Zeilenumbrüche ignoriert werden.
• Wenn Ihr Syntaxfehler nicht über das Web übertragen wird: Es kann vorkommen, dass Sie auf Ihrem Rechner einen Syntaxfehler haben. Aber wenn Sie dieselbe Datei online stellen, wird er nicht mehr angezeigt. Das kann nur eines von zwei Dingen bedeuten:
  • Sie sehen sich die falsche Datei an!
  • Oder Ihr Code enthält unsichtbaren Unicode (siehe oben). Das können Sie leicht herausfinden: Kopieren Sie einfach Ihren Code aus dem Webformular zurück in Ihren Texteditor.
• Überprüfen Sie Ihre PHP-Version. Nicht alle Syntaxkonstrukte sind auf jedem Server verfügbar.
  • php -v für den Kommandozeileninterpreter
  • <?php phpinfo(); für denjenigen, der über den Webserver aufgerufen wird. Das ist aber nicht unbedingt dasselbe. Insbesondere wenn Sie mit Frameworks arbeiten, müssen sie übereinstimmen.
• Verwenden Sie PHP's reservierte Schlüsselwörter nicht als Bezeichner für Funktionen/Methoden, Klassen oder Konstanten.
• Versuch und Irrtum ist Ihr letzter Ausweg. Wenn alles andere fehlschlägt, können Sie Ihre Fehlermeldung immer noch googeln. Syntax-Symbole sind nicht so leicht zu finden (Stack Overflow selbst wird allerdings von SymbolHound indiziert). Daher kann es sein, dass Sie ein paar mehr Seiten durchsehen müssen, bevor Sie etwas Relevantes finden. Weitere Anleitungen:
• PHP-Debugging-Grundlagen von David Sklar
• Behebung von PHP-Fehlern von Jason McCreary
• PHP-Fehler - 10 häufige Fehler von Mario Lurig
• Häufige PHP-Fehler und Lösungen
• Fehlersuche und -behebung für Ihre WordPress-Website
• A Guide To PHP Error Messages For Designers - Smashing Magazine

  Weißer Bildschirm des Todes

  Wenn Ihre Website einfach nur leer ist, dann liegt das in der Regel an einem Syntaxfehler. Aktivieren Sie deren Anzeige mit:

  • error_reporting = E_ALL
  • Anzeige von Fehlern = 1". In Ihrer php.ini im Allgemeinen, oder über .htaccess für mod_php, oder sogar .user.ini bei FastCGI-Konfigurationen. Das Aktivieren innerhalb des kaputten Skripts ist zu spät, weil PHP nicht einmal die erste Zeile interpretieren/ausführen kann. Ein schneller Workaround ist die Erstellung eines Wrapper-Skripts, z.B. test.php:

<?php
   error_reporting(E_ALL);
   ini_set("display_errors", 1);
   include("./broken-script.php");

Rufen Sie dann den fehlerhaften Code auf, indem Sie auf dieses Wrapper-Skript zugreifen. Es hilft auch, PHP's error_log zu aktivieren und einen Blick in Ihr Webserver's error.log zu werfen, wenn ein Skript mit HTTP 500 Antworten abstürzt.

Unerwartetes T_VARIABLE

Ein "unerwartetes T_VARIABLE" bedeutet, dass es einen wörtlichen $variablen-Namen gibt, der nicht in die aktuelle Ausdrucks-/Anweisungsstruktur passt'.

1. Fehlendes Semikolon

   Meistens handelt es sich um [ein fehlendes Semikolon] (https://stackoverflow.com/questions/9135784/syntax-error-unexpected-t-variable) in der vorherigen Zeile. Variablenzuweisungen im Anschluss an eine Anweisung sind ein guter Indikator dafür, wo zu suchen ist:

           ⇓
    func1()
    $var = 1 + 2; # Parse-Fehler in Zeile +2

2. String-Verkettung

   Ein häufiges Missgeschick sind String-Verkettungen mit vergessenem .-Operator:

                                   ⇓
    print "Hier kommt der Wert: " $wert;

   Übrigens sollten Sie string interpolation (Basisvariablen in Anführungszeichen) bevorzugen, wenn dies der Lesbarkeit dient. Damit lassen sich diese Syntaxprobleme vermeiden.

   Die Interpolation von Zeichenketten ist eine Kernfunktion der Skriptsprache. Es ist keine Schande, sie zu nutzen. Ignorieren Sie alle Ratschläge zur Mikro-Optimierung, dass die Verkettung von Variablen schneller ist. **Das ist es nicht.

3. Fehlende Ausdrucksoperatoren

   Natürlich kann das gleiche Problem auch bei anderen Ausdrücken auftreten, zum Beispiel bei arithmetischen Operationen:

               ⇓
    print 4 + 7 $var;

   PHP kann hier nicht erraten, ob die Variable addiert, subtrahiert oder verglichen werden soll usw.

4. Listen

   Dasselbe gilt für Syntaxlisten, wie z.B. in Array-Populationen, wo der Parser auch ein erwartetes Komma , anzeigt:

                                          ⇓
    $var = array("1" => $val, $val2, $val3 $val4);

   Oder Funktionen Parameterlisten:

                                    ⇓
    Funktion myfunc($param1, $param2 $param3, $param4)

   Ähnlich verhält es sich mit list oder global Anweisungen, oder wenn ein ; Semikolon in einer for Schleife fehlt.

5. Klassendeklarationen

   Dieser Parserfehler tritt auch [in Klassendeklarationen] auf (https://stackoverflow.com/questions/5122729/im-getting-a-syntax-error-unexpected-t-variable-error-i-dont-see-what-im). Sie können nur statische Konstanten zuweisen, keine Ausdrücke. Daher beschwert sich der Parser über Variablen als zugewiesene Daten:

    class xyz { ⇓.
        var $value = $_GET["input"];

   Unpassende } schließende geschweifte Klammern können hier besonders dazu führen. Wenn eine Methode zu früh beendet wird (korrekte Einrückung!), dann wird häufig eine verirrte Variable in den Körper der Klassendeklaration verlagert.

6. Variablen nach Bezeichnern

   Sie können auch niemals eine Variable direkt nach einem Bezeichner einfügen:

                 ⇓
    $this->myFunc$VAR();

   Übrigens ist dies ein häufiges Beispiel, bei dem die Absicht war, vielleicht variable Variablen zu verwenden. In diesem Fall eine variable Eigenschaft Lookup mit $this->{"myFunc$VAR"}(); zum Beispiel.

   Denken Sie daran, dass die Verwendung von variablen Variablen die Ausnahme sein sollte. Neulinge versuchen oft, sie zu beiläufig zu verwenden, selbst wenn Arrays einfacher und angemessener wären.

7. Fehlende Parens nach Sprachkonstrukten

   Hastiges Tippen kann dazu führen, dass öffnende Klammern vergessen werden für if und for und foreach Anweisungen:

           ⇓
    foreach $array as $key) {

   Lösung: Fügen Sie das fehlende öffnende ( zwischen Anweisung und Variable ein.

8. Else erwartet keine Bedingungen

         ⇓
    else ($var >= 0)

   Lösung: Entfernen Sie die Bedingungen aus else oder verwenden Sie elseif.

9. Brauche Klammern für den Abschluss

         ⇓
    function() verwendet $var {}

   Lösung: Fügen Sie Klammern um $var hinzu.

10. Unsichtbarer Whitespace

    Wie in der [Referenzantwort] (https://stackoverflow.com/a/18050072/345031) zu "Unsichtbarer Unicode" (wie z.B. ein [non-breaking space] (https://en.wikipedia.org/wiki/Non-breaking_space)) erwähnt, können Sie diesen Fehler auch bei ahnungslosem Code wie dem folgenden sehen:

     <?php
                               ⇐
     $var = new PDO(...);

    Es ist ziemlich häufig am Anfang von Dateien und bei kopiertem und eingefügtem Code anzutreffen. Prüfen Sie mit einem Hexeditor, ob Ihr Code nicht visuell ein Syntaxproblem zu enthalten scheint.

Siehe auch

• Suche: unerwartetes T_VARIABLE

Unerwarteter T_STRING

T_STRING" ist eine etwas missverständliche Bezeichnung. Er bezieht sich nicht auf eine in Anführungszeichen gesetzte "Zeichenkette". Es bedeutet, dass ein roher Bezeichner angetroffen wurde. Dies kann von "bloßen" Wörtern über übrig gebliebene "CONSTANT"- oder Funktionsnamen bis hin zu vergessenen, nicht in Anführungszeichen gesetzten Strings oder einfachem Text reichen.

1. Falsch zitierte Zeichenketten

   Dieser Syntaxfehler tritt jedoch am häufigsten bei falsch zitierten Zeichenfolgen auf. Jedes nicht abgeschlossene und fehlende `"` oder `'` Anführungszeichen bildet einen ungültigen Ausdruck: ⇓ ⇓ echo "click here"; Die Syntaxhervorhebung macht solche Fehler sehr deutlich. Es ist wichtig, daran zu denken, Backslashes zu verwenden, um doppelte Anführungszeichen oder einfache Anführungszeichen zu vermeiden - je nachdem, was als [String Enclosure][1] verwendet wurde. - Der Einfachheit halber sollten Sie bei der Ausgabe von einfachem HTML mit doppelten Anführungszeichen die äußeren einfachen Anführungszeichen bevorzugen. - Verwenden Sie Strings mit doppelten Anführungszeichen, wenn Sie Variablen interpolieren wollen, aber achten Sie dann auf das Escaping von literalen `"` doppelten Anführungszeichen. - Für längere Ausgaben bevorzugen Sie mehrere "echo"/"print"-Zeilen, anstatt "in and out" zu escapen. Noch besser ist es, einen [HEREDOC][2]-Abschnitt zu verwenden. Siehe auch *https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php*.

2. Ungeschlossene Zeichenketten

   Wenn Sie [ein abschließendes `"`][3] vermissen, tritt normalerweise später ein Syntaxfehler auf. Eine nicht abgeschlossene Zeichenkette verbraucht oft ein bisschen Code bis zum nächsten beabsichtigten Zeichenfolgenwert: ⇓ echo "Some text", $a_variable, "and some runaway string ; Erfolg("fertig"); ⇯ Es sind nicht nur wörtliche `T_STRING`s, gegen die der Parser dann protestieren kann. Eine weitere häufige Variante ist ein [Unerwartetes '>'`](https://stackoverflow.com/questions/6507796/troubleshooting-parse-error-unexpected-error) für unquotiertes literales HTML.

3. Nicht programmierte String-Anführungszeichen

   Wenn Sie Code von einem Blog oder einer Website *kopieren und einfügen*, erhalten Sie manchmal ungültigen Code. [Typografische Anführungszeichen sind nicht das, was PHP erwartet[4]: $text = 'Irgendwas irgendwas...' + "das sind keine Anführungszeichen"; Typografische/kluge Anführungszeichen sind Unicode-Symbole. PHP behandelt sie als Teil des angrenzenden alphanumerischen Textes. Zum Beispiel wird `"these` als konstanter Bezeichner interpretiert. Aber jedes nachfolgende Textliteral wird dann vom Parser als ein Bareword/T_STRING angesehen.

4. Das fehlende Semikolon; wieder

   Wenn Sie einen unterminierten Ausdruck in den vorherigen Zeilen haben, wird jede folgende Anweisung oder Sprachkonstruktion als roher Bezeichner angesehen: ⇓ func1() function2(); PHP kann einfach nicht wissen, ob Sie zwei Funktionen nacheinander ausführen wollen, oder ob Sie deren Ergebnisse multiplizieren, addieren, vergleichen oder nur die eine oder die andere Funktion ausführen wollen.

5. Kurze offene Tags und <?xml Kopfzeilen in PHP-Skripten

   Dies ist eher unüblich. Aber wenn short_open_tags aktiviert ist, können Sie Ihre PHP-Skripte nicht [mit einer XML-Deklaration][5] beginnen: ⇓ <?xml version="1.0"?> PHP wird das `<?` erkennen und für sich beanspruchen. Es wird nicht verstehen, wofür das fehlende `xml` gedacht war. Es wird als Konstante interpretiert. Aber die `version` wird als ein weiteres Literal/Konstante angesehen. Und da der Parser keinen Sinn aus zwei aufeinanderfolgenden Literalen/Werten ohne einen Ausdrucksoperator dazwischen machen kann, ist das ein Parserfehler.

6. Unsichtbare Unicode-Zeichen

   Eine besonders hässliche Ursache für Syntaxfehler sind Unicode-Zeichen, wie z. B. das [non-breaking space][6]. PHP erlaubt Unicode-Zeichen als Bezeichnernamen. Wenn Sie eine T_STRING-Parser-Beschwerde für völlig unverdächtigen Code wie: <?php erhalten, drucken Sie 123; müssen Sie einen anderen Texteditor hervorholen. Oder sogar einen Hexeditor. Was hier wie einfache Leerzeichen und Zeilenumbrüche aussieht, kann unsichtbare Konstanten enthalten. Java-basierte IDEs bemerken manchmal nicht, dass ein UTF-8 BOM in den Text eingearbeitet ist, Leerzeichen mit Null-Breite, Absatztrenner, usw. Versuchen Sie, alles neu zu bearbeiten, Leerzeichen zu entfernen und normale Leerzeichen wieder einzufügen. Sie können das Problem eingrenzen, indem Sie überflüssige `;`-Anweisungstrennzeichen an jedem Zeilenanfang hinzufügen: <?php ;print 123; Das zusätzliche `;` Semikolon wandelt das vorangehende unsichtbare Zeichen in einen undefinierten konstanten Verweis um (Ausdruck als Anweisung). Das wiederum bringt PHP dazu, einen hilfreichen Hinweis zu produzieren.

7. Das fehlende `$` Zeichen vor Variablennamen

   [Variablen in PHP][7] werden durch ein Dollarzeichen gefolgt vom Variablennamen dargestellt. Das Dollarzeichen (`$`) ist ein [Siegel][8], das den Bezeichner als Namen einer Variablen kennzeichnet. Ohne dieses Zeichen könnte der Bezeichner ein [Sprachschlüsselwort][9] oder eine [Konstante][10] sein. Dieser Fehler tritt häufig auf, wenn der PHP-Code aus einer anderen Sprache ["übersetzt" wurde][11] (C, Java, JavaScript, etc.). In solchen Fällen kann sich auch eine Deklaration des Variablentyps (wenn der ursprüngliche Code in einer Sprache geschrieben wurde, die typisierte Variablen verwendet) herausschleichen und diesen Fehler verursachen.

8. Entgangene Anführungszeichen

   Wenn Sie `\` in einer Zeichenkette verwenden, hat dies eine besondere Bedeutung. Dies wird als "[Escape-Zeichen][12]" bezeichnet und weist den Parser normalerweise an, das nächste Zeichen wörtlich zu nehmen. Beispiel: "echo 'Jim sagte \'Hallo\'';` gibt `Jim sagte 'hallo'` aus. Wenn Sie das schließende Anführungszeichen einer Zeichenkette escapen, wird das schließende Anführungszeichen wörtlich genommen und nicht wie beabsichtigt, d.h. als druckbares Anführungszeichen als Teil der Zeichenkette und nicht als Abschluss der Zeichenkette. Dies wird als Parse-Fehler nach dem Öffnen des nächsten Strings oder am Ende des Skripts angezeigt. Ein sehr häufiger Fehler bei der Angabe von Pfaden in Windows: "C:xampp" ist falsch. Sie brauchen `"C:\xampp\htdocs\"`.