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

Что такое экранирование строк JSON?#

Внутри документа JSON строка обязана находиться между двойными кавычками — и это порождает проблему, как только сам текст содержит кавычку, перевод строки или обратную косую черту. Если вставить их «как есть», парсер увидит закрывающую кавычку слишком рано или воспримет \ как начало неизвестной escape-последовательности. Экранирование (escaping) — это замена таких символов короткими комбинациями с обратной чертой, как их определяет спецификация JSON: \" для кавычки, \\ для обратной черты, \n для перевода строки, \t для табуляции и ещё несколько. Деэкранирование (unescaping) — обратное преобразование этих последовательностей в исходные символы.

Есть и второй, более жёсткий режим. Некоторые legacy-системы — старые логгеры, ограничительные базы данных, транзитные слои, рассчитанные на чистый ASCII, — давятся любым байтом выше 127. Для них JSON позволяет записать любой не-ASCII символ как \uXXXX (а символы астральной плоскости, такие как эмодзи, — как суррогатную пару UTF-16). Текст остаётся корректным JSON; просто после экранирования он целиком состоит из ASCII.

Эта страница работает в обоих направлениях и в обоих режимах: экранирует «сырую» строку в валидный строковый литерал JSON или деэкранирует литерал обратно в исходный текст — с опциональным переключателем Только ASCII, который принудительно переводит каждую не-ASCII кодовую точку в форму \uXXXX.

Как пользоваться#

1. Выберите направление переключателем Кодировать / Декодировать в левом верхнем углу панели инструментов. «Кодировать» экранирует сырой текст в JSON-литерал; «Декодировать» возвращает литерал обратно в текст.
2. Введите или вставьте текст в панель Ввод слева.
   • В режиме Кодировать весь текст превращается в один JSON-строковый литерал (включая окружающие кавычки).
   • В режиме Декодировать можно вставить как полный литерал в кавычках ("a\nb"), так и только экранированное тело без кавычек (a\nb) — инструмент сам обернёт его в кавычки. Корректное JSON-число, булево значение или объект будут отклонены с сообщением «это не строка», а не молчаливо приведены к строке.
3. Отметьте Только ASCII (\uXXXX) (режим «Кодировать»), если приёмник не переваривает не-ASCII байты. Астральные символы вроде эмодзи при этом выводятся правильной суррогатной парой — ровно так же, как сделал бы JSON.stringify.
4. Результат появляется в реальном времени в панели Вывод. Нажмите Копировать, чтобы забрать его.
5. Пример подставляет многоязычную демонстрационную строку; Очистить сбрасывает обе панели.

Ключевые возможности#

• Точные короткие формы по спецификации. Используются ровно те последовательности, что требует RFC 8259 (\", \\, \b, \f, \n, \r, \t), и \uXXXX для всего остального ниже 0x20 — байт-в-байт как у JSON.stringify.
• Настоящий режим «только ASCII». Не-ASCII символы не отбрасываются и не превращаются в «кракозябры»; каждый выводится как \uXXXX, а астральные символы (выше U+FFFF) становятся корректной суррогатной парой UTF-16, а не сломанной одиночной кодовой единицей, которую декодеры отвергнут.
• Толерантное деэкранирование. Принимает как полный литерал в кавычках, так и голое экранированное тело, поэтому наполовину вставленные обрывки из строки лога всё равно декодируются, а не выбрасывают ошибку.
• Не угадывает. Если деэкранируемый ввод — корректный JSON, но не строка (например, голое число или массив), инструмент прямо об этом сообщает, вместо того чтобы тихо превратить его в строку за вашей спиной.

Разбор примера#

Загрузите Пример в режиме Кодировать, и вводом будет строка, намеренно смешивающая кавычки, путь с обратной чертой, перевод строки, знак копирайта, эмодзи и китайский:

He said "hi"
\path\ © 🌍 你好

Без Только ASCII экранированный литерал сохраняет читаемые символы как есть и экранирует лишь то, что обязано быть экранированным:

"He said \"hi\"\n\\path\\ © 🌍 你好"

Теперь отметьте Только ASCII (\uXXXX), и тот же ввод превращается в чистый ASCII — знак копирайта сворачивается в четырёхсимвольную форму \u00a9, глобус-эмодзи в суррогатную пару \ud83c\udf0d, а каждый китайский иероглиф в свою кодовую точку (\u4f60, \u597d):

"He said \"hi\"\n\\path\\ \u00a9 \ud83c\udf0d \u4f60\u597d"

Переключитесь в Декодировать и вставьте обратно любой из этих литералов: исходный текст — включая эмодзи и китайский — восстановится без потерь.

FAQ#

Почему эмодзи превращается в два кода \u, а не в один?#

Символы выше U+FFFF (эмодзи, редкие CJK-расширения, некоторые математические знаки) не помещаются в одну 16-битную кодовую единицу, поэтому UTF-16 представляет их суррогатной парой — высоким суррогатом и низким. Глобус-эмодзи 🌍 (U+1F30D) превращается в \ud83c\udf0d. Вывод только одного \u дал бы некорректный JSON, который строгие декодеры отвергнут; этот инструмент выводит пару ровно так же, как JSON.stringify, поэтому результат корректно проходит обратное преобразование.

Декодирование пишет «Ввод не является JSON-строкой». Что я вставил?#

Вы вставили что-то, являющееся корректным JSON, но не строку — обычно голое число (42), булево значение (true) или объект/массив. Инструмент отказывается превращать это в строку, потому что иначе скрыл бы настоящую ошибку (вы почти наверняка хотели вставить строковое значение, а не весь документ). Оберните текст в кавычки и попробуйте снова.

Поддерживаются ли управляющие символы вроде литеральной табуляции или звонка?#

Да. Литеральная табуляция во вводе становится \t, забой — \b, перевод страницы — \f, возврат каретки — \r; любой другой управляющий код ниже U+0020 (включая звонок, 0x07) превращается в код вида \u0007. Это важно, потому что сырые управляющие символы внутри JSON-строк недопустимы и некоторые парсеры отвергают их безоговорочно.

Делает ли режим «только ASCII» вывод «безопаснее»?#

Только в специфическом смысле — выживание на транзитном слое, который калечит или отвергает не-ASCII байты. Это не мера безопасности: данные по-прежнему полностью обратимы, просто записаны более ограниченным алфавитом. Включайте его, когда приёмник требует ASCII; в остальных случаях оставляйте выключенным — читаемая форма куда удобнее при отладке.