Iedereen loopt tegen syntax fouten aan. Zelfs ervaren programmeurs maken tikfouten. Voor nieuwkomers, het's gewoon een deel van het leerproces. Echter, het'is vaak gemakkelijk om foutmeldingen te interpreteren zoals:
PHP Parse error: syntaxfout, onverwachte '{' in index.php op regel 20 Het onverwachte symbool is'niet altijd de echte boosdoener. Maar het regelnummer geeft een ruw idee van waar te beginnen met zoeken. Kijk altijd naar de code context. De syntaxisfout verbergt zich vaak in de genoemde of in vorige coderegels. Vergelijk uw code met syntax voorbeelden uit de handleiding. Hoewel niet elk geval overeenkomt met het andere. Toch zijn er enkele algemene stappen om syntaxisfouten op te lossen. Deze referenties vatten de veel voorkomende valkuilen samen:
- Onverwachte T_STRING
- Onverwachte T_VARIABLE
Onverwachte '$varname' (T_VARIABLE)- Onverwacht T_CONSTANT_ENCAPSED_STRING
Onverwacht T_ENCAPSED_AND_WHITESPACE- Onverwacht $end
- Onverwachte T_FUNCTION...
- Onverwacht
{
Onverwacht}
Onverwacht(
Onverwacht)
- Onverwacht
[
Onverwacht]
- Onverwachte T_IF
Onverwachte T_FOREACH
Onverwachte T_FOR
Onverwachte T_WHILE
Onverwachte T_DO
Onverwachte T_PRINT
Onverwachte T_ECHO- Onverwacht T_LNUMBER
- Onverwacht ?
- Unexpected continue (T_CONTINUE)
Unexpected continue (T_BREAK)
Unexpected continue (T_RETURN)- Onverwacht '='
- Onverwachte T_INLINE_HTML...
- Onverwachte T_PAAMAYIM_NEKUDOTAYIM...
- Onverwachte T_OBJECT_OPERATOR...
- Onverwacht T_DOUBLE_ARROW...
- Onverwacht T_SL...
- Onverwachte T_BOOLEAN_OR...
Onverwachte T_BOOLEAN_AND...- Onverwachte T_IS_EQUAL
Onverwachte T_IS_GREATER_OR_EQUAL
Onverwachte T_IS_IDENTICAL
Onverwachte T_IS_NOT_EQUAL
Onverwachte T_IS_NOT_IDENTICAL
Onverwachte T_IS_SMALLER_OR_EQUAL
Onverwacht<
Onverwacht>
- Onverwachte T_NS_SEPARATOR...
- Onverwacht teken in invoer: '``' (ASCII=92) state=1
- Onverwacht 'public' (T_PUBLIC)
Onverwacht 'private' (T_PRIVATE)
Onverwacht 'protected' (T_PROTECTED)
Onverwacht 'final' (T_FINAL)...- Onverwacht T_STATISCH...
- Onverwachte T_CLASS...
- Onverwacht T_DNUMBER
- Onverwacht
,
(komma)- Onverwachte
.
(punt)- Onverwachte
;
(puntkomma)- Onverwachte
*
](https://stackoverflow.com/q/32905365/3933332) (sterretje)- Onverwacht
:
(dubbele punt) Nauw verwante referenties:- Wat betekent deze fout in PHP? (runtime errors)
- Parsefout: syntaxfout, onverwachte T_XXX
- Parsefout: syntaxisfout, onverwachte T_ENCAPSED_AND_WHITESPACE
- Parsefout: syntaxisfout, onverwachte T_VARIABLE
- Wat betekent dit symbool in PHP? (taal tokens)
- Die
""
slimme''
aanhalingstekens betekenen niets voor PHP En:
- De PHP handleiding op php.net en zijn verschillende language tokens
- Of Wikipedia's syntax introductie over PHP.
- En als laatste natuurlijk onze php tag-wiki. Hoewel Stack Overflow ook beginnende programmeurs verwelkomt, is het vooral gericht op professionele programmeervragen.
- Het beantwoorden van iedereen's coderingsfouten en kleine typefouten wordt meestal beschouwd als off-topic.
- Dus neem de tijd om de basis stappen te volgen, voordat je syntax fixing verzoeken plaatst.
Als je toch moet, toon dan je eigen oplossingsinitiatief, pogingen tot fixes, en je denkproces over wat er fout lijkt of zou kunnen zijn. Als uw browser foutmeldingen weergeeft zoals "SyntaxError: illegal character", dan is het'eigenlijk niet [tag:php]-gerelateerd, maar een [tag:javascript]-syntax fout.
Syntaxisfouten veroorzaakt door code van de leverancier: Tenslotte, denk eraan dat als de syntaxisfout niet veroorzaakt werd door het bewerken van uw codebase, maar na een installatie of upgrade van een extern pakket van de leverancier, het te wijten zou kunnen zijn aan PHP-versie incompatibiliteit, dus controleer de vereisten van de leverancier tegen uw platform setup.
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
Er zijn een paar basis voorzorgsmaatregelen die je altijd kunt nemen:
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 zoalsT_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.
;
puntkomma's bij de voorgaande regeleinden/statements. (Althans vanuit stilistisch oogpunt. ){
codeblokken }
verkeerd gesloten of genest zijn, moet u misschien nog verder in de broncode zoeken. Gebruik de juiste code-inspringing om dat te vereenvoudigen.+-*/.
moeten ook verschillend gekleurd zijn. Anders zouden ze in de verkeerde context kunnen staan."
of '
string marker gevonden die niet is ge-escaped of ontbreekt.++
, --
, of haakjes na een operator staan. Twee strings/identifiers direct na elkaar zijn onjuist in de meeste contexten.if
statements op in afzonderlijke of geneste if
condities.? :
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.if:
/elseif:
/endif;
) is gebruikelijk voor templates, maar aantoonbaar minder gemakkelijk te volgen dan normale {
code }
blokken.;
voor het beëindigen van statements/regels."
of '
en unescaped quotes daarbinnen..
aaneenschakeling.(
haakjes )
. Tel ze in de gerapporteerde regel. Zijn het er een gelijk aantal?diff
bekijken van de kapotte en laatst werkende versie. Wat verhelderend kan zijn over wat het syntax probleem is.
grep --color -P -n "\[\x80-\xFF]" file.php
als de eerste maatregel om niet-ASCII symbolen te vinden.//
of #
commentaar wordt gebruikt. Meerregelig /*...*/
commentaar stoort de parser zelden als regeleindes worden genegeerd.php -v
voor de command line interpreter<?php phpinfo();
voor degene die via de webserver wordt aangeroepen.
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.
Een "onverwachte T_VARIABLE
" betekent dat er'een letterlijke $variabele
naam is, die'niet past in de huidige expressie/statement structuur.
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
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.
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.
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.
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.
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.
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.
⇓
else ($var >= 0)
Oplossing: Verwijder de voorwaarden uit else
of gebruik elseif
.
⇓
functie() gebruikt $var {}
Oplossing: Voeg haakjes toe rond $var
.
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.
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.
<?xml
headers in PHP scripts