Il n’y a pas de cause visible pour le « jeton inattendu illégal »

erreur

lorsque l’interpréteur JavaScript analyse le code, il est divisé en parties « jetons ». Lorsqu’un jeton ne peut pas être classé dans l’un des quatre types de jetons de base, il est « illégal » dans la plupart des implémentations, et cette erreur est générée.

La même erreur est générée si, par exemple, essayez, Exécuter un fichier JS avec un caractère malhonnête, un mauvais endroit, des parenthèses, des « citations intelligentes », des citations simples non incluses correctement (par exemple this.run('dev1)), etc.

De nombreuses situations peuvent causer cette erreur. Mais si vous n’avez pas d’erreurs de syntaxe évidentes ni de caractère illégal, cela peut être causé par un caractère illégal invisible. C’est à propos de cette réponse.

mais je ne peux pas voir quoi que ce soit illégal!

Il y a un caractère invisible dans le code, juste après le point et le coma. Est le caractère d’espace unicode large large (également appelé ZWSP entité HTML ​) . On sait que ce caractère provoque l’erreur Unexpected token ILLEGAL Erreur de syntaxe JavaScript.

et d’où vient-il?

Je ne peux pas dire avec certitude mais mon pari est sur jsfiddle. Si vous collez le code à partir de là, il est très probable que vous incluiez une ou plusieurs U+200B caractères. Il semble que l’outil utilise ce caractère pour contrôler le réglage des mots dans des chaînes longues.

Mise à jour 2013-01-07

À partir de la dernière mise à jour Jsfiddle, montre maintenant le personnage comme point rouge que Codepen. Apparemment, il ne fait plus d’insérer U+200B caractères, ce problème devrait donc être moins fréquent à partir de maintenant.

Mise à jour 2015-03-17

Vagabond semble parfois causer ce problème aussi, en raison d’une erreur dans VirtualBox. Selon ce blog, la solution est de définir sendfile off; dans sa configuration NGinx, ou EnableSendfile Off si vous utilisez Apache.

Il a également été signalé que le code bloqué des outils de développeur chromé peut inclure ce caractère, mais je ne pouvais pas le reproduire avec la version actuelle (22.0.1229.79 dans OSX) .

Comment puis-je le détecter?

Le personnage est invisible, comment savons-nous ce qui existe? Vous pouvez demander à votre éditeur d’afficher des caractères invisibles. La plupart des éditeurs de texte ont cette fonctionnalité. Vim, par exemple, les montre par défaut et le ZWSP Affiche comme <u200b>. Vous pouvez également le déboguer en ligne: JSBIN montre le caractère en tant que point rouge sur vos panneaux de code (mais il semble le supprimer après avoir enregistré et rechargé la page). CodePen.io le montre aussi comme un point et le garde même après l’avoir sauvé.

Problèmes connexes

Ce caractère n’est pas une mauvaise chose, cela peut en réalité être très utile. Cet exemple dans Wikipedia montre comment il peut être utilisé pour contrôler où une longue chaîne doit être ajustée à la ligne suivante. Cependant, si vous ne connaissez pas la présence du personnage de votre marquage, vous pouvez devenir un problème. Si vous l’avez à l’intérieur d’une chaîne (par exemple, l’ID

d’un élément DOM qui n’a pas de contenu visible), vous pouvez vous attendre à ce que la chaîne soit vide, quand ce n’est pas (même Après avoir postulé String.trim).

ZWSP peut également être affiché d’espace vide dans une page HTML, par exemple , quand il est entre deux <div> éléments (comme on le voit dans cette question). Ce cas n’est même pas reproductible dans Jsfiddle, car le caractère est ignoré là-bas.

Un autre problème potentiel: Si le codage du site Web n’est pas reconnu comme UTF-8, le caractère peut être affiché (comme ​ en latin1, par exemple).

si ZWSP est présent dans le code CSS (code en ligne ou un style externe ou un style externe feuille), les styles ne peuvent pas être correctement analysés non plus non plus, certains styles ne s’appliquent pas (comme on le voit dans cette question).

Spécification ECMAScript

Je ne peux trouver aucune mention à ce spécifique Caractère dans la spécification Ecmascript (versions 3 et 5.1). La version actuelle mentionne des caractères similaires ( et U+200D) dans la section 7.1, qui dit qu’ils devraient être traités comme IdentifierPart s quand » en dehors des commentaires, des littéraux en chaîne et des littéraux d’expression réguliers « . Ces caractères peuvent, par exemple, faire partie d’un nom de variable (et de var x\u200c; Fonctions de fait).

Section 7.2 répertorie les caractères d’espace vierge valides (tels que la tabulation, l’espace, l’espace sans interruption, etc.) et mentionne vaguement que tout autre séparateur d’espace Unicode (catégorie « ZS ») doit être traité comme un espace vide. Je ne suis probablement pas la meilleure personne à discuter des spécifications à cet égard, mais il me semble que U+200B devrait être considéré comme un espace vide selon cela, en réalité les implémentations (à Le moins chrome et firefox) semblent traiter comme quelque chose de jeton inattendu (ou d’une partie de l’une), qui provoque l’erreur de syntaxe.