PHP parse/syntax fouten; en hoe ze op te lossen?

Wat zijn de syntaxis fouten?

PHP behoort tot de C-stijl en imperatieve programmeertalen. Het heeft starre grammaticaregels, waarvan het zich niet kan herstellen als het op misplaatste symbolen of identificatoren stuit. Het kan je coderingsintenties niet raden. Functiedefinitie syntaxis abstract]3

Belangrijkste tips

Er zijn een paar basis voorzorgsmaatregelen die je altijd kunt nemen:

• Gebruik de juiste code-inspringing, of hanteer een verheven coderingsstijl. Leesbaarheid voorkomt onregelmatigheden.

• Gebruik een IDE of editor voor PHP met syntax highlighting. Die ook helpen bij het uitbalanceren van haakjes/tussen haakjes.

• Lees de taalreferentie en voorbeelden in de handleiding. Twee keer, om enigszins bedreven te raken.

  Hoe parser fouten te interpreteren

  Een typische syntaxfoutmelding luidt:

  Parse error: syntax error, unexpected T_STRING, expecting ';' in file.php on line 217 Die de mogelijke locatie van een syntaxfout aangeeft. Zie de genoemde bestandsnaam en regelnummer. Een moniker zoals T_STRING legt uit welk symbool de parser/tokenizer uiteindelijk'niet kon verwerken. Dit is'echter niet noodzakelijkerwijs de oorzaak van de syntaxisfout. Het'is belangrijk om ook naar vorige coderegels te kijken. Vaak zijn syntaxfouten gewoon ongelukjes die eerder zijn gebeurd. Het foutregelnummer is gewoon waar de parser het definitief opgaf om het allemaal te verwerken.

  Syntax fouten oplossen

  Er zijn vele manieren om syntax fouten op te sporen en op te lossen.

• Open het genoemde bronbestand. Kijk naar de genoemde code regel.

  • Voor op hol geslagen strings en misplaatste operatoren, dit is meestal waar je de boosdoener vindt.
  • Lees de regel van links naar rechts en bedenk wat elk symbool doet.

• Regelmatiger is het om ook naar voorgaande regels te kijken.

  • Met name ontbrekende ; puntkomma's bij de voorgaande regeleinden/statements. (Althans vanuit stilistisch oogpunt. )
  • Als { codeblokken } verkeerd gesloten of genest zijn, moet u misschien nog verder in de broncode zoeken. Gebruik de juiste code-inspringing om dat te vereenvoudigen.

• Kijk naar de syntax kleurstelling!

  • Strings, variabelen en constanten moeten allemaal verschillende kleuren hebben.
  • Operatoren +-*/. moeten ook verschillend gekleurd zijn. Anders zouden ze in de verkeerde context kunnen staan.
  • Als je string-kleuring te ver of te kort doorloopt, dan heb je een " of ' string marker gevonden die niet is ge-escaped of ontbreekt.
  • Twee leestekens met dezelfde kleur naast elkaar kunnen ook problemen geven. Gewoonlijk zijn operatoren eenzaam als er geen ++, --, of haakjes na een operator staan. Twee strings/identifiers direct na elkaar zijn onjuist in de meeste contexten.

• Whitespace is your friend. Volg elke coderingsstijl.

• Breek lange lijnen tijdelijk op.

  • U kunt vrijelijk newlines toevoegen tussen operatoren of constanten en strings. De parser zal dan het regelnummer concretiseren voor parseerfouten. In plaats van te kijken naar de zeer lange code, kunt u het ontbrekende of misplaatste syntaxis-symbool isoleren.
  • Splits complexe if statements op in afzonderlijke of geneste if condities.
  • In plaats van lange wiskundige formules of logische ketens, gebruik tijdelijke variabelen om de code te vereenvoudigen. (Leesbaarder = minder fouten.)
  • Voeg nieuwe regels toe tussen:
    1. De code die u gemakkelijk als correct kunt identificeren,
    2. De delen waar je onzeker over bent,
    3. En de regels waar de parser over klaagt.
       Het opdelen van lange codeblokken helpt echt om de oorsprong van syntaxfouten te lokaliseren.

• Commentarieer overtredende code.

  • Als je de bron van het probleem niet kunt isoleren, begin dan met het uitcommentariëren (en dus tijdelijk verwijderen) van blokken code.
  • Zodra je van de parsingfout af bent, heb je de probleembron gevonden. Kijk daar nog eens goed.
  • Soms wil je complete functie/methode blokken tijdelijk verwijderen. (In het geval van ongematchte accolades en verkeerd ingesprongen code).
  • Wanneer je het syntax probleem niet kunt oplossen, probeer dan de uitgecommentarieerde secties vanaf nul te herschrijven.

• Als nieuwkomer, vermijd enkele van de verwarrende syntax constructies.

  • De ternaire ? : conditie-operator kan code compact maken en is inderdaad nuttig. Maar het helpt niet in alle gevallen de leesbaarheid. Geef de voorkeur aan gewone if statements als ze niet gebruikt worden.
  • PHP's alternatieve syntaxis (if:/elseif:/endif;) is gebruikelijk voor templates, maar aantoonbaar minder gemakkelijk te volgen dan normale { code } blokken.

• De meest voorkomende fouten van nieuwkomers zijn:

  • Ontbrekende puntkomma ; voor het beëindigen van statements/regels.
  • Mismatched string quotes voor " of ' en unescaped quotes daarbinnen.
  • Vergeten operatoren, in het bijzonder voor de string . aaneenschakeling.
  • Onevenwichtige ( haakjes ). Tel ze in de gerapporteerde regel. Zijn het er een gelijk aantal?

• Vergeet niet dat het oplossen van één syntax probleem het volgende kan blootleggen.

  • Als je één probleem laat verdwijnen, maar een ander duikt op in sommige code eronder, ben je meestal op de goede weg.
  • Als na het bewerken een nieuwe syntaxfout opduikt in dezelfde lijn, dan was je poging tot wijziging mogelijk een mislukking. (Niet altijd echter.)

• Herstel een backup van eerder werkende code, als je'het niet kunt repareren.

  • Neem een versiebeheersysteem voor broncode aan. Je kunt altijd een diff bekijken van de kapotte en laatst werkende versie. Wat verhelderend kan zijn over wat het syntax probleem is.
    

• Onzichtbare verdwaalde Unicode tekens: In sommige gevallen moet je een hexeditor gebruiken of een andere editor/viewer op je broncode. Sommige problemen kunnen niet gevonden worden door alleen naar de code te kijken.

  • Probeer grep --color -P -n "\[\x80-\xFF]" file.php als de eerste maatregel om niet-ASCII symbolen te vinden.
  • In het bijzonder BOMs, spaties met een breedte van nul, of niet-brekende spaties, en slimme aanhalingstekens kunnen regelmatig hun weg vinden in de broncode.

• Let op welk type regeleindes worden opgeslagen in bestanden.

  • PHP honoreert gewoon \n newlines, niet \r carriage returns.
  • Dit is af en toe een probleem voor MacOS gebruikers (zelfs op OS  X voor verkeerd geconfigureerde editors).
  • Het komt vaak alleen naar voren als een probleem wanneer eenregelig // of # commentaar wordt gebruikt. Meerregelig /*...*/ commentaar stoort de parser zelden als regeleindes worden genegeerd.

• Als uw syntaxfout niet over het web verstuurt: Het komt voor dat je een syntaxfout hebt op je machine. Maar als je datzelfde bestand online zet, treedt die fout niet meer op. Wat maar één van twee dingen kan betekenen:

  • U kijkt naar het verkeerde bestand!
  • Of uw code bevatte onzichtbare verdwaalde Unicode (zie hierboven). U kunt er gemakkelijk achter komen: Kopieer gewoon je code terug van het webformulier in je tekstverwerker.

• Controleer uw PHP versie. Niet alle syntax constructies zijn beschikbaar op elke server.

  • php -v voor de command line interpreter
  • <?php phpinfo(); voor degene die via de webserver wordt aangeroepen.
    Die zijn niet noodzakelijkerwijs hetzelfde. Vooral als je met frameworks werkt, zul je ze op elkaar moeten afstemmen.

• Gebruik PHP's reserved keywords niet als identifiers voor functies/methodes, klassen of constanten.

• Trial-and-error is uw laatste redmiddel. Als al het andere faalt, kunt u altijd uw foutmelding googelen. Syntax-symbolen zijn niet zo gemakkelijk te doorzoeken (Stack Overflow zelf wordt wel geïndexeerd door SymbolHound). Daarom kan het nodig zijn om nog een paar pagina's door te kijken voordat je iets relevants vindt. Verdere gidsen:

• PHP Debugging Basics door David Sklar

• PHP fouten oplossen]13* door Jason McCreary

• PHP fouten - 10 veel voorkomende fouten]14* door Mario Lurig

• Veel voorkomende PHP fouten en oplossingen

• Hoe kunt u problemen oplossen en uw WordPress website repareren

• Een gids voor PHP foutmeldingen voor ontwerpers - Smashing Magazine

  Wit scherm van de dood

  Als uw website gewoon leeg is, dan is meestal een syntaxisfout de oorzaak. Schakel hun weergave in met:

  • error_reporting = E_ALL
  • display_errors = 1 In uw php.ini in het algemeen, of via .htaccess voor mod_php, of zelfs .user.ini met FastCGI opstellingen. Het inschakelen binnen het gebroken script is te laat omdat PHP't zelfs de eerste regel niet kan interpreteren/uitvoeren. Een snelle workaround is het maken van een wrapper script, zeg test.php:

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

Roep dan de falende code op door dit wrapper script te openen. Het helpt ook om PHP's error_log aan te zetten en in je webserver's error.log te kijken wanneer een script crasht met HTTP 500 responses.

Onverwachte T_VARIABLE

Een "onverwachte T_VARIABLE" betekent dat er'een letterlijke $variabele naam is, die'niet past in de huidige expressie/statement structuur.

1. Ontbrekende puntkomma

   Dit duidt meestal op een ontbrekende puntkomma in de vorige regel. Variabele-toewijzingen na een statement zijn een goede indicator waar te kijken:

           ⇓
    func1()
    $var = 1 + 2; # parsefout in regel +2

2. String aaneenschakeling

   Een veel voorkomende fout zijn string aaneenschakelingen met vergeten . operator:

                                   ⇓
    print "Hier komt de waarde: " $value;

   Btw, je zou de voorkeur moeten geven aan string interpolation (basis variabelen tussen dubbele aanhalingstekens) wanneer dat de leesbaarheid ten goede komt. Dat vermijdt deze syntax problemen.

   String interpolatie is een scripting taal kern functie. Geen schande om het te gebruiken. Negeer elk micro-optimalisatie advies over variabele . aaneenschakeling die sneller is. Het's niet.

3. Ontbrekende expressie operatoren

   Hetzelfde probleem kan zich natuurlijk ook voordoen bij andere expressies, bijvoorbeeld rekenkundige bewerkingen:

               ⇓
    print 4 + 7 $var;

   PHP kan hier niet gissen of de variabele moet worden opgeteld, afgetrokken of vergeleken enz.

4. Lijsten

   Idem voor syntax-lijsten, zoals in array-populaties, waar de parser ook een verwachte komma , aangeeft bijvoorbeeld:

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

   Of functies parameter lijsten:

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

   Vergelijkbaar zie je dit met list of global statements, of bij het ontbreken van een ; puntkomma in een for loop.

5. Klasseverklaringen

   Deze parser error komt ook voor in class declarations. Je kunt alleen statische constanten toewijzen, geen expressies. De parser klaagt dus over variabelen als toegewezen gegevens:

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

   Ongeëvenaarde } afsluitende accolades kunnen hier in het bijzonder toe leiden. Als een methode te vroeg wordt afgesloten (gebruik de juiste inspringing!), dan wordt een verdwaalde variabele vaak misplaatst in de class declaration body.

6. Variabelen na identifiers

   Je kan ook nooit een variabele direct na een identifier laten komen:

                 ⇓
    $this->myFunc$VAR();

   Btw, dit is een veelvoorkomend voorbeeld waar het de bedoeling was om variabele variabelen misschien te gebruiken. In dit geval een variabele property lookup met $this->{"myFunc$VAR"}(); bijvoorbeeld.

   Bedenk dat het gebruik van variabele variabelen een uitzondering moet zijn. Nieuwkomers proberen ze vaak te nonchalant te gebruiken, zelfs wanneer arrays eenvoudiger en meer geschikt zouden zijn.

7. Ontbrekende parens na taalconstructies

   Haastig typen kan leiden tot het vergeten van openende haakjes voor if en for en foreach statements:

           ⇓
    foreach $array als $key) {

   Oplossing: voeg de ontbrekende opening ( toe tussen statement en variabele.

8. Else verwacht geen condities

         ⇓
    else ($var >= 0)

   Oplossing: Verwijder de voorwaarden uit else of gebruik elseif.

9. Haakjes nodig voor afsluiting

         ⇓
    functie() gebruikt $var {}

   Oplossing: Voeg haakjes toe rond $var.

10. Onzichtbare spaties

    Zoals vermeld in het referentie-antwoord op "Invisible stray Unicode" (zoals een non-breaking space), kunt u deze fout ook zien bij nietsvermoedende code zoals:

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

    Het komt nogal vaak voor in het begin van bestanden en bij gekopieerde en geplakte code. Controleer met een hexeditor, als uw code visueel geen syntaxisprobleem lijkt te bevatten.

Zie ook

• Zoeken: onverwachte T_VARIABLE](http://www.google.com/search?q=site:stackoverflow.com+php%20parse%20error%20unexpected#q=site:stackoverflow.com+php+parse+error+unexpected+T_VARIABLE)

Onverwachte T_STRING

T_STRING is een beetje een verkeerde benaming. Het verwijst niet naar een geciteerde "string". Het betekent dat er een ruwe identifier is aangetroffen. Dit kan variëren van kale woorden tot overgebleven CONSTANT of functienamen, vergeten ongequote strings, of elke willekeurige platte tekst.

1. Verkeerd geciteerde strings

   Deze syntax fout komt het meest voor bij verkeerd geciteerde string waarden. Elke niet-escaped en verdwaalde `"` of `'` quote zal een ongeldige expressie vormen: ⇓ ⇓ echo "click here"; Syntax highlighting zal zulke fouten super duidelijk maken. Het is belangrijk om te onthouden om backslashes te gebruiken voor het escapen van dubbele aanhalingstekens, of enkele aanhalingstekens - afhankelijk van welke gebruikt werd als [string enclosure][1]. - Voor het gemak kun je het beste enkele aanhalingstekens gebruiken als je HTML uitvoert met dubbele aanhalingstekens erin. - Gebruik strings met dubbele aanhalingstekens als je variabelen wilt interpoleren, maar pas dan op voor het escapen van letterlijke `"` dubbele aanhalingstekens. - Voor langere uitvoer, geef de voorkeur aan meerdere `echo`/`print` regels in plaats van het escapen van in en uit. Beter nog is om een [HEREDOC][2] sectie te overwegen. Zie ook *https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php*.

2. Unclosed strings

   Als je [een afsluitende `"`][3] mist, dan ontstaat er later typisch een syntax fout. Een string die niet wordt afgesloten zal vaak een beetje code opslokken tot de volgende bedoelde stringwaarde: ⇓ echo "Some text", $a_variable, "and some runaway string ; succes("finished"); ⇯ Het's niet alleen letterlijke `T_STRING`s waartegen de parser dan kan protesteren. Een andere veel voorkomende variant is een [`Unexpected '>'`](https://stackoverflow.com/questions/6507796/troubleshooting-parse-error-unexpected-error) voor unquoted literal HTML.

3. Niet-programmeerbare string quotes

   Als je code *kopieert en plakt* van een blog of website, kom je soms uit op ongeldige code. [Typografische aanhalingstekens zijn'niet][4] wat PHP verwacht: $text = 'Iets iets...' + "this ain't quotes"; Typografische/smarte aanhalingstekens zijn Unicode-symbolen. PHP behandelt ze als deel van aangrenzende alfanumerieke tekst. Bijvoorbeeld `"these` wordt geïnterpreteerd als een constante identificator. Maar elke volgende letterlijke tekst wordt dan door de parser gezien als een kaal woord/T_STRING.

4. De ontbrekende puntkomma; alweer

   Als je een expressie zonder puntkomma hebt in de vorige regels, dan wordt elk volgend statement of taalconstructie gezien als een ruwe identifier: ⇓ func1() function2(); PHP kan gewoon niet weten of je bedoelde om twee functies na elkaar uit te voeren, of dat je bedoelde om hun resultaten te vermenigvuldigen, op te tellen, te vergelijken, of alleen de ene `||` of de andere uit te voeren.

5. Korte open tags en <?xml headers in PHP scripts

   Dit is vrij ongewoon. Maar als short_open_tags zijn ingeschakeld, dan kun je'je PHP-scripts niet beginnen [met een XML-declaratie][5]: ⇓ <?xml version="1.0"?> PHP zal de `<?` zien en het voor zichzelf opeisen. Het zal niet begrijpen waar de verdwaalde `xml` voor bedoeld was. Het zal worden geïnterpreteerd als een constante. Maar de `versie` zal worden gezien als een andere letterlijke/constante. En aangezien de parser niets kan begrijpen van twee opeenvolgende letterwoorden/waarden zonder een uitdrukkingsoperator ertussen, zal dat'een parserfout zijn.

6. Onzichtbare Unicode tekens

   Een afschuwelijke oorzaak van syntaxfouten zijn Unicode-symbolen, zoals de [non-breaking space][6]. PHP laat Unicode karakters toe als identifier namen. Als u een T_STRING parser klacht krijgt voor geheel onverdachte code zoals: <?php print dan 123; Dan moet je een andere tekst editor tevoorschijn halen. Of zelfs een hexeditor. Wat hier lijkt op gewone spaties en nieuwe regels, kan onzichtbare constanten bevatten. Java-gebaseerde IDE's zijn soms ongevoelig voor een UTF-8 BOM gemangeld binnen, nul-breedte spaties, paragraaf scheidingstekens, enz. Probeer alles opnieuw te bewerken, witruimte te verwijderen en normale spaties weer toe te voegen. Je kunt het beperken door overbodige `;` scheidingstekens toe te voegen aan het begin van elke regel: <?php ;print 123; De extra `;` puntkomma hier zal het voorafgaande onzichtbare karakter omzetten in een ongedefinieerde constante verwijzing (expressie als statement). Wat er op zijn beurt voor zorgt dat PHP een nuttige mededeling produceert.

7. Het `$` teken ontbreekt voor variabelenamen

   [Variabelen in PHP][7] worden voorgesteld door een dollarteken gevolgd door de naam van de variabele. Het dollarteken (`$`) is een [sigil][8] die de identifier markeert als een naam van een variabele. Zonder dit teken zou de identifier een [taalsleutelwoord][9] of een [constante][10] kunnen zijn. Dit is een veel voorkomende fout wanneer de PHP-code werd ["vertaald" uit code geschreven in een andere taal][11] (C, Java, JavaScript, enz.). In dergelijke gevallen kan een verklaring van het type variabele (wanneer de originele code werd geschreven in een taal die getypte variabelen gebruikt) er ook tussenuit knijpen en deze fout veroorzaken.

8. Ontsnapte aanhalingstekens

   Als je `` gebruikt in een string, heeft dat een speciale betekenis. Dit heet een "[Escape Character][12]" en vertelt de parser normaal gesproken om het volgende karakter letterlijk te nemen. Voorbeeld: `echo 'Jim said #39;Hello'';` zal afdrukken `Jim said 'hello'` Als je de afsluitende quote van een string escape, zal de afsluitende quote letterlijk genomen worden en niet zoals bedoeld, d.w.z. als een afdrukbare quote als deel van de string en niet de string afsluiten. Dit zal verschijnen als een parse-fout, meestal na het openen van de volgende string of aan het einde van het script. Veel voorkomende fout bij het opgeven van paden in Windows: `"C:\xampphtdocs\"` is fout. Je hebt `"C:\xampp\htdocs\"` nodig.