Nessuna causa visibile per “Token inaspettato ILLEGAL”

Sto ottenendo 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 syntax?

L’errore

Quando il codice viene analizzato dall’interprete JavaScript, viene suddiviso in parti chiamate “token”. Quando un token non può essere classificato in uno dei quattro tipi di token di base , viene etichettato come “ILLEGAL” sulla maggior parte delle implementazioni e viene generato questo errore.

Lo stesso errore viene sollevato se, ad esempio, si tenta di eseguire un file js con un carattere rogue @ , parentesi graffa, parentesi graffa, “virgolette” this.run('dev1) , virgolette singole non racchiuse correttamente (ad es. this.run('dev1) ) e così via.

Molte situazioni diverse possono causare questo errore. Ma se non si hanno evidenti errori di syntax o caratteri illegali, potrebbe essere causato da un carattere illegale invisibile . Questo è ciò di cui tratta questa risposta.

Ma non riesco a vedere nulla di illegale!

C’è un carattere invisibile nel codice, subito dopo il punto e virgola. È il carattere Unicode U+200B a larghezza zero (noto ZWSP come ZWSP , HTML entity ). È noto che tale carattere causa l’errore di syntax JavaScript Unexpected token ILLEGAL .

E da dove viene?

Non posso dirlo con certezza, ma la mia scommessa è su jsfiddle . Se incolli il codice da lì, è molto probabile che includa uno o più caratteri U+200B . Sembra che lo strumento usi quel personaggio per controllare il wrapping delle parole su stringhe lunghe.

AGGIORNAMENTO 2013-01-07

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

AGGIORNAMENTO 2015-03-17

Vagrant sembra a volte causare questo problema, a causa di un bug in VirtualBox . La soluzione, come per questo post del blog è di impostare sendfile off; nella tua configurazione di nginx, o EnableSendfile Off se usi Apache.

È stato anche segnalato che il codice incollato dagli strumenti per sviluppatori di Chrome potrebbe includere quel carattere, ma non è stato ansible 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 personaggi invisibili. La maggior parte degli editor di testo ha questa caratteristica. Ad esempio, Vim li visualizza per impostazione predefinita e ZWSP visualizzato come ZWSP . Puoi anche eseguirne il debug online: jsbin visualizza il carattere come un punto rosso sui relativi riquadri di codice (ma sembra rimuoverlo dopo aver salvato e ricaricato la pagina). CodePen.io lo visualizza anche come un punto e lo mantiene anche dopo il salvataggio.

Problemi correlati

Quel personaggio non è qualcosa di brutto, può essere piuttosto utile. Questo esempio su Wikipedia dimostra come può essere usato per controllare dove una lunga stringa deve essere incapsulata nella riga successiva. Tuttavia, se non si è a conoscenza della presenza del personaggio sul markup, potrebbe diventare un problema. Se lo si ha all’interno di una stringa (ad esempio, il valore nodeValue di un elemento DOM che non ha alcun contenuto visibile), ci si potrebbe aspettare che tale stringa sia vuota, quando in realtà non lo è (anche dopo l’applicazione di String.trim ).

ZWSP può anche causare spazi bianchi extra da visualizzare su una pagina HTML, ad esempio quando si trova tra due 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 essere effettivamente visualizzato (come in latino1, ad esempio).

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

La specifica ECMAScript

Non sono riuscito a trovare alcun riferimento a quel carattere specifico nella specifica ECMAScript (versioni 3 e 5.1 ). La versione corrente menziona caratteri simili ( U+200C e U+200D ) nella Sezione 7.1 , che dice che dovrebbero essere trattati come IdentifierPart quando “al di fuori di commenti, stringhe letterali e letterali di espressioni regolari”. Questi personaggi possono, ad esempio, essere parte di un nome di variabile (e var x\u200c; effetti funziona).

La Sezione 7.2 elenca i caratteri dello spazio bianco validi (come tab, spazio, spazio senza interruzione, ecc.) E accenna vagamente che qualsiasi altro “spazio separatore” Unicode (categoria “Zs”) dovrebbe essere trattato come spazio bianco. Probabilmente non sono la persona migliore per discutere le specifiche al riguardo, ma mi sembra che U+200B debba essere considerato spazio bianco in base a ciò, quando in effetti le implementazioni (almeno Chrome e Firefox) sembrano trattarle come token imprevisto (o parte di uno), causando l’errore di syntax.

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 a ***** alla fine del file. Non è affatto correlato al tuo codice.

Soluzione.

Se stai usando nginx nella casella vagrant – aggiungi alla configurazione del server:

 sendfile off; 

Se si utilizza apache nella casella vagrant – aggiungere alla configurazione del server:

 EnableSendfile Off; 

Fonte del problema: VirtualBox Bug

Questo potrebbe anche accadere se copi codice da un altro documento (come un PDF) nella tua console e provi ad eseguirlo.

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

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

Ho avuto questo errore in chrome quando ho avuto una stringa non terminata dopo la riga che l’errore ha indicato. Dopo aver chiuso la stringa, l’errore è andato via.

Esempio con errore:

 var file = files[i]; // SyntaxError: Unexpected token ILLEGAL jQuery('#someDiv').innerHTML = file.name + " (" + formatSize(file.size) + ") " + "Error is here"; 

Esempio senza errore:

 var file = files[i]; // No error jQuery('#someDiv').innerHTML = file.name + " (" + formatSize(file.size) + ") " + "Error was here"; 

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 (l’impostazione predefinita era selezionata).

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

  1. Nel file send di nginx.conf distriggersto

  2. uwsgi application / config –disable-sendfile

Quando si esegue OS X, il filesystem crea forchette nascoste di praticamente tutti i file, se si trovano su un disco rigido che non supporta HFS +. Questo può a volte (mi è successo proprio ora) portare il tuo motore JavaScript a provare a lanciare il data-fork invece del codice che intendi far girare. Quando ciò accade, riceverai anche

 SyntaxError: Unexpected token ILLEGAL 

perché il data fork del tuo file conterrà il carattere Unicode U + 200B. La rimozione del file di dati fork farà sì che lo script esegua il codice effettivo e previsto anziché un binario dati binario del codice.

. qualunque cosa: questi file sono creati su volumi che non supportano nativamente le caratteristiche complete del file HFS (es. volumi ufs, file condivisi di Windows, ecc.). Quando un file Mac viene copiato in tale volume, il suo fork di dati viene memorizzato sotto il nome normale del file e le informazioni HFS aggiuntive (fork delle risorse, codici di tipo e creatore, ecc.) Sono archiviati 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 sistemi operativi, questo a volte può essere noioso …)

Ho avuto lo stesso problema e si è verificato perché avevo premuto il tasto Invio quando aggiungo il codice in una stringa di testo.

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

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

val.replace (“”, “& nbsp”);

Spero che aiuti qualcuno.

Ecco la mia ragione:

prima:

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

che è una via di fuga, l’ho capito usando l’analisi JS di Codepen .

dopo:

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

e l’errore risolto