Tutti si imbattono in errori di sintassi. Anche i programmatori esperti fanno errori di battitura. Per i nuovi arrivati, è solo parte del processo di apprendimento. Tuttavia, è spesso facile interpretare i messaggi di errore come: PHP Parse error: syntax error, unexpected '{' in index.php sulla linea 20 Il simbolo inatteso non è sempre il vero colpevole. Ma il numero di linea dà un'idea approssimativa di dove iniziare a cercare. Guardate sempre il contesto del codice. L'errore di sintassi spesso si nasconde nel citato o in linee di codice precedenti. Confrontate il vostro codice con gli esempi di sintassi del manuale. Anche se non tutti i casi corrispondono agli altri. Tuttavia ci sono alcuni passi generali per risolvere gli errori di sintassi. Questi riferimenti hanno riassunto le insidie comuni:
{
}``<br>Unexpected
(<br>Unexpected
)`[
]
]](https://stackoverflow.com/a/29505827)<
>
\
' (ASCII=92) state=1,
(virgola)
.
(punto)
;
(punto e virgola)*
(asterisco):
(due punti)
Riferimenti strettamente correlati:""
intelligenti ''
virgolette non significano nulla in PHP
E:Errori di sintassi generati dal codice del fornitore: Infine, considerate che se l'errore di sintassi non è stato generato modificando la vostra base di codice, ma dopo l'installazione o l'aggiornamento di un pacchetto di un fornitore esterno, potrebbe essere dovuto all'incompatibilità della versione di PHP, quindi controllate i requisiti del fornitore rispetto alla configurazione della vostra piattaforma.
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.
Ci sono alcune precauzioni di base che puoi sempre prendere:
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.
Ci sono molti approcci per restringere e risolvere gli errori di sintassi.
;
alla fine della linea/stato precedente. (Almeno dal punto di vista stilistico. ){
}` 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.+-*/.
dovrebbero essere colorati separatamente. Altrimenti potrebbero essere nel contesto sbagliato."
o '
di chiusura mancante.++
, --
, o parentesi che seguono un operatore. Due stringhe/identificatori che si seguono direttamente sono scorretti nella maggior parte dei contesti.if
in condizioni if
distinte o annidate.? :
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.if:
/elseif:
/endif;
) è comune per i template, ma probabilmente meno facile da seguire dei normali blocchi di {
codice }
.;
per terminare le dichiarazioni/linee."
o '
e virgolette non catturate all'interno..
.(
parentesi )
. Contatele nella riga riportata. Ce ne sono un numero uguale?diff
della versione rotta e dell'ultima versione funzionante. Il che potrebbe essere illuminante su quale sia il problema di sintassi.
br/>grep --color -P -n "\x80-\xFF\]" file.php
]9 come prima misura per trovare simboli non-ASCII.//
o #
. I commenti multilinea /*...*/
raramente disturbano il parser quando le interruzioni di riga vengono ignorate.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.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, diciamo
test.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.
Un "unexpected T_VARIABLE
" significa che c'è un nome letterale di $variabile
, che non si adatta alla struttura dell'espressione/stato corrente.
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
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 è.
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.
Liste
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
.
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.
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.
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.
⇓
else ($var >= 0)
Soluzione: Rimuovi le condizioni da else
o usa elseif
.
⇓
function() usa $var {}
Soluzione: Aggiungi le parentesi attorno a $var
.
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.
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.
"
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."
.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."
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."these
viene interpretato come un identificatore costante. Ma qualsiasi letterale di testo che segue è visto come una bareword/T_STRING dal parser.||
o l'altra.<?xml
intestazioni negli script PHP;
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.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`"`.