Ошибка синтаксического анализа Javascript для символа \ u2028 - PullRequest
Новая
       1

Ошибка синтаксического анализа Javascript для символа \ u2028

48 голосов
/ 03 июня 2010

Всякий раз, когда я использую символьный литерал \ u2028 в моем источнике JavaScript с типом содержимого, установленным на "text / html; charset = utf-8", я получаю ошибки синтаксического анализа 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>

Если <meta http-equiv> опущен, все работает как положено. Я проверил это на Safari и Firefox, у обоих одинаковая проблема.

Любые идеи о том, почему это происходит и как правильно это исправить (без удаления кодировки)?

Edit: После еще нескольких исследований конкретная проблема заключалась в том, что символ проблемы был возвращен с использованием JSONP. Затем это было интерпретировано браузером, который читает u2028 как символ новой строки и выдает ошибку о недопустимом переводе строки в строку.

Ответы [ 4 ]

75 голосов
/ 07 февраля 2012

Да, это особенность языка JavaScript, задокументированная в стандарте ECMAScript (3-е издание, раздел 7.3), что символы U + 2028 и U + 2029 считаются окончаниями строк. Следовательно, синтаксический анализатор JavaScript будет обрабатывать любой незашифрованный символ U + 2028/9 так же, как и символ новой строки. Поскольку вы не можете поместить новую строку в строковый литерал, вы получите синтаксическую ошибку.

Это неудачный упущение в дизайне JSON: на самом деле он не является надлежащим подмножеством JavaScript. Необработанные символы U + 2028/9 допустимы в строковых литералах в JSON и будут приняты JSON.parse, но не в самом JavaScript.

Следовательно, безопасно генерировать код JavaScript с использованием анализатора JSON, если вы уверены, что он явно \u - экранирует эти символы. Некоторые делают, некоторые нет; многие \u -экранируют все не-ASCII символы, что позволяет избежать проблемы.

11 голосов
/ 04 июня 2010

Хорошо, чтобы ответить на мой собственный вопрос.

Обычно анализатор JSON удаляет эти проблемные символы, потому что я получал JSONP. Я не использовал анализатор JSON, вместо этого браузер пытался проанализировать сам JSON сразу после вызова обратного вызова.

Единственный способ исправить это - убедиться, что сервер никогда не возвращает эти символы при запросе ресурса JSONP.

p.s. Мой вопрос был о u2028, согласно библиотеке json2 Дугласа Крокфорда все следующие символы могут вызывать эти проблемы:

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

2 голосов
/ 04 июня 2010

Не могли бы вы просто использовать \u2028 вместо реального символа? Потому что U + 2028 - это разделитель строк в Unicode , браузеры считают, что в качестве реального символа разрыва строки, как \n.

Мы не можем делать как 

x = "

"

Правильно? но мы делаем x = "\n", поэтому может быть такая же концепция.

0 голосов
/ 04 июня 2010

Хорошо, это имеет смысл, так как вы сообщаете браузеру, что HTML и скрипт используют UTF-8, но затем вы указываете символ, не закодированный в UTF-8. Когда вы указываете "charset = UTF-8", вы несете ответственность за то, чтобы убедиться, что байты, передаваемые в браузер, на самом деле являются UTF-8. Веб-сервер и браузер не будут делать это за вас в этой ситуации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...