Экранирование JSON

JSON (RFC 8259) — это строгая текстовая грамматика; каждый строковый литерал должен быть заключён в ASCII двойные кавычки (U+0022), и любой символ, способный нарушить эту грамматику, должен быть выражен как экранированная последовательность с обратным слешем. Обязательные экранирования: двойная кавычка в обратный слеш-кавычка, обратный слеш в двойной обратный слеш и 32 управляющих символа от U+0000 до U+001F (включая \b U+0008, \f U+000C, \n U+000A, \r U+000D, \t U+0009). Любой символ выше U+001F может присутствовать в строке как последовательность сырых байтов UTF-8, включая CJK-идеограммы, эмодзи, буквы с диакритиками и другие дополнительные символы. Прямой слеш необязательно экранировать (\/), но конвенция предписывает делать это, когда JSON встраивается в HTML-теги <script>, чтобы последовательность закрывающего тега скрипта не закрыла окружающий элемент script преждевременно. На практике встречаются два слоя экранирования. JSON-экранирование (синтаксическая подстановка) — единственный, требуемый RFC 8259: оно гарантирует, что строка является валидным JSON. Unicode-экранирование (перезапись каждого символа как \uXXXX или \u{XXXXX}) — это выбор представления, а не синтаксическое требование; оно меняет только то, как байты выглядят в файле, но не то, во что они декодируются. CJK-текст уже валиден в JSON как сырые байты UTF-8; режим Unicode-экранирования страницы перезаписывает его в \uXXXX, что полезно при встраивании строки в исходный код Java или JavaScript, где окружающему парсеру пришлось бы работать с многобайтовым UTF-8, но это добавляет 4-6 байтов на символ и ухудшает читаемость. У правил экранирования есть граничные случаи. JSON.parse строг к ведущим нулям (01 вызывает ошибку парсинга, хотя JavaScript принял бы его как восьмеричное 1); JSON.stringify в V8 всегда генерирует минимально необходимые экранирования (управляющие символы как \b/\n/\r/\t/\f, когда возможно, иначе как \uXXXX, а прямой слеш /, U+2028, U+2029 остаются нетронутыми для читаемого вывода). Одинокий суррогат (высокий суррогат без низкого после него) технически валиден по RFC 8259, но JSON.parse в строгом режиме или в TypeScript отвергает его как InvalidString; режим экранирования страницы заменяет одинокие суррогаты на \uFFFD (символ замены), чтобы вывод проходил round-trip через любой стандартный парсер. Для встраивания в исходный код JavaScript строке JSON нужен третий слой экранирования: JSON внутри строкового литерала JS должен экранировать сами обратные слеши. Режим вывода JS-страницы добавляет это двойное экранирование, а кнопка eval или JSON.parse показывает, что оба кодирования декодируются в одну строку. Контексты встраивания в HTML добавляют четвёртый слой: <, >, & требуют HTML-экранирования сущностей в окружающей странице, а значения атрибутов также требуют экранирования кавычек. JSON в HTML печально известен как опасный (ловушка </script>, описанная выше), и лучше избегать его в пользу безопасных приёмников, таких как присвоение textContent или JSON.stringify в блок <script type="application/json"> (затем читать через script.textContent, а не eval). JSON5 (популярное надмножество) добавляет одинарные кавычки, многострочные строки, ключи без кавычек, trailing-запятые, NaN/Infinity и однострочные комментарии //. Страница не генерирует вывод JSON5; если нужен round-trip, используйте специализированную библиотеку.

• Строки JSON (RFC 8259) должны экранировать двойную кавычку в обратный слеш-кавычку, обратный слеш в двойной обратный слеш и 32 управляющих символа U+0000..U+001F (\b \f \n \r \t, остальные как \uXXXX). Всё выше U+001F допустимо как сырые байты UTF-8, включая CJK, эмодзи и буквы с диакритиками.
• Два слоя «экранирования»: JSON-экранирование (синтаксическое, обязательное) делает строку валидным JSON; Unicode-экранирование (представительное) перезаписывает символы как \uXXXX и меняет только читаемость, но не валидность.
• Необязательный '/': / в \/ допустим в JSON. Конвенция: экранировать при встраивании JSON в HTML <script>, чтобы последовательность закрывающего тега скрипта не закрывала окружающий тег.
• CJK не экранируется в сыром UTF-8 JSON: пример '你好' — 6 сырых байтов. Режим Unicode-экранирования страницы перезаписывает его как \u4f60\u597d для использования в исходных файлах, что жертвует читаемостью ради совместимости.
• Одинокие суррогаты: высокий суррогат (U+D800..U+DBFF) без низкого после него технически валиден по RFC 8259, но JSON.parse в строгом режиме или TypeScript отвергает его. Страница заменяет одинокие суррогаты на \uFFFD, чтобы вывод проходил round-trip через строгие парсеры.
• JSON.parse строг: ведущие нули (01) — ошибка парсинга, NaN/Infinity — невалидные литералы, trailing-запятые не допускаются. JSON.stringify в V8 всегда генерирует минимально необходимые экранирования и оставляет прямой слеш / и U+2028/U+2029 нетронутыми для читаемости.
• JSON в JS: для встраивания JSON-строки в строковый литерал JS удвойте обратные слеши. Режим вывода «JS string» страницы добавляет этот слой; eval над результатом даёт ту же строку, что и JSON.parse.
• Надмножество JSON5: строки в одинарных кавычках, многострочные строки, ключи без кавычек, trailing-запятые, NaN/Infinity, однострочные комментарии //. Страница генерирует строгий JSON RFC 8259, а не JSON5.