Alle støter på syntaksfeil. Selv erfarne programmerere gjør skrivefeil. For nykommere er det bare en del av læringsprosessen. Imidlertid er det ofte lett å tolke feilmeldinger som:
PHP Parse-feil: syntaksfeil, uventet '{' i index.php på linje 20 Det uventede symbolet er ikke alltid den virkelige synderen. Men linjenummeret gir en grov idé om hvor du skal begynne å lete. Se alltid på kodekonteksten. Syntaksfeilen skjuler seg ofte i den nevnte eller i foregående kodelinjer. Sammenlign koden din med syntakseksemplene i håndboken. Selv om ikke alle tilfeller samsvarer med hverandre. Likevel finnes det noen generelle trinn for å løse syntaksfeil. Denne referansen oppsummerer de vanligste fallgruvene:
- Unexpected T_STRING
- Uventet T_VARIABLE
Uventet '$varname' (T_VARIABLE)- Unexpected T_CONSTANT_ENCAPSED_STRING
Unexpected T_ENCAPSED_AND_WHITESPACE- Uventet $slutt
- Unexpected T_FUNCTION...
- Unexpected
{
Unexpected}
Unexpected(
Unexpected)
- Uventet
[
Uventet]
- Unexpected T_IF
Unexpected T_FOREACH
Unexpected T_FOR
Unexpected T_WHILE
Unexpected T_DO
Unexpected T_PRINT
Unexpected T_ECHO- Unexpected T_LNUMBER
- Uventet ?
- Uventet fortsette (T_CONTINUE)
Uventet fortsette (T_BREAK)
Uventet fortsette (T_RETURN)- Uventet '='
- Unexpected T_INLINE_HTML...
- Unexpected T_PAAMAYIM_NEKUDOTAYIM...
- Unexpected T_OBJECT_OPERATOR...
- Unexpected T_DOUBLE_ARROW...
- Uventet T_SL...
- Unexpected T_BOOLEAN_OR...
Unexpected T_BOOLEAN_AND... [Unexpected T_BOOLEAN_AND](https://stackoverflow.com/questions/8668461/unexpected-t-boolean-and-error-in-my-if-statement)..;- Unexpected T_IS_EQUAL
Unexpected T_IS_GREATER_OR_EQUAL
Uventet T_IS_IDENTICAL
Uventet T_IS_NOT_EQUAL
Uventet T_IS_NOT_IDENTICAL
Uventet T_IS_SMALLER_OR_EQUAL
Uventet<
Uventet>
- Uventet T_NS_SEPARATOR...
- Uventet tegn i input: '
\
' (ASCII=92) state=1- Uventet 'public' (T_PUBLIC)
Uventet 'private' (T_PRIVATE)
Uventet 'protected' (T_PROTECTED)
Uventet 'final' (T_FINAL)...- Unexpected T_STATIC...
- Unexpected T_CLASS...
- Unexpected T_DNUMBER
- Unexpected
,
(comma)- Uventet
.
(punktum)- Uventet
;
(semikolon)- Unexpected
*
(asterisk)- Uventet
:
(kolon) Nært beslektede referanser:- Hva betyr denne feilen i PHP? (kjøretidsfeil)
- Parse-feil: syntaksfeil, uventet T_XXX
- Parse-feil: syntaksfeil, uventet T_ENCAPSED_AND_WHITESPACE
- Parse-feil: syntaksfeil, uventet T_VARIABLE
- Hva betyr dette symbolet i PHP? (language tokens)
- Disse
""
smart''
anførselstegnene betyr ingenting for PHP Og:
- PHP-manualen på php.net og dens forskjellige språksymboler
- Eller Wikipedias syntaksintroduksjon om PHP.
- Og til slutt vår php tag-wiki selvfølgelig. Mens Stack Overflow også ønsker nybegynnere velkommen, er det for det meste rettet mot profesjonelle programmeringsspørsmål.
- Å svare på alles kodingsfeil og smale skrivefeil anses for det meste utenfor emnet.
- Så vennligst ta deg tid til å følge de grunnleggende trinnene før du legger ut forespørsler om syntaksfiksering.
Hvis du likevel må, vennligst vis ditt eget løsningsinitiativ, forsøk på rettelser og din tankeprosess om hva som ser ut eller kan være feil. Hvis nettleseren din viser feilmeldinger som "SyntaxError: ulovlig tegn", er det ikke [tag:php]-relatert, men en [tag:javascript]-syntaksfeil.
Syntaksfeil hevet på leverandørkode: Til slutt, vurder at hvis syntaksfeilen ikke ble hevet ved å redigere kodebasen din, men etter en ekstern leverandørpakkeinstallasjon eller oppgradering, kan det skyldes inkompatibilitet med PHP-versjonen, så sjekk leverandørens krav mot plattformoppsettet ditt.
PHP tilhører programmeringsspråkene C-stil og imperativ. Det har stive grammatikkregler, som det ikke kan gjenopprette når det støter på feilplasserte symboler eller identifikatorer. Det kan ikke gjette dine kodingsintensjoner. Funksjonsdefinisjon syntaks abstrakt
Det er noen grunnleggende forholdsregler du alltid kan ta:
En typisk syntaksfeilmelding lyder som følger:
Parse-feil: syntaksfeil, uventet T_STRING, forventer '
;
' i file.php på line 217. Som viser den mulige plasseringen av en syntaksfeil. Se det nevnte filnavnet og linjenummeret. En moniker somT_STRING
forklarer hvilket symbol parseren/tokenizeren ikke kunne behandle til slutt. Dette er imidlertid ikke nødvendigvis årsaken til syntaksfeilen. Det er viktig å se på tidligere kodelinjer også. Ofte er syntaksfeil bare uhell som skjedde tidligere. Feillinjenummeret er akkurat der parseren definitivt ga opp å behandle det hele.Løse syntaksfeil
Det er mange tilnærminger for å begrense og fikse syntakshikke.
{
kodeblokker }
er feil lukket eller nestet, må du kanskje undersøke enda lenger opp i kildekoden. Bruk riktig kodeinnrykk for å forenkle det.+-*/.
bør også være farget forskjellig. Ellers kan de være i feil sammenheng.&"
eller &"
strengmarkør.++
, --
eller parenteser etter en operator. To strenger/identifikatorer direkte etter hverandre er feil i de fleste sammenhenger.if
-setninger i forskjellige eller nestede if
-betingelser.? :
betingelsesoperatoren kan komprimere kode og er faktisk nyttig. Men det hjelper ikke lesbarheten i alle tilfeller. Foretrekker vanlige if
uttalelser mens du ikke er kjent.if:
/elseif:
/endif;
) er vanlig for maler, men uten tvil mindre lett å følge enn vanlige {
kode }
blokker.;
for å avslutte utsagn/linjer."
eller '
og anførselstegn som ikke er omsluttet av anførselstegn..
.(
parenteser )
. Tell dem i den rapporterte linjen. Er det like mange av dem?diff
av den ødelagte og siste fungerende versjonen. Noe som kan være opplysende om hva syntaksproblemet er.
grep --color -P -n "\[\x80-\xFF\]" file.php
som det første tiltaket for å finne ikke-ASCII-symboler.//
eller #
kommentarer brukes. Flerlinjers /*...*/
-kommentarer forstyrrer sjelden parseren når linjeskift blir ignorert.php -v
for kommandolinjetolkeren.<?php phpinfo();
for den som påkalles via webserveren.
Disse er ikke nødvendigvis de samme. Spesielt når du arbeider med rammeverk, vil du at de skal matche hverandre.Hvis nettstedet ditt bare er tomt, er det vanligvis en syntaksfeil som er årsaken. Aktiver visningen med:
error_reporting = E_ALL
(feilrapportering = E_ALL)display_errors = 1
I din php.ini
generelt, eller via .htaccess
for mod_php,
eller til og med .user.ini
med FastCGI-oppsett.
Å aktivere det i det ødelagte skriptet er for sent fordi PHP ikke engang kan tolke / kjøre den første linjen. En rask løsning er å lage et wrapper-skript, for eksempel test.php
:<?php
error_reporting(E_ALL);
ini_set("display_errors", 1);
include("./broken-script.php");
Påkall deretter den feilende koden ved å få tilgang til dette innpakningsskriptet.
Det hjelper også å aktivere PHPs error_log
og se i webserverens error.log
når et skript krasjer med HTTP 500-svar.
En "uventet T_VARIABLE" betyr at det finnes et bokstavelig "$variabel"-navn som ikke passer inn i den aktuelle uttrykks-/setningsstrukturen.
(bevisst abstrakt/unøyaktig operator+$variabel-diagram].
Det indikerer oftest et manglende semikolon i forrige linje. Variabeltilordninger etter et utsagn er en god indikator på hvor du skal lete:
⇓
func1()
$var = 1 + 2; # parse-feil i linje +2
Et hyppig uhell er string concatenations med glemt .
-operator:
⇓
print "Her kommer verdien: " $verdi;
Forresten, du bør foretrekke string interpolation (grunnleggende variabler i doble anførselstegn) når det hjelper lesbarheten. Som unngår disse syntaksproblemer.
Strenginterpolasjon er en skriptspråk kjernefunksjon. Ingen skam i å bruke det. Ignorer eventuelle mikrooptimaliseringsråd om at variabel
.
sammenkjeding er raskere . **Det er det ikke.
Det samme problemet kan selvfølgelig oppstå i andre uttrykk, for eksempel aritmetiske operasjoner:
⇓
print 4 + 7 $lt;
PHP kan ikke gjette her om variabelen skal legges til, trekkes fra eller sammenlignes osv.
Samme for syntakslister, som i array-populasjoner, der parseren også indikerer et forventet komma ,
for eksempel:
⇓
$var = array("1" => $val, $val2, $val3 $val4);
Eller lister med funksjonsparametere:
⇓
function myfunc($param1, $param2 $param3, $param4)
Tilsvarende ser du dette med list
- eller global
-setninger, eller når det mangler et ;
semikolon i en for
-løkke.
Denne parserfeilen forekommer også i klassedeklarasjoner. Du kan bare tilordne statiske konstanter, ikke uttrykk. Dermed klager parseren på variabler som tilordnede data:
class xyz { ⇓
var $verdi = $_GET["input"];
Uovertruffen }
avsluttende krøllete klammeparenteser kan spesielt føre til dette. Hvis en metode avsluttes for tidlig (bruk riktig innrykk!), blir en herreløs variabel ofte feilplassert i klassedeklarasjonskroppen.
Du kan heller aldri ha en variabel etter en identifikator direkte:
⇓
$this->myFunc$VAR();
Btw, dette er et vanlig eksempel der intensjonen var å bruke variable variabler kanskje. I dette tilfellet et variabelegenskapsoppslag med $this->{"myFunc$VAR"}();
for eksempel.
Husk at bruk av variable variabler bør være unntaket. Nykommere prøver ofte å bruke dem for tilfeldig, selv når matriser ville være enklere og mer passende.
Forhastet skriving kan føre til at man glemmer åpningsparentesen
for if
og for
og foreach
-setninger:
⇓
foreach $array as $key) {
Løsning: legg til den manglende åpningen (
mellom setning og variabel.
⇓
else ($var >= 0)
Løsning: Fjern betingelsene fra else
eller bruk elseif
.
⇓
function() bruker $var {}
Løsning: Legg til parenteser rundt $var
.
Som nevnt i referansesvaret på "Invisible stray Unicode" (for eksempel et non-breaking space), kan du også se denne feilen for intetanende kode som:
<?php
⇐
$var = new PDO(...);
Det er ganske utbredt i starten av filer og for kode som er kopiert og limt inn. Sjekk med en hexeditor om koden din ikke ser ut til å inneholde et syntaksproblem.
T_STRINGer litt av en misvisende betegnelse. Det refererer ikke til en sitert
"streng"`. Det betyr at en rå identifikator ble funnet. Dette kan være alt fra "nakne" ord til rester av "KONSTANT" eller funksjonsnavn, glemte strenger uten anførselstegn eller ren tekst.
<?xml
overskrifter i PHP-skript