Ошибка анализа JavaScript на '\u2028' unicode символ

Каждый раз, когда я использую \u2028 символьный литерал в своем источнике JavaScript с набором типа контента к "тексту/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, оба показывает ту же проблему.

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

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

48
задан klaaspieter 4 June 2010 в 11:02
поделиться

3 ответа

Хорошо, отвечу на свой вопрос.

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

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

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

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

11
ответ дан 26 November 2019 в 18:50
поделиться

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

-4
ответ дан 26 November 2019 в 18:50
поделиться

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

Мы не можем делать что-то подобное

x = "

"

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

2
ответ дан 26 November 2019 в 18:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: