Nessuna causa visibile per "Token imprevisto ILLEGAL"

Ricevo questo errore JavaScript sulla mia console:

Uncaught SyntaxError: token imprevisto ILLEGAL

Questo è il mio codice:

var foo = 'bar';​

È super semplice, come puoi vedere. Come potrebbe causare un errore di sintassi?

L'errore

Quando il codice viene analizzato dall'interprete JavaScript, viene suddiviso in pezzi chiamati "token". Quando un token non può essere classificato in uno dei quattro tipi di token di base , viene etichettato "ILLEGAL" sulla maggior parte delle implementazioni e questo errore viene generato.

Lo stesso errore viene generato se, ad esempio, si tenta di eseguire un file js con un @carattere canaglia , una parentesi graffa posizionata male, una parentesi, "virgolette intelligenti", virgolette singole non racchiuse correttamente (ad esempio this.run('dev1)) e così via.

Molte diverse situazioni possono causare questo errore. Ma se non hai alcun evidente errore di sintassi o carattere illegale, potrebbe essere causato da un personaggio illegale invisibile . Questa è la risposta.

Ma non vedo nulla di illegale!

C'è un carattere invisibile nel codice, subito dopo il punto e virgola. È il carattere Unicode U+200Ba larghezza zero (aka ZWSP, entità HTML ​). Quel personaggio è noto per causare ilUnexpected token ILLEGAL errore di sintassi JavaScript.

E da dove viene?

Non posso dirlo con certezza, ma la mia scommessa è su jsfiddle . Se si incolla il codice da lì, è molto probabile che includa uno o più U+200Bcaratteri. Sembra che lo strumento usi quel carattere per controllare il ritorno a capo delle parole su lunghe stringhe.

AGGIORNAMENTO 2013-01-07

Dopo l'ultimo aggiornamento di jsfiddle , ora mostra il personaggio come un punto rosso come fa Codepen. Apparentemente , inoltre, non sta più inserendo i U+200Bcaratteri da solo, quindi questo problema dovrebbe essere meno frequente da ora in poi.

AGGIORNAMENTO 2015-03-17

Vagrant sembra talvolta causare anche questo problema, a causa di un bug in VirtualBox . La soluzione, come in questo post del blog, è quella di impostare la sendfile off;tua configurazione nginx o EnableSendfile Offse usi Apache.

È stato anche riportato che il codice incollato dagli strumenti di sviluppo di Chrome potrebbe includere quel personaggio, ma non sono stato in grado di riprodurlo con la versione corrente (22.0.1229.79 su OSX).

Come posso individuarlo?

Il personaggio è invisibile, come facciamo a sapere che è lì? Puoi chiedere al tuo editor di mostrare caratteri invisibili. La maggior parte degli editor di testo ha questa funzione. Vim, ad esempio, li visualizza per impostazione predefinita e gli ZWSPspettacoli come <u200b>. Puoi anche eseguirne il debug online: jsbin visualizza il carattere come un punto rosso nei riquadri del codice (ma sembra rimuoverlo dopo aver salvato e ricaricato la pagina). CodePen.io lo visualizza anche come punto e lo mantiene anche dopo il salvataggio.

Problemi correlati

Quel personaggio non è qualcosa di brutto, in realtà può essere abbastanza utile. Questo esempio su Wikipedia dimostra come può essere usato per controllare dove una lunga stringa dovrebbe essere spostata alla riga successiva. Tuttavia, se non sei a conoscenza della presenza del personaggio nel tuo markup, potrebbe diventare un problema. Se lo hai all'interno di una stringa (ad esempio, l' nodeValueelemento di un elemento DOM che non ha contenuto visibile), potresti aspettarti che tale stringa sia vuota, quando in realtà non lo è (anche dopo l'applicazione String.trim).

ZWSPpuò anche far sì che spazi bianchi extra vengano visualizzati su una pagina HTML, ad esempio quando si trova tra due <div>elementi (come si vede in questa domanda ). Questo caso non è nemmeno riproducibile su jsfiddle, poiché il personaggio è ignorato lì.

Un altro potenziale problema: se la codifica della pagina Web non viene riconosciuta come UTF-8, il personaggio potrebbe effettivamente essere visualizzato (come ​ in latino1, ad esempio).

Se ZWSPè presente sul codice CSS (codice incorporato o un foglio di stile esterno), gli stili non possono essere analizzati correttamente, quindi alcuni stili non vengono applicati (come visto in questa domanda ).

La specifica ECMAScript

Non sono riuscito a trovare alcun riferimento a quel personaggio specifico nella specifica ECMAScript (versioni 3 e 5.1 ). La versione attuale menziona caratteri simili ( U+200Ce U+200D) nella Sezione 7.1 , in cui si dice che dovrebbero essere trattati come IdentifierPart"quando fuori dai commenti, dai letterali delle stringhe e dai letterali delle espressioni regolari". Quei personaggi possono, ad esempio, far parte di un nome di variabile (evar x\u200c; effetti funziona).

La Sezione 7.2 elenca i caratteri validi dello spazio bianco (come tab, spazio, spazio senza interruzioni, ecc.) E menziona vagamente che qualsiasi altro "separatore di spazi" Unicode (categoria "Z") deve essere trattato come spazio bianco. Probabilmente non sono la persona migliore per discutere le specifiche a questo proposito, ma mi sembra che U+200Bdovrebbe essere considerato uno spazio bianco in base a ciò, quando in realtà le implementazioni (almeno Chrome e Firefox) sembrano trattarle come un imprevisto token (o parte di uno), causando l'errore di sintassi.

perché stai cercando questo problema nel tuo codice? Anche, se è copypasted.

Se riesci a vedere cosa succede esattamente dopo aver salvato il file nella cartella sincronizzata, vedrai qualcosa di simile *****alla fine del file. Non è affatto correlato al tuo codice.

Soluzione.

Se si utilizza nginxnella casella vagabondo, aggiungere alla configurazione del server:

sendfile off;

Se si utilizza apachenella casella vagabondo, aggiungere alla configurazione del server:

EnableSendfile Off;

Fonte del problema: VirtualBox Bug

Questo potrebbe accadere anche se stai copiando il codice da un altro documento (come un PDF) nella tua console e stai provando a eseguirlo.

Stavo cercando di eseguire alcuni esempi di codice da un libro Javascript che sto leggendo e sono rimasto sorpreso dal fatto che non sia stato eseguito nella console.

Apparentemente, la copia dal PDF introduce nel codice alcuni caratteri inattesi, illegali e invisibili.

Ho avuto lo stesso problema sul mio mac e ho scoperto che era perché il Mac stava sostituendo le virgolette standard con virgolette ricci che sono caratteri javascript illegali.

Per risolvere questo problema, ho dovuto modificare le impostazioni sul mio mac Preferenze di Sistema => Tastiera => Testo (scheda) deselezionare Usa virgolette e trattini intelligenti (impostazione predefinita selezionata).

Ho riscontrato questo errore in Chrome quando avevo una stringa non terminata dopo la riga indicata dall'errore. Dopo aver chiuso la stringa l'errore è scomparso.

Esempio con errore:

var file = files[i]; // SyntaxError: Unexpected token ILLEGAL

jQuery('#someDiv').innerHTML = file.name + " (" + formatSize(file.size) + ") "
    + "<a href=\"javascript: something('"+file.id+');\">Error is here</a>";

Esempio senza errore:

var file = files[i]; // No error

jQuery('#someDiv').innerHTML = file.name + " (" + formatSize(file.size) + ") "
    + "<a href=\"javascript: something('"+file.id+"');\">Error was here</a>";

Se stai eseguendo un vagrant di installazione nginx + uwsgi, il problema principale è il bug della scatola virtuale con file di invio, come menzionato in alcune delle risposte. Tuttavia per risolverlo devi disabilitare sendfile sia in nginx che in uwsgi.

1. In nginx.conf sendfile off

2. uwsgi application / config --disable-sendfile

Quando si esegue OS X, il filesystem crea fork nascosti praticamente di tutti i file, se si trovano su un disco rigido che non supporta HFS +. Questo a volte (a me è successo proprio ora) può far sì che il tuo motore JavaScript tenti di eseguire il fork dei dati anziché il codice che intendi eseguire. Quando ciò accade, riceverai anche

SyntaxError: Unexpected token ILLEGAL

perché il fork di dati del file conterrà il carattere Unicode U + 200B. La rimozione del file fork dei dati farà eseguire allo script il codice effettivo e previsto, anziché un fork di dati binari del codice.

. comunque: questi file vengono creati su volumi che non supportano in modo nativo le caratteristiche complete dei file HFS (ad es. volumi ufs, condivisioni file di Windows, ecc.). Quando un file Mac viene copiato su tale volume, il suo fork di dati viene archiviato con il nome normale del file e le informazioni HFS aggiuntive (fork di risorse, tipo e codici creatore, ecc.) Vengono archiviate in un secondo file (in formato AppleDouble), con un nome che inizia con ". ". (Questi file sono, ovviamente, invisibili per quanto riguarda OS-X, ma non per altri SO; questo a volte può essere fastidioso ...)

• Gordon Davisson @ http://www.westwind.com/reference/OS-X/invisibles.html

Ecco la mia ragione:

prima:

var path = "D:\xxx\util.s"

che \uè una via di fuga, l'ho capito usando Codepen l'analisi JS di .

dopo:

var path = "D:\\xxx\\util.s"

e l'errore corretto

Ho avuto lo stesso problema e si è verificato perché avevo premuto il tasto Invio durante l'aggiunta di codice in una stringa di testo.

Poiché era una lunga stringa di testo, volevo vedere tutto senza dover scorrere il mio editor di testo, tuttavia premere Invio ha aggiunto un carattere invisibile alla stringa che era illegale. Stavo usando Sublime Text come editor.

Ho cambiato tutte le aree dello spazio in & nbsp, proprio così e ha funzionato senza problemi.

val.replace ("", "& nbsp");

Spero che aiuti qualcuno.

Ho intenzione di aggiungere un'altra risposta alla pila. Questo problema potrebbe verificarsi anche a causa della codifica. Vuoi che la codifica utf8 sia sicura. Alcuni editor usano di default utf16 che può causare problemi. Un modo rapido per testarlo, ad esempio nel codice VS, è semplicemente ricreare lo stesso contenuto ma utilizzare l'editor locale di vscode per creare il file. Spero che questo aiuti alcuni.