Erori de parse/sintaxa PHP; și cum să le rezolvăm?

Care sunt erorile de sintaxă?

PHP aparține limbajelor de programare stil C și imperativ. Acesta are reguli gramaticale rigide, pe care nu le poate recupera atunci când întâlnește simboluri sau identificatori greșit plasați. Nu vă poate ghici intențiile de codare.

Cele mai importante sfaturi

Există câteva precauții de bază pe care le puteți lua întotdeauna:

• Folosiți o indentare corespunzătoare a codului, sau adoptați orice stil de codare elevat. Lizibilitatea previne neregulile.

• Folosiți un IDE sau un editor pentru PHP cu semnalizare de sintaxă. Care ajută, de asemenea, la echilibrarea parantezelor/parantezelor.

• Citiți referința limbajului și exemplele din manual. De două ori, pentru a deveni oarecum competent.

  Cum se interpretează erorile parserului

  Un mesaj tipic de eroare de sintaxă sună astfel::

  Eroare de parsare: eroare de sintaxă, neașteptată T_STRING, așteptând ';' în file.php pe linie 217. Care enumeră locația posibilă a unei erori de sintaxă. Vedeți numele fișierului și numărul liniei menționate. Un moniker, cum ar fi T_STRING, explică ce simbol nu a putut fi procesat în cele din urmă de parser/tokenizer. Totuși, aceasta nu este neapărat cauza greșelii de sintaxă. Este important să vă uitați și la linii de cod anterioare. Adesea, erorile de sintaxă sunt doar niște ghinioane care s-au întâmplat anterior. Numărul liniei de eroare este doar locul unde parserul a renunțat în mod concludent să proceseze totul.

  Rezolvarea erorilor de sintaxă

  Există mai multe abordări pentru a restrânge și a rezolva sughițuri de sintaxă.

• Deschideți fișierul sursă menționat. Uitați-vă la linia de cod menționată.

  • Pentru șiruri de caractere fugare și operatori greșit plasați, aici este de obicei locul unde găsiți vinovatul.
  • Citiți linia de la stânga la dreapta și imaginați-vă ce face fiecare simbol.

• Mai regulat, trebuie să vă uitați și la linii precedente.

  • În special, lipsesc punctele și virgulele ; la capetele de linie/la declarațiile anterioare. (Cel puțin din punct de vedere stilistic. )
  • Dacă {blocuri de cod `}`` sunt închise sau imbricate incorect, s-ar putea să trebuiască să investigați și mai sus în codul sursă. Folosiți o indentare corespunzătoare a codului pentru a simplifica acest lucru.

• Uitați-vă la colorizarea sintaxei!

  • Șirurile de caractere, variabilele și constantele ar trebui să aibă toate culori diferite.
  • Operatorii +-*/. ar trebui să fie și ei colorați distinct. Altfel, ar putea fi în context greșit.
  • Dacă vedeți că colorarea șirurilor se extinde prea mult sau prea puțin, atunci ați găsit un marker de închidere a șirurilor " sau ' neescapsulat sau lipsă.
  • Faptul că există două caractere de punctuație de aceeași culoare unul lângă celălalt poate însemna, de asemenea, probleme. De obicei, operatorii sunt singuri dacă nu este ++, -- sau paranteze după un operator. Două șiruri de caractere/identificatori care urmează direct unul după altul sunt incorecte în majoritatea contextelor.

• Spațiul alb este prietenul tău. Urmați orice stil de codare.

• Despărțiți temporar liniile lungi.

  • Puteți adăuga liber adăuga linii noi între operatori sau constante și șiruri de caractere. Analizatorul va concretiza apoi numărul liniei pentru erori de analiză. În loc să vă uitați la codul foarte lung, puteți izola simbolul de sintaxă lipsă sau greșit plasat.
  • Împărțiți declarațiile if complexe în condiții if distincte sau imbricate.
  • În loc de formule matematice sau lanțuri logice lungi, utilizați variabile temporare pentru a simplifica codul. (Mai ușor de citit = mai puține erori).
  • Adăugați linii noi între:
    1. Codul pe care îl puteți identifica cu ușurință ca fiind corect,
    2. Părțile de care nu sunteți siguri,
    3. Și liniile de care se plânge parserul.
       Împărțirea blocurilor lungi de cod ajută de fapt la localizarea originii erorilor de sintaxă.

• Comentați codul incriminat.

  • Dacă nu puteți izola sursa problemei, începeți să comentați (și astfel să eliminați temporar) blocuri de cod.
  • De îndată ce ați scăpat de eroarea de parsare, ați găsit sursa problemei. Uitați-vă mai atent acolo.
  • Uneori doriți să eliminați temporar blocuri complete de funcții/metode. (În cazul bretelelor nepotrivite și al codului indentat greșit).
  • Atunci când nu puteți rezolva problema de sintaxă, încercați să descrieți secțiunile comentate de la zero.

• În calitate de nou-venit, evitați unele dintre construcțiile sintactice confuze.

  • Operatorul de condiție ternară ? : poate compacta codul și este într-adevăr util. Dar nu ajută la lizibilitate în toate cazurile. Preferați declarațiile if simple în timp ce nu sunteți versat.
  • Sintaxa alternativă a PHP'lui (if:/elseif:/endif;) este obișnuită pentru șabloane, dar se poate spune că este mai puțin ușor de urmărit decât blocurile normale { cod }.

• Cele mai răspândite greșeli ale începătorilor sunt:

  • Lipsește punctul și virgula ; pentru terminarea instrucțiunilor/liniei.
  • Ghilimele de șiruri de caractere necorespunzătoare pentru " sau ' și ghilimele necompletate în interiorul lor.
  • Operatori uitați, în special pentru concatenarea șirurilor de caractere ..
  • Dezechilibrarea (paranteze ). Numărați-le în linia raportată. Există un număr egal de ele?

• Nu uitați că rezolvarea unei probleme de sintaxă o poate descoperi pe următoarea.

  • Dacă faceți ca o problemă să dispară, dar apare alta în codul de mai jos, sunteți în mare parte pe drumul cel bun.
  • Dacă după editare apare o nouă eroare de sintaxă în aceeași linie, atunci este posibil ca încercarea dumneavoastră de modificare să fi fost un eșec. (Nu întotdeauna însă.)

• Restaurați o copie de rezervă a codului care a funcționat anterior, dacă nu puteți rezolva problema.

  • Adoptați un sistem de versionare a codului sursă. Puteți vizualiza întotdeauna un diff al versiunii defecte și al ultimei versiuni de lucru. Ceea ce ar putea fi lămuritor pentru a afla care este problema de sintaxă.
    

• Caractere Unicode rătăcite invizibile: În unele cazuri, trebuie să folosiți un hexeditor sau un alt editor/vizualizator pe sursa dvs. Unele probleme nu pot fi găsite doar uitându-vă la codul dvs.

  • Încercați grep --color -P -n "\[\x80-\xFF\]" file.php ca primă măsură pentru a găsi simboluri non-ASCII.
  • În special BOM-urile, spațiile de lățime zero sau spațiile fără întrerupere și ghilimelele inteligente își pot găsi cu regularitate drumul în codul sursă.

• Aveți grijă la ce tip de întreruperi de linie sunt salvate în fișiere.

  • PHP onorează doar \n newlines, nu \r carriage returns.
  • Ceea ce reprezintă ocazional o problemă pentru utilizatorii MacOS (chiar și pe OS  X pentru editorii configurați greșit).
  • De multe ori apare ca o problemă doar atunci când se folosesc comentarii // sau # pe o singură linie. Comentariile cu mai multe linii /*...*/ deranjează rareori parserul atunci când sunt ignorate întreruperile de linie.

• În cazul în care erorile de sintaxă nu se transmit pe web: Se întâmplă să aveți o eroare de sintaxă pe calculatorul dumneavoastră. Dar postarea aceluiași fișier pe internet nu o mai prezintă. Ceea ce nu poate însemna decât unul din două lucruri:

  • Vă uitați la fișierul greșit!
  • Sau codul dumneavoastră conținea Unicode rătăcit invizibil (vezi mai sus). Puteți afla cu ușurință: Copiați codul din formularul web în editorul de text.

• Verificați versiunea PHP. Nu toate construcțiile sintactice sunt disponibile pe fiecare server.

  • php -v pentru interpretorul de linie de comandă
  • <?php phpinfo(); pentru cel invocat prin intermediul serverului web.
    Acestea nu sunt'neapărat identice. În special atunci când lucrați cu framework-uri, le veți face să se potrivească.

• Nu folosiți cuvintele cheie rezervate din PHP ca identificatori pentru funcții/metode, clase sau constante.

• Încercarea și eroarea este ultima ta soluție. Dacă toate celelalte eșuează, puteți oricând să google mesajul de eroare. Simbolurile de sintaxă nu sunt la fel de ușor de căutat (totuși, Stack Overflow însuși este indexat de SymbolHound). Prin urmare, este posibil să fie nevoie să căutați prin mai multe pagini înainte de a găsi ceva relevant. Alte ghiduri:

• PHP Debugging Basics de David Sklar

• Repararea erorilor PHP de Jason McCreary

• Erori PHP - 10 greșeli comune de Mario Lurig

• Erori PHP comune și soluții

• Cum să depanați și să vă reparați site-ul WordPress

• Un ghid al mesajelor de eroare PHP pentru designeri - Smashing Magazine

  Ecranul alb al morții

  Dacă site-ul dvs. este pur și simplu alb, atunci, de obicei, cauza este o eroare de sintaxă. Activați afișarea acestora cu: - Afișează-le cu:

  • error_reporting = E_ALL
  • display_errors = 1 În php.ini dumneavoastră, în general, sau prin .htaccess pentru mod_php, sau chiar în .user.ini pentru configurațiile FastCGI. Activarea acestuia în cadrul scriptului stricat este prea târziu, deoarece PHP nu poate nici măcar să interpreteze/execute prima linie. O soluție rapidă este crearea unui script wrapper, să zicem test.php:

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

Apoi, apelați codul care nu funcționează prin accesarea acestui script de tip wrapper. De asemenea, este util să activați error_log al PHP's și să vă uitați în error.log al webserver's error.log atunci când un script se blochează cu răspunsuri HTTP 500.

Neașteptat T_VARIABLE

Un "unexpected T_VARIABLE" înseamnă că există un nume literal $variable, care nu se potrivește în structura expresiei/extrasului curent.

1. Semicolon lipsă

   Cel mai frecvent indică un punct și virgulă lipsă în linia anterioară. Atribuțiile variabilelor care urmează după o declarație sunt un bun indicator unde trebuie căutat:

           ⇓
    func1()
    $var = 1 + 2; # eroare de analiză în linia +2

2. Concatenare de șiruri

   O greșeală frecventă sunt concatenările de șiruri cu operatorul . uitat:

                                   ⇓
    print "Iată valoarea: " $valoare;

   Btw, ar trebui să preferați string interpolation (variabile de bază între ghilimele duble) ori de câte ori acest lucru ajută la lizibilitate. Ceea ce evită aceste probleme de sintaxă.

   Interpolarea șirurilor de caractere este o caracteristică de bază a limbajului de scripting. Nu este nicio rușine să o folosiți. Ignorați orice sfat de micro-optimizare despre concatenarea variabilelor . fiind mai rapidă. Nu este așa.

3. Operatori de expresie lipsă

   Desigur, aceeași problemă poate apărea și în alte expresii, de exemplu în cazul operațiilor aritmetice:

               ⇓
    print 4 + 7 $var;

   PHP nu poate gândi aici dacă variabila ar fi trebuit să fie adăugată, scăzută sau comparată etc.

4. Lists

   Același lucru pentru listele de sintaxă, ca în populațiile de array-uri, unde parserul indică și o virgulă așteptată ,, de exemplu:

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

   Sau liste de parametri de funcții:

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

   Echivalent vedeți acest lucru cu instrucțiuni list sau global, sau atunci când lipsește un punct și virgulă ; într-o buclă for.

5. Declarații de clasă

   Această eroare de parser apare, de asemenea, în declarațiile de clasă. Puteți atribui doar constante statice, nu și expresii. Astfel, parserul se plânge de variabile ca date alocate:

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

   În mod special, acoladele de închidere } nepotrivite pot duce aici. Dacă o metodă este terminată prea devreme (folosiți indentarea corespunzătoare!), atunci o variabilă rătăcită este de obicei plasată greșit în corpul declarației clasei.

6. Variabile după identificatori

   De asemenea, nu puteți avea niciodată o variabilă după un identificator direct:

                 ⇓
    $this->myFunc$VAR();

   Btw, acesta este un exemplu obișnuit în care intenția a fost de a folosi variabile variabile poate. În acest caz, o căutare a proprietății variabilei cu $this->{"myFunc$VAR"}();, de exemplu.

   Rețineți că utilizarea variabilelor variabile ar trebui să fie o excepție. Nou-veniții încearcă adesea să le folosească cu prea multă dezinvoltură, chiar și atunci când array-urile ar fi mai simple și mai potrivite.

7. Paranteze lipsă după construcțiile de limbaj

   Tastarea precipitată poate duce la uitarea parantezelor de deschidere pentru instrucțiunile if și for și foreach:

           ⇓
    foreach $array as $key) {

   Soluție: adăugați ( de deschidere lipsă între declarație și variabilă.

8. Else nu așteaptă condiții

         ⇓
    else ($var >= 0)

   Soluție: Eliminați condițiile din else sau utilizați elseif.

9. Aveți nevoie de paranteze pentru închidere

         ⇓
    function() folosește $var {}

   Soluție: Adăugați paranteze în jurul lui $var.

10. Spațiu alb invizibil

    După cum s-a menționat în răspunsul de referință privind "Unicode invizibil rătăcit" (cum ar fi un spațiu fără întrerupere), este posibil să vedeți această eroare și pentru coduri nesuspectaculoase de genul

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

    Este destul de răspândit la începutul fișierelor și pentru codul copiat și lipit. Verificați cu un hexeditor, dacă vizual codul dumneavoastră nu pare să conțină o problemă de sintaxă.

A se vedea, de asemenea

• Căutare: unexpected T_VARIABLE

Unexpected T_STRING

T_STRING este o denumire puțin greșită. Acesta nu se referă la un "șir de caractere". Înseamnă că a fost întâlnit un identificator brut. Acesta poate varia de la cuvinte bare la resturi de CONSTANT sau nume de funcții, șiruri de caractere uitate și necotate, sau orice text simplu.

1. Șiruri necotate

   Această eroare de sintaxă este însă cea mai frecventă pentru valorile de șiruri de caractere greșit citate. Orice ghilimele `"` sau `'` necompletate și rătăcite vor forma o expresie invalidă: ⇓ ⇓ echo "click aici"; Evidențierea sintaxei va face ca astfel de greșeli să fie super evidente. Este important să nu uitați să folosiți backslashes pentru a scăpa de ghilimelele duble `\"` sau ghilimelele simple `\'` - în funcție de ce a fost folosit ca [string enclosure][1]. - Pentru comoditate, ar trebui să preferați ghilimelele simple exterioare atunci când scoateți HTML simplu cu ghilimele duble în interior. - Utilizați șiruri de caractere cu ghilimele duble dacă doriți să interpolați variabile, dar atunci aveți grijă la scăparea ghilimelelor duble literale `"`. - Pentru ieșiri mai lungi, preferați mai multe linii `echo`/`print` în loc să scăpați înăuntru și afară. Mai bine luați în considerare o secțiune [HEREDOC][2]. A se vedea, de asemenea, *https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php*.

2. Șiruri de caractere neînchise

   Dacă [omiteți o `"` de închidere][3][3], atunci o eroare de sintaxă se materializează de obicei mai târziu. Un șir de caractere neterminat va consuma adesea un pic de cod până la următoarea valoare de șir de caractere prevăzută: ⇓ echo "Some text", $a_variable, "and some runaway string ; success("terminat"); ⇯ Nu este vorba doar de `T_STRING`s literale pe care parserul le poate protesta atunci. O altă variantă frecventă este un [`Unexpected '>'`](https://stackoverflow.com/questions/6507796/troubleshooting-parse-error-unexpected-error) pentru HTML literal necotat.

3. Non-programming string quotes

   Dacă *copi și lipești* codul de pe un blog sau de pe un site web, uneori te trezești cu un cod invalid. [Ghilimelele tipografice nu sunt ceea ce așteaptă PHP][4]: $text = 'Ceva ceva ceva..' + "these ain't quotes"; Ghilimelele tipografice/smart sunt simboluri Unicode. PHP le tratează ca parte a textului alfanumeric adiacent. De exemplu `"these` este interpretat ca un identificator constant. Dar orice text literal care urmează este văzut ca un cuvânt gol/T_STRING de către parser.

4. Punct și virgulă lipsă; din nou

   Dacă aveți o expresie neterminată în liniile anterioare, atunci orice declarație sau construcție lingvistică următoare este văzută ca un identificator brut: ⇓ func1() func2(); PHP pur și simplu nu-și poate da seama dacă ați vrut să rulați două funcții una după alta, sau dacă ați vrut să le înmulțiți rezultatele, să le adăugați, să le comparați sau să executați doar una `|||` sau cealaltă.

5. Etichete deschise scurte și <?xml anteturi în scripturile PHP

   Acest lucru este destul de neobișnuit. Dar dacă short_open_tags sunt activate, atunci nu vă puteți începe scripturile PHP [cu o declarație XML][5]: ⇓ <?xml version="1.0"?> PHP va vedea `<?` și îl va revendica pentru el însuși. Nu va'înțelege pentru ce a fost destinat `xml` rătăcit. Va fi interpretat ca fiind o constantă. Dar `version` va fi văzut ca un alt literal/constant. Și din moment ce parserul nu poate înțelege două literale/valori ulterioare fără un operator de expresie între ele, va fi un eșec al parserului.

6. Caractere Unicode invizibile

   O cauză cea mai hidoasă pentru erorile de sintaxă sunt simbolurile Unicode, cum ar fi [spațiu fără întrerupere][6]. PHP permite caractere Unicode ca nume de identificator. Dacă primiți o reclamație a parserului T_STRING pentru un cod complet nesuspect precum: <?php print 123; trebuie să scoateți un alt editor de text. Sau chiar un hexeditor. Ceea ce pare a fi simple spații și linii noi aici, poate conține constante invizibile. IDE-urile bazate pe Java sunt uneori indiferente la un BOM UTF-8 modificat, la spațiile de lățime zero, la separatoarele de paragraf etc. Încercați să reeditați totul, să eliminați spațiile albe și să adăugați din nou spații normale. Puteți restrânge căutarea prin adăugarea de separatori de declarații `;` redundanți la fiecare început de linie: <?php ;print 123; Punctul și virgula suplimentară `;` de aici va converti caracterul invizibil anterior într-o referință constantă nedefinită (expresie ca declarație). Ceea ce, în schimb, face ca PHP să producă o notificare utilă.

7. Semnul `$` lipsă în fața numelor de variabile

   [Variabilele în PHP][7] sunt reprezentate de un semn de dolar urmat de numele variabilei. Semnul dolarului (`$`) este un [sigil][8] care marchează identificatorul ca fiind numele unei variabile. Fără acest sigiliu, identificatorul ar putea fi un [cuvânt cheie de limbaj][9] sau o [constantă][10]. Aceasta este o eroare frecventă atunci când codul PHP a fost ["tradus" din cod scris într-un alt limbaj][11] (C, Java, JavaScript etc.). În astfel de cazuri, o declarație a tipului de variabilă (atunci când codul original a fost scris într-un limbaj care utilizează variabile tipizate) ar putea, de asemenea, să se strecoare și să producă această eroare.

8. Ghilimele scăpate

   Dacă folosiți `\` într-un șir de caractere, acesta are o semnificație specială. Acesta se numește "[Caracter de evadare][12]" și în mod normal îi spune parserului să ia caracterul următor la propriu. Exemplu: `echo 'Jim said \'Hello'';`` va imprima `Jim said 'hello'``. Dacă scăpați ghilimelele de închidere ale unui șir de caractere, ghilimelele de închidere vor fi luate literal și nu așa cum au fost intenționate, adică ca ghilimele tipărite ca parte a șirului și nu vor închide șirul. Acest lucru se va afișa ca o eroare de analiză în mod obișnuit după ce deschideți următorul șir sau la sfârșitul scriptului. Eroare foarte frecventă la specificarea căilor de acces în Windows: `"C:\xampp\htdocs\"` este greșit. Aveți nevoie de `"C:\xampp\\\htdocs\\\"`.