'；上的Javascript分析错误\u2028'；unicode字符_Javascript_Unicode

'；上的Javascript分析错误\u2028'；unicode字符

javascript unicode

'；上的Javascript分析错误\u2028'；unicode字符,javascript,unicode,Javascript,Unicode,每当我在javascript源代码中使用内容类型设置为“text/html；charset=utf-8”的\u2028字符文本时，就会出现javascript解析错误例如： <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <meta http-equiv="

每当我在javascript源代码中使用内容类型设置为“text/html；charset=utf-8”的\u2028字符文本时，就会出现javascript解析错误

例如：

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">

<html lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>json</title>

    <script type="text/javascript" charset="utf-8">
    var string = '     ';
    </script>
</head>
<body>

</body>
</html>


json
var字符串=     ';

如果省略了

，则一切正常。我已经在Safari和Firefox上测试过了，它们都有同样的问题

关于为什么会发生这种情况，以及如何正确修复（不删除编码）有什么想法吗

编辑：

经过进一步研究，具体问题是使用JSONP返回问题字符。然后，浏览器将u2028读取为换行符，并抛出一个关于字符串中无效换行符的错误。

这是有道理的，因为您告诉浏览器HTML和脚本都使用UTF-8，但随后您指定了一个非UTF-8编码的字符。当您指定“charset=UTF-8”时，您有责任确保传输到浏览器的字节实际上是UTF-8。在这种情况下，web服务器和浏览器将无法为您执行此操作。

您是否可以使用

\u2028

，而不是真正的字符？因为U+2028是，浏览器会认为像

\n

这样的真正的换行字符

我们不能这样做

x = "

"

对吧?？但是我们有

x=“\n”

，所以可能是相同的概念。

好的，回答我自己的问题

通常，JSON解析器会去除这些问题字符，因为我在检索JSONP时没有使用JSON解析器，而浏览器会在调用回调后立即尝试解析JSON本身

修复此问题的唯一方法是确保服务器在请求JSONP资源时从不返回这些字符

p、美国。我的问题是关于u2028，根据以下所有字符都可能导致这些问题：

“\u0000\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-\u206f\ufeff\ufff0-\uffff”

是的，这是ECMAScript标准（第三版第7.3节）中记录的JavaScript语言的一个特性，U+2028和U+2029字符作为行尾。因此，JavaScript解析器将以与换行符相同的方式处理任何未编码的U+2028/9字符。由于不能在字符串文本中添加换行符，因此会出现语法错误

这是JSON设计中的一个不幸疏忽：它实际上不是JavaScript的一个适当子集。原始U+2028/9字符在JSON的字符串文本中是有效的，并且将被

JSON.parse

接受，但在JavaScript本身中不是这样

因此，只有当您确信JSON解析器显式地转义这些字符时，使用JSON解析器生成JavaScript代码才是安全的。有的做，有的不做；许多

\u

-对所有非ASCII字符进行转义，从而避免了问题。

从何处获得解析错误？在

var string=''的行上\u2029

Too顺便说一下，我已经对它进行了更多的测试，Douglas Crockford的实现没有抛出解析错误。你有这个列表的来源吗？（douglas Crockford下的链接没有任何用处）链接到JSON js，当repo/文件更新时，JSON js不会中断：这非常有用。修复方法是转义JSON，然后解析客户端。例如，对于Ruby/Rails，它告诉您在服务器端模板中执行$.parseJSON（“#{j xyz.to_json}”）
。更好的是：json.parse（#{j.to_json.inspect}）
将其呈现为字符串，其中包含\uxxx
的任何不规则字符。您可以将json插入到脚本标记中，其类型设置为“application/json”。这应该避免将UTF-8文本解析为JavaScript。加载页面后，可以使用JSON.parse（）
解析JSON，方法是将脚本标记的innerHTML
作为参数传递。我不确定这是JSON中的疏忽还是Javascript中的设计缺陷；将这些字符作为换行符包含是奇怪和意外的，并且不是由其他文本数据格式完成的。但对于JSON，虽然它的起源是Javascript子集，但多年来它并没有与Javascript绑定，规范也并没有宣称它将是一个子集，或者说这将是一个目标。建议不要评估它，而是正确地解析它。因此，除了使用JSONP之外，引用写作是否必要甚至是一件好事还不完全清楚。在第10版（非常新）中：“更新的语法包括……允许字符串文本中的U+2028（行分隔符）和U+2029（段落分隔符）与JSON对齐。”