Как читать вложенный JSON с помощью форматирования

Увидеть вложенность и сохранить 1e3, escape и порядок ключей

Бумажная архитектура с вложенными комнатами как образ структуры JSON

Однострочный ответ API трудно читать: границы объектов теряются, вложенные массивы приходится разбирать глазами. Форматирование добавляет отступы и переносы строк. Оно помогает изучить структуру, но не меняет правила данных и не исправляет их за вас.

В этом руководстве разберём синтетический заказ: он не относится к покупателю и не содержит настоящих реквизитов. Для работы используем форматирование JSON в Neraviko. Обработка выполняется на сервере: введённый текст отправляется из формы HTTP-запросом. Для конфиденциального документа сначала подготовьте обезличенную копию или работайте локально в своей среде.

Пример до и после

Вставьте следующий текст целиком, без оформления блока кода:

{"order":"DEMO-17","amount":1e3,"items":[{"name":"Paper","qty":2}],"note":"keep  two spaces","letter":"\u0041"}

При отступе в два пробела и выключенном переносе в конце документа результат выглядит так:

{
  "order": "DEMO-17",
  "amount": 1e3,
  "items": [
    {
      "name": "Paper",
      "qty": 2
    }
  ],
  "note": "keep  two spaces",
  "letter": "\u0041"
}

Этот результат получен запуском текущего форматтера Neraviko на показанном примере. Обратите внимание на три детали: 1e3 не заменён на 1000, запись \u0041 сохранена, два пробела внутри note остались на месте. Форматтер работает с исходным текстом, не пересобирая значения через декодирование и повторную сериализацию. Порядок ключей также сохранён. Это полезно при сопоставлении с исходным сообщением или документацией интеграции.

Форматирование всё же меняет байты документа. Если другая система подписывает исходное тело запроса или проверяет его контрольную сумму, красиво оформленная копия будет отличаться от оригинала. Храните исходник отдельно; читаемая версия нужна для анализа, а решение о передаче принимает ваш протокол.

Как выполнить преобразование

  1. Откройте JSON formatter и замените демонстрационный ввод своим обезличенным JSON.
  2. Выберите отступ: инструмент принимает целое число от 1 до 8. Значение по умолчанию — 2.
  3. Решите, нужен ли дополнительный перенос строки после последней скобки. По умолчанию он выключен.
  4. Запустите операцию и прочитайте статус. Ошибка разбора означает, что результат ещё не готов.
  5. Сверьте ключи и значения с оригиналом, затем скопируйте или скачайте результат доступной кнопкой.

Не заменяйте обычные двойные кавычки типографскими при копировании из текстового редактора. Не включайте в поле строки с тройными обратными кавычками: они обозначают блок кода в статье, а не являются частью JSON. Если исходник пришёл вместе с HTTP-заголовками, вставляйте только тело документа.

Когда форматтер сообщает об ошибке

Для синтетического ввода {"ready":true,} текущий парсер сообщает INVALID_JSON: лишняя запятая перед закрывающей скобкой. Позиция ошибки — 14. Это отсчёт байтов от нуля, а не номер строки. При кириллице один символ может занимать несколько байтов, поэтому простое отсчитывание букв в редакторе даст другое место.

Исправление здесь однозначно: удалить последнюю запятую и повторить запуск. Если нарушены кавычки или пропущено значение, не угадывайте содержимое: сравните документ с источником. Для отдельной диагностики предназначена проверка синтаксиса JSON.

Сервис принимает исходный JSON как строку. В API это значит, что поле input содержит текст документа, а не уже разобранный объект. Операция имеет лимит 262 144 байта запроса; действует также общий лимит полезной нагрузки. Большой файл и глубоко вложенный документ могут потребовать локального инструмента. Лимит интерфейсного поля в символах не следует считать обещанием принять столько же байтов UTF-8.

Чего результат не доказывает

Успех форматирования показывает, что документ прошёл синтаксическую проверку текущего инструмента. Он не подтверждает наличие обязательных полей, допустимый диапазон суммы или корректность заказа. Например, строка "two" вместо числа может быть синтаксически допустимой, но не подходить вашему API. Для правил структуры используйте JSON Schema validation.

Не используйте форматирование для устранения повторяющихся ключей. Neraviko сохраняет их, чтобы не потерять исходный текст. Разные получатели могут обработать такие ключи по-разному; RFC рекомендует уникальные имена в объекте. Исправлять повтор нужно в системе, которая создала документ, после выяснения правильного значения. RFC 8259, раздел 4.

Когда чтение закончено и нужна компактная копия, откройте минификацию JSON. Для проверки интеграции полезно держать рядом исходник, читаемый результат и договорённость о полях: каждое из этих представлений отвечает на свой вопрос.