“Unexpected token ILLEGAL”没有明显原因。 [英] No visible cause for "Unexpected token ILLEGAL"

问题描述

我在我的控制台上收到此JavaScript错误：

I'm getting this JavaScript error on my console:

未捕获的SyntaxError：意外的令牌ILLEGAL

Uncaught SyntaxError: Unexpected token ILLEGAL

这是我的代码：

var foo = 'bar';​

如你所见，它非常简单。怎么会导致语法错误？

It's super simple, as you can see. How could it be causing a syntax error?

推荐答案

错误

当JavaScript解释器解析代码时，它会被分解为称为令牌的片段。如果令牌无法归入四种基本令牌类型之一，则会将其标记为ILLEGAL 在大多数实现中，抛出此错误。

The error

When code is parsed by the JavaScript interpreter, it gets broken into pieces called "tokens". When a token cannot be classified into one of the four basic token types, it gets labelled "ILLEGAL" on most implementations, and this error is thrown.

例如，如果您尝试使用流氓 @ 字符运行js文件，则会引发相同的错误，错误的花括号，括号，智能引号，单引号未正确封闭（例如 this.run（'dev1））等等。

The same error is raised if, for example, you try to run a js file with a rogue @ character, a misplaced curly brace, bracket, "smart quotes", single quotes not enclosed properly (e.g. this.run('dev1)) and so on.

许多不同的情况都可能导致此错误。但是，如果您没有任何明显的语法错误或非法字符，则可能是由不可见非法字符引起的。这就是答案。

A lot of different situations can cause this error. But if you don't have any obvious syntax error or illegal character, it may be caused by an invisible illegal character. That's what this answer is about.

但我看不出任何违法行为！

在分号后面的代码中有一个不可见的字符。这是 Unicode U + 200B 零宽度空间字符（又名 ZWSP ，HTML实体&＃8203; ）。已知该字符会导致意外令牌ILLEGAL JavaScript语法错误。

But I can't see anything illegal!

There is an invisible character in the code, right after the semicolon. It's the Unicode U+200B Zero-width space character (a.k.a. ZWSP, HTML entity ​). That character is known to cause the Unexpected token ILLEGAL JavaScript syntax error.

我无法确定，但我的赌注是 jsfiddle 。如果您从那里粘贴代码，则很可能包含一个或多个 U + 200B 个字符。似乎该工具使用该字符来控制长字符串上的自动换行。

I can't tell for sure, but my bet is on jsfiddle. If you paste code from there, it's very likely to include one or more U+200B characters. It seems the tool uses that character to control word-wrapping on long strings.

UPDATE 2013-01-07

在最新的 jsfiddle update之后，它现在将字符显示为红点，就像codepen一样。 显然，它也不再单独插入 U + 200B 字符，所以从现在开始这个问题应该不那么频繁了。

After the latest jsfiddle update, it's now showing the character as a red dot like codepen does. Apparently, it's also not inserting U+200B characters on its own anymore, so this problem should be less frequent from now on.

更新2015-03-17

Vagrant 有时会出现由于 VirtualBox 中的错误，也会导致此问题。解决方案，按照这篇博客文章是在你的nginx配置中设置 sendfile; ，或者如果你在 EnableSendfile Off 使用Apache。

Vagrant appears to sometimes cause this issue as well, due to a bug in VirtualBox. The solution, as per this blog post is to set sendfile off; in your nginx config, or EnableSendfile Off if you use Apache.

它也被报道从Chrome开发人员工具粘贴的代码可能包含该字符，但我无法使用当前版本（OSX上的22.0.1229.79）重现该代码。

It's also been reported that code pasted from the Chrome developer tools may include that character, but I was unable to reproduce that with the current version (22.0.1229.79 on OSX).

这个角色是看不见的，我们怎么知道它在那里？您可以要求编辑显示隐形字符。大多数文本编辑器都具有此功能。例如，Vim默认显示它们， ZWSP 显示为< u200b> 。您也可以在线调试： jsbin 在其代码窗格中将字符显示为红点（但似乎在删除之后将其删除保存并重新加载页面）。 CodePen.io也将其显示为点，并在保存后保留。

The character is invisible, do how do we know it's there? You can ask your editor to show invisible characters. Most text editors have this feature. Vim, for example, displays them by default, and the ZWSP shows as <u200b>. You can also debug it online: jsbin displays the character as a red dot on its code panes (but seems to remove it after saving and reloading the page). CodePen.io also displays it as a dot, and keeps it even after saving.

这个角色不是坏事，它实际上非常有用。 维基百科上的这个示例演示了如何使用它来控制长字符串的包装位置到下一行。但是，如果您不知道角色在您的标记上的存在，它可能会成为一个问题。如果你有一个字符串（例如，没有可见内容的DOM元素的 nodeValue ），你可能希望这样的字符串是空的，实际上它是不（甚至在应用 String.trim 之后）。

That character is not something bad, it can actually be quite useful. This example on Wikipedia demonstrates how it can be used to control where a long string should be wrapped to the next line. However, if you are unaware of the character's presence on your markup, it may become a problem. If you have it inside of a string (e.g., the nodeValue of a DOM element that has no visible content), you might expect such string to be empty, when in fact it's not (even after applying String.trim).

ZWSP 还会导致在HTML页面上显示额外的空格，例如当它在两个页面之间找到​​时code>< div> 元素（如此问题所示）。这个案例甚至不能在jsfiddle上重现，因为那里的字符被忽略了。

ZWSP can also cause extra whitespace to be displayed on an HTML page, for example when it's found between two <div> elements (as seen on this question). This case is not even reproducible on jsfiddle, since the character is ignored there.

另一个潜在的问题：如果网页的编码不被识别为UTF-8，那么角色实际上可以显示（例如，在latin1中为 - / code>）。

Another potential problem: if the web page's encoding is not recognized as UTF-8, the character may actually be displayed (as ​ in latin1, for example).

如果 ZWSP 出现在CSS代码（内联代码或外部样式表）上，样式也无法正确解析，因此某些样式不会被应用（如这个问题）。

If ZWSP is present on CSS code (inline code, or an external stylesheet), styles can also not be parsed properly, so some styles don't get applied (as seen on this question).

我在ECMAScript规范中找不到任何关于该特定字符的提及（版本 3 和 5.1 ）。当前版本在 U + 200C 和 U + 200D ） /ecma-international.org/ecma-262/5.1/#sec-7.1\"rel =noreferrer>第7.1节，表示它们应被视为 IdentifierPart 当在注释，字符串文字和正则表达式文字之外时。例如，这些字符可能是变量名称的一部分（ var x \ u200c; 确实有效）。

I couldn't find any mention to that specific character on the ECMAScript Specification (versions 3 and 5.1). The current version mentions similar characters (U+200C and U+200D) on Section 7.1, which says they should be treated as IdentifierParts when "outside of comments, string literals, and regular expression literals". Those characters may, for example, be part of a variable name (and var x\u200c; indeed works).

第7.2节列出有效的空白字符（例如制表符，空格，不间断空格等），并且模糊地提到任何其他Unicode空格分隔符（类别Zs）应该被视为空格。我可能不是讨论这方面规格的最佳人选，但在我看来， U + 200B 应该被视为白色空间，实际上实现（至少Chrome和Firefox）似乎将它们视为意外的令牌（或其中一部分），导致语法错误。

Section 7.2 lists the valid White space characters (such as tab, space, no-break space, etc.), and vaguely mentions that any other Unicode "space separator" (category "Zs") should be treated as white space. I'm probably not the best person to discuss the specs in this regard, but it seems to me that U+200B should be considered white space according to that, when in fact the implementations (at least Chrome and Firefox) appear to treat them as an unexpected token (or part of one), causing the syntax error.

这篇关于“Unexpected token ILLEGAL”没有明显原因。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！