Errori di analisi/sintassi di PHP; e come risolverli?

Quali sono gli errori di sintassi?

PHP appartiene ai linguaggi di programmazione stile C e imperativo. Ha regole grammaticali rigide, dalle quali non può riprendersi quando incontra simboli o identificatori fuori posto. Non può indovinare le vostre intenzioni di codifica.

Consigli più importanti

Ci sono alcune precauzioni di base che puoi sempre prendere:

• Usare una corretta indentazione del codice, o adottare uno stile di codifica elevato. La leggibilità previene le irregolarità.
• Usare un IDE o editor per PHP con evidenziazione della sintassi. Che aiutano anche a bilanciare parentesi e parentesi.
• Leggere il riferimento al linguaggio e gli esempi nel manuale. Due volte, per diventare un po' abili.

  Come interpretare gli errori del parser

  Un tipico messaggio di errore di sintassi recita: Parse error: syntax error, unexpected T_STRING, expecting ';' in file.php on line 217 Che elenca la possibile posizione di un errore di sintassi. Vedi il nome del file e il numero della linea menzionati. Un moniker come T_STRING spiega quale simbolo il parser/tokenizer non ha potuto elaborare alla fine. Questa non è necessariamente la causa dell'errore di sintassi, tuttavia. E' importante guardare anche le linee di codice precedenti. Spesso gli errori di sintassi sono solo contrattempi accaduti in precedenza. Il numero della linea di errore è solo il punto in cui il parser ha definitivamente rinunciato ad elaborare il tutto.

  Risolvere gli errori di sintassi

  Ci sono molti approcci per restringere e risolvere gli errori di sintassi.

• Aprire il file sorgente menzionato. Guardate la linea di codice menzionata.
  • Per le stringhe in fuga e gli operatori mal posizionati, questo è di solito il punto in cui si trova il colpevole.
  • Leggete la linea da sinistra a destra e immaginate cosa fa ogni simbolo.
• Più regolarmente dovete guardare anche le linee precedenti.
  • In particolare, mancano i punti e virgola ; alla fine della linea/stato precedente. (Almeno dal punto di vista stilistico. )
  • Se i blocchi di codice {}` sono chiusi o annidati in modo scorretto, potresti aver bisogno di indagare ancora più in alto nel codice sorgente. Usa una corretta indentazione del codice per semplificare la cosa.
• Guardate la colorazione della sintassi!
  • Stringhe, variabili e costanti dovrebbero avere tutti colori diversi.
  • Anche gli operatori +-*/. dovrebbero essere colorati separatamente. Altrimenti potrebbero essere nel contesto sbagliato.
  • Se vedete che la colorazione delle stringhe si estende troppo lontano o troppo corto, allora avete trovato un marcatore di stringa " o ' di chiusura mancante.
  • Anche avere due caratteri di punteggiatura dello stesso colore uno accanto all'altro può significare problemi. Di solito, gli operatori sono solitari se non sono ++, --, o parentesi che seguono un operatore. Due stringhe/identificatori che si seguono direttamente sono scorretti nella maggior parte dei contesti.
• Lo spazio bianco è tuo amico*. Segui qualsiasi* stile di codifica. Non disturbiamo i neofiti con il PSR-x qui, comunque, K? -->
• Spezza temporaneamente le linee lunghe.
  • Puoi liberamente aggiungere newlines tra operatori o costanti e stringhe. Il parser concretizzerà poi il numero di linea per gli errori di parsing. Invece di guardare il codice molto lungo, si può isolare il simbolo di sintassi mancante o fuori posto.
  • Dividere complesse istruzioni if in condizioni if distinte o annidate.
  • Invece di lunghe formule matematiche o catene logiche, usate variabili temporanee per semplificare il codice. (Più leggibile = meno errori).
  • Aggiungere i newline tra:
    1. Il codice che si può facilmente identificare come corretto,
    2. Le parti di cui non sei sicuro,
    3. E le linee di cui il parser si lamenta; Suddividere lunghi blocchi di codice aiuta veramente a localizzare l'origine degli errori di sintassi.
• Commenta il codice incriminato.
  • Se non potete isolare la fonte del problema, iniziate a commentare (e quindi rimuovere temporaneamente) blocchi di codice.
  • Non appena vi siete liberati dell'errore di parsing, avete trovato la fonte del problema. Guardate più da vicino lì.
  • A volte volete rimuovere temporaneamente interi blocchi di funzioni/metodi. (Nel caso di parentesi graffe spaiate e codice indentato in modo errato).
  • Quando non potete risolvere il problema di sintassi, provate a riscrivere le sezioni commentate da zero.
• Come nuovo arrivato, evitate alcuni dei confusi costrutti sintattici.
  • L'operatore di condizione ternario ? : può compattare il codice ed è davvero utile. Ma non aiuta la leggibilità in tutti i casi. Preferite le semplici dichiarazioni if quando non sono state superate.
  • La sintassi alternativa di PHP (if:/elseif:/endif;) è comune per i template, ma probabilmente meno facile da seguire dei normali blocchi di {codice }.
• Gli errori più diffusi tra i nuovi arrivati sono:
  • Punto e virgola mancante ; per terminare le dichiarazioni/linee.
  • Virgolette di stringa non corrispondenti per " o ' e virgolette non catturate all'interno.
  • Operatori dimenticati, in particolare per la concatenazione di stringhe ..
  • Sbilanciamento di ( parentesi ). Contatele nella riga riportata. Ce ne sono un numero uguale?
• Non dimenticare che risolvere un problema di sintassi può far emergere il successivo.
  • Se fai sparire un problema, ma ne spunta un altro nel codice sottostante, sei per lo più sulla strada giusta.
  • Se dopo la modifica un nuovo errore di sintassi si presenta nella stessa linea, allora il vostro tentativo di modifica è stato probabilmente un fallimento. (Non sempre però).
• Ripristinate un backup del codice precedentemente funzionante, se non riuscite a risolverlo.
  • Adottare un sistema di versioning del codice sorgente. Puoi sempre visualizzare un diff della versione rotta e dell'ultima versione funzionante. Il che potrebbe essere illuminante su quale sia il problema di sintassi. br/>
• Caratteri Unicode vaganti invisibili: In alcuni casi, è necessario usare un hexeditor o un diverso editor/visualizzatore sul tuo sorgente. Alcuni problemi non possono essere trovati solo guardando il tuo codice.
  • Prova [grep --color -P -n "\x80-\xFF\]" file.php]9 come prima misura per trovare simboli non-ASCII.
  • In particolare BOM, spazi a larghezza zero, o spazi non di interruzione, e le virgolette intelligenti possono trovare regolarmente la loro strada nel codice sorgente.
• Fate attenzione a quale tipo di interruzioni di riga vengono salvate nei file.
  • PHP onora solo \n newlines, non \r carriage returns.
  • Il che è occasionalmente un problema per gli utenti MacOS (anche su OS  X per gli editor mal configurati).
  • Spesso emerge come un problema solo quando si usano commenti a linea singola // o #. I commenti multilinea /*...*/ raramente disturbano il parser quando le interruzioni di riga vengono ignorate.
• Se il tuo errore di sintassi non si trasmette sul web: Succede che hai un errore di sintassi sulla tua macchina. Ma pubblicando lo stesso file online non lo si vede più. Il che può significare solo una delle due cose:
  • State guardando il file sbagliato!
  • Oppure il vostro codice contiene un Unicode invisibile (vedi sopra). Potete scoprirlo facilmente: Copia semplicemente il tuo codice dal modulo web nel tuo editor di testo.
• Controlla la tua versione di PHP. Non tutti i costrutti sintattici sono disponibili su tutti i server.
  • php -v per l'interprete della linea di comando
  • <?php phpinfo(); per quello invocato attraverso il webserver. Questi non sono necessariamente la stessa cosa. In particolare quando si lavora con i framework, li si vuole far combaciare.
• Non usare parole chiave riservate di PHP come identificatori di funzioni/metodi, classi o costanti.
• Il trial-and-error è la vostra ultima risorsa. Se tutto il resto fallisce, puoi sempre cercare su google il tuo messaggio di errore. I simboli di sintassi non sono così facili da cercare (Stack Overflow stesso è indicizzato da SymbolHound). Pertanto potrebbe essere necessario guardare attraverso alcune altre pagine prima di trovare qualcosa di rilevante. Altre guide:
• PHP Debugging Basics di David Sklar
• Correzione degli errori PHP di Jason McCreary
• Errori PHP - 10 errori comuni di Mario Lurig
• Errori PHP comuni e soluzioni
• Come risolvere i problemi e riparare il tuo sito web WordPress
• Una guida ai messaggi di errore PHP per i designer - Smashing Magazine

  Schermo bianco della morte

  Se il tuo sito web è semplicemente vuoto, allora tipicamente la causa è un errore di sintassi. Abilita la loro visualizzazione con:

  • error_reporting = E_ALL
  • display_errors = 1 Nel tuo [php.ini][18] in generale, o tramite [.htaccess][19] per mod_php, o anche [.user.ini][20] con le configurazioni FastCGI. Abilitarlo all'interno dello script rotto è troppo tardi perché PHP non può nemmeno interpretare/eseguire la prima linea. Un rapido workaround è creare uno script wrapper, diciamotest.php`:

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

Quindi invocare il codice che fallisce accedendo a questo script wrapper. Aiuta anche ad abilitare il error_log di PHP e guardare nel tuo webserver's error.log quando uno script va in crash con risposte HTTP 500.

T_VARIABILE inattesa

Un "unexpected T_VARIABLE" significa che c'è un nome letterale di $variabile, che non si adatta alla struttura dell'espressione/stato corrente.

1. Punto e virgola mancante

   Indica più comunemente un punto e virgola mancante nella riga precedente. Le assegnazioni di variabili che seguono una dichiarazione sono un buon indicatore di dove guardare:

           ⇓
    func1()
    $var = 1 + 2; # errore di parsing nella linea +2

2. concatenazione di stringhe

   Un errore frequente sono le concatenazioni di stringhe con l'operatore . dimenticato:

                                   ⇓
    print "Ecco il valore: " $valore;

   Btw, dovresti preferire interpolazione di stringhe (variabili di base tra virgolette doppie) quando ciò aiuta la leggibilità. Il che evita questi problemi di sintassi.

   L'interpolazione delle stringhe è una caratteristica fondamentale del linguaggio di scrittura. Nessuna vergogna nell'utilizzarla. Ignorate qualsiasi consiglio di micro-ottimizzazione sulla concatenazione delle variabili . che è più veloce. **Non lo è.

3. Operatori di espressione mancanti

   Naturalmente lo stesso problema può sorgere in altre espressioni, per esempio le operazioni aritmetiche:

               ⇓
    stampa 4 + 7 $var;

   PHP non può indovinare qui se la variabile deve essere aggiunta, sottratta o confrontata, ecc.

4. Liste

   /h3>

   Lo stesso per le liste sintattiche, come nelle popolazioni di array, dove il parser indica anche una virgola attesa , per esempio:

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

   O elenchi di parametri di funzioni:

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

   Equivalentemente lo vedete con dichiarazioni list o global, o quando manca un ; punto e virgola in un ciclo for.

5. Dichiarazioni di classe

   Questo errore del parser si verifica anche nelle dichiarazioni di classe. Si possono assegnare solo costanti statiche, non espressioni. Così il parser si lamenta delle variabili come dati assegnati:

    classe xyz { ⇓
        var $valore = $_GET["input"];

   Le parentesi graffe di chiusura non appaiate } possono in particolare portare qui. Se un metodo è terminato troppo presto (usate una corretta indentazione!), allora una variabile vagante è comunemente collocata in modo errato nel corpo della dichiarazione di classe.

6. Variabili dopo gli identificatori

   Non potete mai avere una variabile dopo un identificatore direttamente:

                 ⇓
    $this->myFunc$VAR();

   Btw, questo è un esempio comune in cui l'intenzione era di usare variabili variabili forse. In questo caso una ricerca di proprietà variabili con $this->{"myFunc$VAR"}(); per esempio.

   Tieni a mente che l'uso delle variabili dovrebbe essere l'eccezione. I nuovi arrivati spesso cercano di usarle con troppa disinvoltura, anche quando gli array sarebbero più semplici e appropriati.

7. Parentesi mancanti dopo i costrutti del linguaggio

   Una digitazione frettolosa può portare a dimenticare le parentesi di apertura per le dichiarazioni if e for e foreach:

           ⇓
    foreach $array as $key) {

   Soluzione: aggiungi l'apertura mancante ( tra l'istruzione e la variabile.

8. Else non prevede condizioni

         ⇓
    else ($var >= 0)

   Soluzione: Rimuovi le condizioni da else o usa elseif.

9. Servono parentesi per la chiusura

         ⇓
    function() usa $var {}

   Soluzione: Aggiungi le parentesi attorno a $var.

10. Spazi bianchi invisibili

    Come menzionato nella risposta di riferimento su "Invisible stray Unicode" (come un non-breaking space), potresti anche vedere questo errore per codice ignaro come:

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

    È piuttosto prevalente all'inizio dei file e per il codice copiato e incollato. Controllate con un hexeditor, se il vostro codice non sembra visivamente contenere un problema di sintassi.

Vedi anche

• Ricerca: unexpected 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)

T_STRING inaspettato

T_STRING è un po' un termine improprio. Non si riferisce a una "stringa" quotata. Significa che è stato incontrato un identificatore grezzo. Questo può spaziare da parole bare ad avanzi di CONSTANT o nomi di funzioni, stringhe dimenticate non quotate, o qualsiasi testo semplice.

1. Stringhe mal citate

   /h3> Questo errore di sintassi è più comune per valori di stringhe mal citate. Qualsiasi citazione senza escape e randagio " o ' formerà un'espressione non valida: ⇓ ⇓ echo "clicca qui"; L'evidenziazione della sintassi renderà questi errori super ovvi. E' importante ricordare di usare le backslashes per l'escape delle "doppie virgolette", o delle "virgolette singole" - a seconda di quale sia stato usato come "string enclosure"1.

   • Per comodità dovresti preferire le virgolette singole esterne quando emetti del semplice HTML con le doppie virgolette all'interno.
   • Usa le stringhe con doppi apici se vuoi interpolare le variabili, ma poi fai attenzione all'escaping dei doppi apici letterali ".
   • Per un output più lungo, preferisci più linee echo/print invece di usare l'escape in e out. Meglio ancora considerare una sezione HEREDOC. Vedere anche https://stackoverflow.com/questions/3446216/what-is-the-difference-between-single-quoted-and-double-quoted-strings-in-php.

2. Stringhe non chiuse Se manca una chiusura " allora un errore di sintassi tipicamente si materializza dopo. Una stringa non terminata spesso consumerà un po' di codice fino al prossimo valore di stringa previsto: ⇓ echo "Qualche testo", $a_variabile, "e qualche stringa non terminata ; successo("finito"); ⇯ Non sono solo le T_STRING letterali che il parser può protestare. Un'altra variazione frequente è un Unexpected '>' per HTML letterale non quotato.
3. H3>Non programmare le virgolette delle stringhe Se si copia e incolla* del codice da un blog o da un sito web, a volte si finisce con del codice non valido. 4 virgolette tipografiche non sono4 ciò che PHP si aspetta: $text = "Qualcosa di qualcosa... + "queste non sono virgolette"; Le virgolette tipografiche/smart sono simboli Unicode. PHP li tratta come parte del testo alfanumerico adiacente. Per esempio "these viene interpretato come un identificatore costante. Ma qualsiasi letterale di testo che segue è visto come una bareword/T_STRING dal parser.
4. Il punto e virgola mancante; ancora Se hai un'espressione non terminata nelle righe precedenti, allora qualsiasi dichiarazione o costrutto linguistico seguente viene visto come identificatore grezzo: ⇓ func1() function2(); PHP non può sapere se intendevi eseguire due funzioni dopo l'altra, o se intendevi moltiplicare i loro risultati, aggiungerli, confrontarli, o eseguire solo una || o l'altra.

5. Tag aperti brevi e <?xml intestazioni negli script PHP

   Questo è piuttosto raro. Ma se short_open_tags è abilitato, allora non puoi'iniziare i tuoi script PHP [con una dichiarazione XML][5]: ⇓ <?xml version="1.0"?> PHP vedrà il `<?` e lo reclamerà per sé. Non capirà a cosa serve l'"xml" vagante. Verrà interpretato come costante. Ma la `versione` sarà vista come un altro letterale/costante. E poiché il parser non può dare un senso a due valori letterali successivi senza un operatore di espressione in mezzo, questo sarà un fallimento del parser.
6. Caratteri Unicode invisibili Una causa più odiosa di errori di sintassi sono i simboli Unicode, come il non-breaking space. PHP permette i caratteri Unicode come nomi di identificatori. Se ottenete un reclamo del parser T_STRING per codice del tutto insospettabile come: <?php stampa 123; Dovete tirar fuori un altro editor di testo. O anche un hexeditor. Quello che sembra un semplice spazio e linee nuove qui, potrebbe contenere costanti invisibili. Gli IDE basati su Java sono a volte ignari di una UTF-8 BOM maciullata all'interno, spazi a larghezza zero, separatori di paragrafo, ecc. Prova a rieditare tutto, rimuovi gli spazi bianchi e aggiungi di nuovo gli spazi normali. Puoi restringere il campo con l'aggiunta di separatori di frase ridondanti ; all'inizio di ogni linea: <?php ;print 123; Il punto e virgola extra qui convertirà il carattere invisibile precedente in un riferimento costante non definito (espressione come dichiarazione). Il che in cambio fa sì che PHP produca un utile avviso.

7. Il segno `$` mancante davanti ai nomi delle variabili

   [Le variabili in PHP[7] sono rappresentate da un segno di dollaro seguito dal nome della variabile. Il segno del dollaro (`$`) è un [sigillo][8] che contrassegna l'identificatore come nome di una variabile. Senza questo sigillo, l'identificatore potrebbe essere una [parola chiave della lingua][9] o una [costante][10]. Questo è un errore comune quando il codice PHP è stato ["tradotto" da codice scritto in un altro linguaggio][11] (C, Java, JavaScript, ecc.). In questi casi, una dichiarazione del tipo di variabile (quando il codice originale era scritto in un linguaggio che usa variabili tipizzate) potrebbe anche sgattaiolare via e produrre questo errore.
8. Virgolette sfuggite

   /h3> Se usi quote' in una stringa, ha un significato speciale. Questo è chiamato un "[carattere di escape][12]" e normalmente dice al parser di prendere il carattere successivo alla lettera. Esempio:echo 'Jim ha detto 'Ciao'';stamperàJim ha detto 'ciao' Se si esegue l'escape delle virgolette di chiusura di una stringa, le virgolette di chiusura saranno prese alla lettera e non come previsto, cioè come una citazione stampabile come parte della stringa e non come chiusura della stringa. Questo verrà mostrato come un errore di parsing comunemente dopo aver aperto la stringa successiva o alla fine dello script. Errore molto comune quando si specificano i percorsi in Windows:"C:xampp\htdocs\"è sbagliato. Hai bisogno di"C:\xampp\htdocs`"`.