Geen zichtbare oorzaak voor “Onverwachte token ILLEGAAL”

var foo = 'bar';​

Antwoord 1, autoriteit 100%

De fout

Wanneer code wordt geparseerd door de JavaScript-interpreter, wordt deze opgesplitst in stukjes die ‘tokens’ worden genoemd. Wanneer een token niet kan worden geclassificeerd in een van de vier basistokentypen, krijgt het het label “ILLEGAAL ” bij de meeste implementaties, en deze fout wordt gegenereerd.

Dezelfde fout treedt op als u bijvoorbeeld een js-bestand probeert uit te voeren met een bedrieglijk @-teken, een verkeerd geplaatste accolade, haakjes, “slimme aanhalingstekens”, enkele aanhalingstekens die niet correct zijn ingesloten (bijv. this.run('dev1)) enzovoort.

Veel verschillende situaties kunnen deze fout veroorzaken. Maar als je geen duidelijke syntaxisfout of illegaal teken hebt, kan dit worden veroorzaakt door een onzichtbaarillegaal teken. Daar gaat dit antwoord over.

Maar ik kan niets illegaals zien!

Er staat een onzichtbaar teken in de code, direct na de puntkomma. Het is de Unicode U+200Bnulbreedte-ruimte -teken (ook bekend als ZWSP, HTML-entiteit ​). Van dat teken is bekend dat het de JavaScript-syntaxisfout Unexpected token ILLEGALveroorzaakt.

En waar komt het vandaan?

Ik weet het niet zeker, maar ik gok op jsfiddle. Als je daar code plakt, bevat deze zeer waarschijnlijk een of meer U+200B-tekens. Het lijkt erop dat de tool dat teken gebruikt om woordterugloop op lange strings te controleren.

UPDATE 07-01-2013

Na de laatste jsfiddle-update, het toont nu het teken als een rode stipzoals codepen doet. Blijkbaarvoegt het ook geen zelfstandig meer tekens van U+200Bin, dus dit probleem zou vanaf nu minder frequent moeten zijn.

UPDATE 17-03-2015

Vagrantlijkt dit probleem soms ook te veroorzaken, vanwege een bug in VirtualBox. De oplossing, volgens deze blogpostis om sendfile off;in je nginx-configuratie, of EnableSendfile Offals je Apache gebruikt.

Er is ook gemelddat code die is geplakt vanuit de Chrome-ontwikkelaarstools dat teken kan bevatten, maar ik kon het niet reproduceren dat met de huidige versie (22.0.1229.79 op OSX).

Hoe kan ik het herkennen?

Het personage is onzichtbaar, hoe weten we dat het er is? U kunt uw redacteur vragen om onzichtbare tekens weer te geven. De meeste teksteditors hebben deze functie. Vim geeft ze bijvoorbeeld standaard weer, en de ZWSPtoont als <u200b>. Je kunt het ook online debuggen: jsbingeeft het teken weer als een rode stip in de codevensters (maar lijkt het te verwijderen na opslaan en opnieuw laden van de pagina). CodePen.io geeft het ook weer als een punten bewaart het zelfs na het opslaan.

Verwante problemen

Dat karakter is niet iets slechts, het kan zelfs heel nuttig zijn. Dit voorbeeld op Wikipedialaat zien hoe het kan worden gebruikt om te bepalen waar een lange string moet worden ingepakt naar de volgende regel. Als u zich echter niet bewust bent van de aanwezigheid van het personage in uw opmaak, kan dit een probleem worden. Als je het in een tekenreeks hebt (bijv. de nodeValuevan een DOM-element dat geen zichtbare inhoud heeft), zou je kunnen verwachten dat zo’n tekenreeks leeg is, terwijl dat in feite niet zo is (zelfs na het toepassen van String.trim).

ZWSPkan er ook voor zorgen dat er extra witruimte wordt weergegeven op een HTML-pagina, bijvoorbeeld wanneer deze wordt gevonden tussen twee <div>-elementen (zoals te zien op deze vraag). Dit geval is zelfs niet reproduceerbaar op jsfiddle, omdat het karakter daar wordt genegeerd.

Een ander potentieel probleem: als de codering van de webpagina niet wordt herkend als UTF-8, kan het teken daadwerkelijk worden weergegeven (bijvoorbeeld als ​in latin1, bijvoorbeeld).

Als ZWSPaanwezig is op CSS-code (inline code of een externe stylesheet), kunnen stijlen ook niet goed worden geparseerd, waardoor sommige stijlen niet worden toegepast (zoals te zien op deze vraag).

De ECMAScript-specificatie

Ik kon geen enkele vermelding van dat specifieke teken vinden in de ECMAScript-specificatie (versies 3en 5.1). De huidige versie vermeldt vergelijkbare tekens (U+200Cen U+200D) op Sectie 7.1, waarin staat dat ze moeten worden behandeld als IdentifierParts wanneer “buiten opmerkingen, letterlijke tekenreeksen en letterlijke uitdrukkingen van reguliere expressies”. Die tekens kunnen bijvoorbeeld deel uitmaken van een variabelenaam (en var x\u200c;werkt inderdaad).

Sectie 7.2vermeldt de geldige witruimtetekens (zoals tab, spatie, no-break spatie, enz.), en vermeldt vaag dat elke andere Unicode “spatiescheidingsteken” (categorie “Zs”) moet worden behandeld als witruimte. Ik ben waarschijnlijk niet de beste persoon om de specificaties in dit verband te bespreken, maar het lijkt mij dat U+200Bvolgens dat als witruimte moet worden beschouwd, terwijl in feite de implementaties (tenminste Chrome en Firefox) lijken ze te behandelen als een onverwacht token (of een deel daarvan), wat de syntaxisfout veroorzaakt.

Antwoord 2, autoriteit 13%

waarom zoekt u dit probleem in uw code? Zelfs als het gekopieerd is.

Als u kunt zien, wat er precies gebeurt na het opslaan van bestand in de gesynchroniseerde map – zie je iets als *****aan het einde van het bestand. Het is helemaal niet gerelateerd aan uw code.

oplossing.

Als u nginxin zwervende doos gebruikt – Toevoegen aan serverconfiguratie:

sendfile off;

Als u apacheIn Vagrant Box – Toevoegen aan Server Config:

EnableSendfile Off;

Bron van probleem: virtualbox bug

3

Dit zou ook kunnen gebeuren als u code van een ander document (zoals een pdf) in uw console kopieert en probeert het uit te voeren.

Ik probeerde een aantal voorbeeldcode uit te voeren uit een JavaScript-boek dat ik aan het lezen ben en was verrast dat het niet in de console heeft uitgevoerd.

Blijkbaar introduceert het kopiëren van de PDF enkele onverwachte, illegale en onzichtbare tekens in de code.

4

Ik had hetzelfde probleem op mijn Mac en vond het omdat de Mac de standaardcitaten vervangt met krullende citaten die illegale JavaScript-tekens zijn.

Om dit te verhelpen, moest ik de instellingen wijzigen op mijn Mac System Preferences = & GT; Keyboard = & GT; Tekst (Tabblad) Verwijderen Gebruik Smart Quotes en Streepjes (standaard is gecontroleerd).

5

Ik heb deze fout in Chrome toen ik na de regel een niet-gecodeerde string had waarnaar de fout heeft gewezen. Na het sluiten van de tekenreeks ging de fout weg.

Voorbeeld met fout:

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>";

Voorbeeld zonder fout:

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

Antwoord 6

Als je een nginx + uwsgi setup zwerver gebruikt, dan is het grootste probleem de Virtual box bug met het verzendbestand zoals vermeld in sommige van de antwoorden. Om het op te lossen, moet u sendfile zowel in nginx als uwsgi uitschakelen.

1. In nginx.conf
   verzendbestand uit

2. uwsgi-toepassing / configuratie
   –disable-sendfile

Antwoord 7

Als je OS X draait, creëert het bestandssysteem verborgen forks van in principe al je bestanden, als ze op een harde schijf staan die HFS+ niet ondersteunt. Dit kan er soms (ik is me zojuist overkomen) ertoe leiden dat uw JavaScript-engine de data-fork probeert uit te voeren in plaats van de code die u wilt uitvoeren. Wanneer dit gebeurt, ontvangt u ook

SyntaxError: Unexpected token ILLEGAL

omdat de datafork van uw bestand het Unicode U+200B-teken zal bevatten. Als u het datafork-bestand verwijdert, voert uw script uw eigenlijke, beoogde code uit, in plaats van een binaire datafork van uw code.

. Wat dan ook: deze bestanden worden gemaakt op volumes die niet native volledige HFS-bestandskenmerken ondersteunen (bijvoorbeeld UFS-volumes, Windows FileShirt, enz.). Wanneer een MAC-bestand naar een dergelijk volume wordt gekopieerd, wordt de gegevensvork opgeslagen onder de normale naam van het bestand en de aanvullende HFS-informatie (resource-vork, type & amp; makercodes, enz.) Wordt opgeslagen in een tweede bestand (in AppleCouble Format) , met een naam die begint met “. “. (Deze bestanden zijn natuurlijk onzichtbaar voor OS-X betreft OS-X, maar niet op andere OS; dit kan soms irritant zijn …)

• Gordon Davisson @ http://www.westwind.com/reference/os -X / Invisibles.html

8

Hier is mijn reden:

VÓÓR:

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

Welk \uis een ontsnapping, ik heb het ontdekt door codepen ‘s te gebruiken Analyse JS.

Na:

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

en de fout vaste

9

Ik heb alle ruimtegebieden veranderd naar & amp; nbsp, net als dat en het werkte zonder problemen.

Val.Replace (“”, “& amp; nbsp”);

Ik hoop dat het iemand helpt.

10

Ik ga nog een antwoord aan de stapel toevoegen. Dit probleem kan ook optreden vanwege codering. U wilt dat utf8-codering aan de veilige kant is. Sommige editors gebruiken standaard utf16, wat problemen kan veroorzaken. Een snelle manier om dit te testen is, bijvoorbeeld in VS-code, gewoon dezelfde inhoud opnieuw te maken, maar de lokale editor van vscode te gebruiken om het bestand te maken.
Ik hoop dat dit wat helpt.