Форматтер JSON

JSON — это строгое подмножество того, что допускают объектные литералы JavaScript, и именно в этом разрыве кроется большинство ошибок «невалидный JSON». Запятая после последнего элемента массива или объекта допустима в современном JavaScript, но является синтаксической ошибкой в JSON. Строки в одинарных кавычках прекрасно работают в JavaScript, но JSON их отвергает — он требует двойные кавычки. Ключи объекта без кавычек — запись `{name: "value"}` вместо `{"name": "value"}` — валидное сокращение в JavaScript и невалидный JSON. Ни один из этих случаев не является редкой аномалией: это ровно те привычки, выработанные при написании JavaScript, которые незаметно превращают документ, похожий на JSON, в документ, JSON не являющийся.

Комментарии — ещё один частый источник путаницы, потому что немало форматов конфигурационных файлов, похожих на JSON, — и даже некоторые производные от JSON форматы, используемые намеренно, — допускают комментарии `//` или `/* */`, тогда как в самой спецификации JSON синтаксиса комментариев нет вовсе. Если скопировать «JSON»-конфиг, в котором на самом деле есть комментарии, в строгий парсер, разбор сразу же завершится ошибкой, и исправление — либо удалить комментарии, либо признать, что файл изначально не был стандартным JSON.

Парсер, который сообщает только «невалидный JSON» без указания места, заставляет вас глазами просматривать весь документ в поисках одной пропущенной запятой или неэкранированной кавычки — а это становится по-настоящему утомительным уже после нескольких десятков строк. Указание точной строки и столбца первой проблемы превращает такой поиск в прямое попадание — ошибка описывает конкретный символ, а не общий расплывчатый сбой, — и это разница между исправлением большого ответа API за секунды и минутами ручного просмотра.

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

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

Практическое правило простое: форматируйте JSON, пока с ним работаете — читаете, отлаживаете, редактируете вручную, — и минифицируйте перед тем, как отправить туда, где важен размер: в тело HTTP-запроса, параметр запроса URL или значение, хранящееся в переменной окружения с ограничением по длине.