Проверка и форматирование JSON

Проверка и форматирование JSON, это бесплатный инструмент, который проверяет синтаксическую корректность JSON и форматирует валидные данные, делая их структуру более наглядной.

Для чего нужны проверка и форматирование JSON?

Проверка позволяет убедиться, что введённые данные соответствуют грамматике JSON, а форматирование добавляет единообразные отступы и пробелы в валидные объекты и массивы. Это удобно при отладке ответов API, проверке конфигурации перед развёртыванием или чтении компактных данных, полученных от стороннего поставщика.

Синтаксис JSON строже, чем у литералов объектов JavaScript. Имена свойств должны заключаться в двойные кавычки, строки нельзя заключать в одинарные кавычки, а после последнего элемента объекта или массива не должно быть запятой. Комментарии, undefined, NaN и Infinity также не входят в спецификацию JSON.

Инструмент использует на сервере функцию PHP json_decode. Введённые данные передаются на сервер по HTTPS и не сохраняются. Поскольку они покидают твоё устройство, удали пароли, токены доступа и персональные данные, если правила твоей организации запрещают отправлять их на внешний сервер.

Как проверить и отформатировать JSON?

Вставь содержимое в поле JSON и запусти инструмент. Чтобы получить полезный результат, передавай одно полное значение JSON, а не часть объекта, скопированную из строки журнала.

1. Скопируй исходный ответ, блок конфигурации или другое значение JSON без окружающих его подписей из консоли.
2. Вставь данные в поле JSON, сохранив кавычки и управляющие последовательности.
3. Запусти проверку и изучи отформатированный результат или сообщение об ошибке.
4. Если проверка завершилась неудачно, исправь первую заметную синтаксическую ошибку и повтори попытку. Из-за одной пропущенной кавычки парсер может неправильно интерпретировать несколько последующих символов.

Между токенами JSON разрешены четыре пробельных символа: пробел (U+0020), табуляция (U+0009), перевод строки (U+000A) и возврат каретки (U+000D). Они не влияют на данные, поэтому их можно добавлять или удалять. Пробельные символы внутри строки в кавычках являются частью данных и должны оставаться без изменений. Знаки препинания в строках также сохраняются, однако кавычки, обратные косые черты и управляющие символы необходимо записывать с соответствующими управляющими последовательностями.

Как понять результат проверки?

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

Частые причины ошибок:

• запятая перед закрывающим символом } или ];
• имя свойства без кавычек, например {name: "Ada"};
• строки в одинарных кавычках;
• пропущенная запятая между свойствами или элементами массива;
• неэкранированная двойная кавычка или обратная косая черта внутри строки;
• незавершённый объект, массив или строка;
• некорректные входные данные UTF-8 или необработанный управляющий символ внутри строки;
• лишние ведущие нули в целой части числа, например 01 или -01, либо значения, не предусмотренные JSON, например NaN.

Пустое поле не является валидным JSON. При этом отдельное значение, например 42, true, null или "hello", считается валидным JSON, даже если это не объект и не массив. Данные с очень большой глубиной вложенности также могут превышать предел декодера.

Синтаксическая проверка не подтверждает соответствие данных контракту API. Документ может быть валидным JSON, но содержать строку там, где приложение ожидает число, не включать обязательное свойство или использовать недопустимый формат даты. Для проверки таких требований применяй JSON Schema или проверки на уровне приложения.

Примеры JSON

Валидные данные в компактном виде:

{"name":"Ada","active":true,"roles":["admin","editor"]}

В отформатированном результате свойства и элементы массива размещаются на отдельных уровнях с отступами. Значения при этом остаются соответственно строкой, логическим значением и массивом. Форматирование меняет представление данных, но не их типы.

Невалидные данные с лишней запятой:

{"name":"Ada","active":true,}

Проверка завершается ошибкой, потому что JSON не допускает запятую после последнего свойства. Удали её, чтобы объект стал валидным.

Если входные данные представлены в корректной кодировке UTF-8, строки JSON могут напрямую содержать символы с диакритикой и текст на других письменностях. Например, {"city":"Zürich","greeting":"こんにちは"} является валидным JSON. Некоторые символы Unicode также можно записывать с помощью управляющих последовательностей JSON, таких как \u00fc. Для символов за пределами базовой многоязычной плоскости потребуются суррогатные пары.

Когда форматировать JSON не имеет смысла?

Форматирование не нужно, если JSON будет читать только машина, а проверять его вручную или просматривать изменения в системе контроля версий никто не будет. Дополнительные отступы и переносы строк увеличивают объём передаваемых данных, поэтому в рабочей среде ответы обычно отправляют в компактном виде.

Минификация JSON, который уже записан компактно, тоже почти ничего не даёт. Повторная минификация не сократит фиксированные имена свойств или строковые значения, а их изменение повлияет на сами данные. Если требуется обработать готовый к развёртыванию JavaScript, а не данные JSON, лучше использовать JS минификатор.

Форматирование особенно полезно при изучении структуры и значений JSON во время отладки, проверки кода и подготовки к развёртыванию. Оно помогает заметить несогласованную вложенность, упрощает просмотр больших массивов и делает различия нагляднее, когда конфигурация сохраняется в Git. При этом инструмент не исправляет некорректный JSON автоматически и не определяет, что должен был означать неоднозначный фрагмент.

Часто задаваемые вопросы

Можно ли добавлять комментарии в JSON?

Нет. В стандартном JSON нет синтаксиса комментариев, поэтому // comment и /* comment */ приводят к ошибке проверки. Если в конфигурационном файле нужны комментарии, используй формат, который их поддерживает, либо удали комментарии перед передачей содержимого строгому парсеру JSON.

Будут ли повторяющиеся имена свойств считаться ошибкой?

Не обязательно. Согласно спецификации JSON, имена членов внутри объекта должны быть уникальными, но парсеры не всегда считают повторы синтаксической ошибкой. При декодировании в PHP обычно сохраняется последнее значение, поэтому, если важно сохранить каждое вхождение, найди дубликаты до проверки.

Можно ли проверить файл JSON Lines?

Не как единый документ JSON. JSON Lines, также известный как NDJSON, содержит отдельное значение JSON в каждой строке, тогда как обычный парсер JSON ожидает одно значение верхнего уровня. Проверяй каждую строку отдельно или преобразуй записи в единый массив JSON.

Важен ли порядок свойств в объекте JSON?

Приложения не должны полагаться на порядок свойств объекта JSON. Порядок элементов массива определён, но объекты представляют собой наборы именованных членов, и другой парсер или сериализатор может вывести их в иной последовательности. Если порядок имеет значение, помести значения в массив.

Почему корректный на вид файл JSON не проходит проверку?

Причиной может быть невидимая метка порядка байтов, некорректная кодировка UTF-8 или неэкранированный управляющий символ. При копировании из терминала также могут добавиться префиксы, например метки состояния или временные метки. Проверь исходные байты или открой файл в редакторе, который умеет показывать кодировку и управляющие символы.

Что проверить в конце

Перед развёртыванием исправленного JSON сравни не только отображаемые значения, но и типы данных, убедись, что управляющие последовательности не изменились, а затем запусти использующее эти данные приложение или проверку по его схеме. При диагностике сторонних данных сохраняй неизменённую копию исходного ответа, чтобы форматирование не скрыло причину ошибки.