PHP parse / syntaks feil; og hvordan løse dem?

Hva er syntaksfeilene?

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

De viktigste tipsene

Det er noen grunnleggende forholdsregler du alltid kan ta:

• Bruk riktig kodeinnrykk, eller ta i bruk en høy kodestil. Lesbarhet forhindrer uregelmessigheter.
• Bruk en IDE eller editor for PHP med syntaksutheving. Som også hjelper med parenteser/klammeparenteser. Forventet: semikolon]5.
• Les språkreferansen og eksempler i håndboken. To ganger, for å bli noenlunde dyktig.

  Hvordan tolke parserfeil

  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 som T_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.

• Åpne den nevnte kildefilen. Se på den nevnte kodelinjen .
  • For løpske strenger og feilplasserte operatorer er det vanligvis her du finner synderen.
  • Les linjen fra venstre til høyre og forestill deg hva hvert symbol gjør.
• Mer regelmessig må du også se på foregående linjer.
  • Det er særlig semikolon som mangler ved forrige linjeslutt/utsagn. (I det minste fra et stilistisk synspunkt. )
  • Hvis { kodeblokker } er feil lukket eller nestet, må du kanskje undersøke enda lenger opp i kildekoden. Bruk riktig kodeinnrykk for å forenkle det.
• Se på syntax colorization!
  • Strenger og variabler og konstanter skal alle ha forskjellige farger.
  • Operatorer +-*/. bør også være farget forskjellig. Ellers kan de være i feil sammenheng.
  • Hvis du ser strengfarging strekker seg for langt eller for kort, har du funnet en uescaped eller manglende avsluttende &" eller &" strengmarkør.
  • Å ha to tegnsettingstegn i samme farge ved siden av hverandre kan også bety problemer. Vanligvis er operatorer ensomme hvis det ikke er ++, -- eller parenteser etter en operator. To strenger/identifikatorer direkte etter hverandre er feil i de fleste sammenhenger.
• Mellomrom er din venn. Følg en hvilken som helst kodestil. La oss imidlertid ikke plage nybegynnere med PSR-x her, K? -->
• Bryt opp lange linjer midlertidig.
  • Du kan fritt legge til nye linjer mellom operatorer eller konstanter og strenger. Parseren vil da konkretisere linjenummeret for parsingfeil. I stedet for å se på den veldig lange koden, kan du isolere det manglende eller feilplasserte syntakssymbolet.
  • Del opp komplekse if-setninger i forskjellige eller nestede if-betingelser.
  • I stedet for lange matematiske formler eller logiske kjeder, bruk midlertidige variabler for å forenkle koden. (Mer lesbar = færre feil).
  • Legg til nye linjer mellom:
    1. Koden du lett kan identifisere som korrekt,
    2. Delene du er usikker på,
    3. Og linjene som parseren klager på.
       Partisjonering av lange kodeblokker hjelper virkelig til å finne opprinnelsen til syntaksfeil.
• Kommenter ut krenkende kode.
  • Hvis du ikke kan isolere problemkilden, begynner du å kommentere ut (og dermed midlertidig fjerne) kodeblokker.
  • Så snart du ble kvitt analyseringsfeilen, har du funnet problemkilden. Se nærmere der.
  • Noen ganger vil du midlertidig fjerne komplette funksjons- / metodeblokker. (I tilfelle uoverensstemmende krøllete parenteser og feil innrykket kode).
  • Når du ikke kan løse syntaksproblemet, kan du prøve å omskrive de kommenterte seksjonene fra bunnen av.
• Som nybegynner bør du unngå noen av de forvirrende syntakskonstruksjonene.
  • Den ternære ? : 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.
  • PHP&# 39s alternative syntaks (if:/elseif:/endif;) er vanlig for maler, men uten tvil mindre lett å følge enn vanlige { kode } blokker.
• De mest utbredte nybegynnerfeilene er:
  • Manglende semikolon ; for å avslutte utsagn/linjer.
  • Feil anførselstegn for " eller ' og anførselstegn som ikke er omsluttet av anførselstegn.
  • Glemte operatorer, særlig for sammenkjeding av strengen ..
  • Ubalanserte ( parenteser ). Tell dem i den rapporterte linjen. Er det like mange av dem?
• Ikke glem at å løse ett syntaksproblem kan avdekke det neste.
  • Hvis du får ett problem til å forsvinne, men andre dukker opp i noen kode nedenfor, er du stort sett på rett vei.
  • Hvis en ny syntaksfeil dukker opp i samme linje etter redigering, var endringsforsøket ditt muligens en feil. (Men ikke alltid.)
• Gjenopprett en sikkerhetskopi av tidligere fungerende kode, hvis du ikke kan fikse den.
  • Ta i bruk et versjoneringssystem for kildekode. Du kan alltid se en diff av den ødelagte og siste fungerende versjonen. Noe som kan være opplysende om hva syntaksproblemet er.
    
• Usynlige Unicode-tegn på avveie: I noen tilfeller må du bruke en hexeditor eller en annen editor/viewer på kilden din. Noen problemer kan ikke finnes bare ved å se på koden din.
  • Prøv grep --color -P -n "\[\x80-\xFF\]" file.php som det første tiltaket for å finne ikke-ASCII-symboler.
  • Spesielt stykklister, nullbredde mellomrom, eller ikke-brytende mellomrom, og smarte anførselstegn kan regelmessig finne veien inn i kildekoden.
• Ta vare på hvilken type linjeskift som er lagret i filer.
  • PHP respekterer bare \n nye linjer, ikke \r vognreturer.
  • Noe som av og til er et problem for MacOS-brukere (selv på OS X for feilkonfigurerte redaktører).
  • Det dukker ofte bare opp som et problem når enlinjers // eller # kommentarer brukes. Flerlinjers /*...*/-kommentarer forstyrrer sjelden parseren når linjeskift blir ignorert.
• Hvis syntaksfeilen din ikke overføres over nettet: Det hender at du har en syntaksfeil på maskinen din. Men når du legger ut den samme filen på nettet, vises den ikke lenger. Det kan bare bety én av to ting:
  • Du ser på feil fil!
  • Eller koden din inneholder usynlig Unicode på avveie (se ovenfor). Du kan enkelt finne ut av det: Bare kopier koden tilbake fra nettskjemaet til tekstredigeringsprogrammet ditt.
• Sjekk din PHP-versjon. Ikke alle syntakskonstruksjoner er tilgjengelige på alle servere.
  • 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.
• Ikke bruk PHPs reserverte nøkkelord som identifikatorer for funksjoner / metoder, klasser eller konstanter.
• Prøving og feiling er din siste utvei. Hvis alt annet mislykkes, kan du alltids google feilmeldingen din. Syntakssymboler er ikke like enkle å søke etter (Stack Overflow i seg selv er indeksert av SymbolHound skjønt). Derfor kan det ta å se gjennom noen flere sider før du finner noe relevant. Ytterligere guider:
• Grunnleggende om feilsøking i PHP av David Sklar
• Å fikse PHP-feil av Jason McCreary
• PHP-feil - 10 vanlige feil av Mario Lurig
• Vanlige PHP-feil og løsninger av Mario Lurig
• Hvordan feilsøke og fikse WordPress-nettstedet ditt [En guide til PHP-feilmeldinger
• En guide til PHP-feilmeldinger for designere - Smashing Magazine

  Hvit skjerm av død

  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.

Uventet T_VARIABLE

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].

1. Manglende semikolon

   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

2. String concatenation

   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.

3. Manglende uttrykksoperatorer

   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.

4. Lister

   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.

5. Klassedeklarasjoner

   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.

6. Variabler etter identifikatorer

   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.

7. Manglende parens etter språkkonstruksjoner

   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.

8. Else forventer ikke betingelser

         ⇓
    else ($var >= 0)

   Løsning: Fjern betingelsene fra else eller bruk elseif.

9. Trenger parenteser for avslutning

         ⇓
    function() bruker $var {}

   Løsning: Legg til parenteser rundt $var.

10. Usynlig mellomrom

    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.

Se også

• Søk: unexpected T_VARIABLE

Uventet T_STRING

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.

1. Feilsiterte strenger

   Denne syntaksfeilen er imidlertid mest vanlig for feilsiterte strengverdier. Enhver unescaped og bortkommen `"` eller `'` sitat vil danne et ugyldig uttrykk: ⇓ ⇓ echo "klikk her"; Syntaksutheving vil gjøre slike feil super åpenbare. Det er viktig å huske å bruke backslashes for å fjerne doble anførselstegn eller enkle anførselstegn - avhengig av hva som ble brukt som [string enclosure][1]. - For enkelhets skyld bør du foretrekke ytre enkle anførselstegn når du skriver ut ren HTML med doble anførselstegn innenfor. - Bruk doble anførselstegn hvis du ønsker å interpolere variabler, men pass da på å unngå bokstavelige doble anførselstegn. - For lengre utdata, foretrekker du flere `echo`/`print`-linjer i stedet for å escape inn og ut. Enda bedre er det å vurdere en [HEREDOC][2]-seksjon. Se også *https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php*.

2. Uavsluttede strenger

   Hvis du [går glipp av et avsluttende `"`][3], oppstår det vanligvis en syntaksfeil senere. En underminert streng vil ofte forbruke litt kode til neste tiltenkte strengverdi: ⇓ echo "Noe tekst", $a_variabel, "og en løpsk streng ; suksess("ferdig"); ⇯ Det er ikke bare bokstavelig `T_STRING` som parseren kan protestere på da. En annen hyppig variant er en [`Uventet '>'`](https://stackoverflow.com/questions/6507796/troubleshooting-parse-error-unexpected-error) for ikke-sitert bokstavelig HTML.

3. Ikke-programmerende anførselstegn

   Hvis du *kopierer og limer inn* kode fra en blogg eller et nettsted, ender du noen ganger opp med ugyldig kode. [Typografiske anførselstegn er ikke][4] hva PHP forventer: $text = 'Noe noe ..' + "dette er ikke anførselstegn"; Typografiske/smarte anførselstegn er Unicode-symboler. PHP behandler dem som en del av tilstøtende alfanumerisk tekst. For eksempel tolkes `"these` som en konstant identifikator. Men enhver påfølgende tekst bokstavelig blir da sett på som et bareword/T_STRING av parseren.

4. Det manglende semikolon; igjen

   Hvis du har et underminert uttrykk i tidligere linjer, blir enhver påfølgende setning eller språkkonstruksjon sett på som rå identifikator: ⇓ func1() function2(); PHP kan bare ikke vite om du mente å kjøre to funksjoner etter hverandre, eller om du mente å multiplisere resultatene deres, legge dem til, sammenligne dem eller bare kjøre den ene `||` eller den andre.

5. Korte åpne koder og <?xml overskrifter i PHP-skript

   Dette er ganske uvanlig. Men hvis short_open_tags er aktivert, kan du ikke starte PHP-skriptet [med en XML-erklæring][5]: ⇓ <?xml version="1.0"?> PHP vil se `<?` og gjenvinne det for seg selv. Det vil ikke forstå hva den bortkomne `xml` var ment for. Det vil bli tolket som konstant. Men `versjonen` vil bli sett på som en annen bokstavelig/konstant. Og siden parseren ikke kan gi mening av to påfølgende literaler/verdier uten en uttrykksoperator i mellom, vil det være en parserfeil.

6. Usynlige Unicode-tegn

   En mest heslig årsak til syntaksfeil er Unicode-symboler, for eksempel [non-breaking space][6]. PHP tillater Unicode-tegn som identifikatornavn. Hvis du får en T_STRING parser klage for helt uskyldig kode som: <?php skriv ut 123; Du må bryte ut en annen tekstredigerer. Eller en hexeditor til og med. Det som ser ut som vanlige mellomrom og nye linjer her, kan inneholde usynlige konstanter. Java-baserte IDE-er er noen ganger uvitende om en UTF-8 BOM manglet i, nullbredde mellomrom, skilletegn osv. Prøv å redigere alt på nytt, fjern mellomrom og legg til normale mellomrom igjen. Du kan begrense det med å legge til overflødige `;` skilletegn ved hver linjestart: <?php ;print 123; Det ekstra `;` semikolon her vil konvertere det foregående usynlige tegnet til en udefinert konstant referanse (uttrykk som uttalelse). Som til gjengjeld får PHP til å produsere en nyttig melding.

7. Tegnet `$` mangler foran variabelnavn

   [Variabler i PHP][7] er representert med et dollartegn etterfulgt av navnet på variabelen. Dollartegnet (`$`) er et [sigil][8] som markerer identifikatoren som et navn på en variabel. Uten dette tegnet kan identifikatoren være et [språknøkkelord][9] eller en [konstant][10]. Dette er en vanlig feil når PHP-koden ble ["oversatt" fra kode skrevet på et annet språk][11] (C, Java, JavaScript osv.). I slike tilfeller kan en deklarasjon av variabeltypen (når den opprinnelige koden ble skrevet i et språk som bruker typede variabler) også snike seg ut og produsere denne feilen.

8. Unnslapp anførselstegn

   Hvis du bruker `\` i en streng, har det en spesiell betydning. Dette kalles et "[Escape Character][12]" og forteller normalt parseren å ta det neste tegnet bokstavelig. Eksempel: `echo 'Jim said \'Hello\'';` vil skrive ut `Jim said 'hello'`. Hvis du unngår det avsluttende anførselstegnet i en streng, vil det avsluttende anførselstegnet bli tatt bokstavelig og ikke som tiltenkt, dvs. som et anførselstegn som kan skrives ut som en del av strengen, og ikke avslutte strengen. Dette vises vanligvis som en parsefeil etter at du åpner neste streng eller på slutten av skriptet. Svært vanlig feil når du spesifiserer baner i Windows: `"C:\xampp\htdocs\"` er feil. Du trenger `"C:\\xampp\\htdocs\"`.