Форматтер и валидатор JSON

Что делает форматтер JSON

Структура JSON из вложенных объектов и массивов на рабочем столе

Форматтер решает три связанные задачи. Сначала он проверяет, соответствует ли вставленный текст синтаксису JSON. Затем либо расставляет переносы и отступы по два пробела, либо удаляет пробелы и переводы строк между элементами. Строки, числа, порядок свойств и escape-последовательности остаются записанными как в исходнике.

Например, компактная запись {"active":true,"items":[1,2]} после форматирования занимает несколько строк. Вложенность массива становится видна сразу, но данные не меняются. Обратный режим собирает тот же документ в {"active":true,"items":[1,2]}, чтобы его было удобнее передать в запросе или сохранить.

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

Из каких значений состоит JSON

JSON хранит шесть видов значений. Четыре простых вида: строка, число, логическое значение true или false и пустое значение null. Два составных вида: объект с именованными свойствами и массив с последовательностью элементов.

Объект записывают в фигурных скобках. Имя каждого свойства является строкой в двойных кавычках, после него ставят двоеточие. Массив записывают в квадратных скобках, а его элементы разделяют запятыми. Вложенность не ограничивается одним уровнем: значением свойства может стать другой объект, массив или простое значение.

По RFC 8259 весь документ не обязан начинаться с объекта или массива. Строка "готово", число 42 и значение true являются полноценными JSON-документами. Некоторые старые системы принимают только объект или массив, но это ограничение конкретной программы, а не современного формата.

Какие записи валидатор не принимает

JSON похож на запись объекта в JavaScript, но правила строже. Имена и строковые значения заключают только в двойные кавычки. Одинарные кавычки, комментарии, undefined, NaN и Infinity в JSON не входят. Слова true, false и null пишутся строчными буквами.

После последнего свойства объекта или элемента массива нельзя оставлять запятую. Запись [1,2,] завершится ошибкой у закрывающей скобки: после запятой ожидалось ещё одно значение. Валидатор покажет строку и столбец, поэтому в большом документе не придётся искать место только глазами.

Числа записываются в десятичной системе. Целая часть не получает ведущий ноль, кроме самого числа 0. Допустимы минус, дробная часть после точки и показатель степени, например -12.5e+3. Десятичная запятая из русской записи числа здесь не работает.

Внутри строки кавычка, обратная косая черта и управляющие символы требуют escape-записи. Перенос строки обозначают как \n, табуляцию как \t, а кавычку как \". Обычный перевод строки прямо внутри кавычек делает документ некорректным.

Почему числа не нужно разбирать ради отступов

Многие короткие реализации сначала превращают JSON в объект JavaScript, а потом собирают обратно. Такой путь способен изменить числовую запись. Например, целое 9007199254740993 находится за диапазоном, в котором двоичное число JavaScript хранит каждую единицу точно. Причину этой границы объясняет материал о вычислениях с плавающей точкой.

Этот форматтер разбирает структуру, но при выводе сохраняет исходные токены. Число 9007199254740993 не округляется, а запись 1e+03 не превращается в 1000. Форматирование меняет только незначащие пробелы между скобками, запятыми, двоеточиями и значениями.

Тот же принцип сохраняет escape-последовательности. Строки "A" и "\u0041" обозначают один символ, но выглядят по-разному в исходнике. Форматтер не решает за пользователя, какую запись оставить.

Что происходит с повторяющимися ключами

RFC 8259 рекомендует делать имена внутри одного объекта уникальными, но синтаксис прямо не запрещает повтор. Документ {"price":100,"price":120} проходит грамматическую проверку. Проблема появляется позже: одна программа оставит последнее значение, другая сообщит об ошибке, третья сохранит оба.

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

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

Когда форматировать, а когда сжимать

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

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

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

Проверка на знакомых фрагментах

Пример 1. Компактный объект. Исходник { "name": "eCalc", "active": true } после сжатия превращается в {"name":"eCalc","active":true}. Два свойства и их значения сохраняются, исчезают только пробелы между токенами.

Пример 2. Массив из трёх чисел. Запись [3,1,2] форматируется с отдельной строкой для каждого элемента. Порядок 3, 1, 2 не меняется, потому что перестановка элементов изменила бы данные.

Пример 3. Одно число. Исходник 42 остаётся 42 и после форматирования, и после сжатия. Это корректный документ из одного значения, объект вокруг него не требуется.

Пример 4. Большое целое. В документе {"value":9007199254740993} все 16 цифр сохраняются буквально. Форматтер не превращает число в тип JavaScript и поэтому не округляет последнюю цифру.

Пример 5. Лишняя запятая. Для строки [1,2,] валидатор укажет строку 1, столбец 6: после второй запятой ожидалось значение, но встретилась закрывающая скобка.

Пример 6. Два одинаковых ключа. Документ {"price":100,"price":120} сохраняет обе пары и получает предупреждение. Пользователь сам решает, какое из двух значений оставить перед передачей в другую систему.

Ограничения локальной проверки

Инструмент принимает строгий JSON по RFC 8259. Он не форматирует JSONC и JSON5, не сортирует ключи и не проверяет документ по JSON Schema. Валидный синтаксис также не доказывает правильность данных: поле email может содержать число, если отдельная схема или программа не запрещает это.

Размер исходника ограничен 2 МБ, глубина вложенности 256 уровнями, а готовый текст 8 МБ. Эти пределы защищают вкладку от слишком тяжёлой операции. Для гигабайтного журнала или автоматически созданной выгрузки нужен потоковый инструмент, который не держит весь документ в памяти.

Для другой локальной записи данных пригодятся конвертер Base64 и URL-кодировщик. Если структура верна, но строки выглядят как РџСЂ..., ошибку чтения кодировки поможет исправить декодер текста. Форматтер JSON отвечает только за структуру одного документа и не выполняет код.

Частые вопросы о JSON

Ответы отделяют проверку синтаксиса от изменения данных и помогают понять сообщения валидатора.

Что такое JSON простыми словами?

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

Изменяет ли форматирование значения?

Нет. Инструмент меняет только незначащие пробелы и переносы вне строк. Числа, строки, порядок свойств, escape-последовательности и повторяющиеся ключи сохраняются как в исходнике.

Почему комментарий вызывает ошибку?

Комментарии не входят в строгий JSON по RFC 8259. Они встречаются в расширениях JSONC и JSON5, но документ для обычного JSON API нужно передавать без них.

Можно ли писать строки в одинарных кавычках?

Нет. Имена свойств и строковые значения JSON заключаются в двойные кавычки. Одинарные кавычки относятся к синтаксису некоторых языков программирования, но не к JSON.

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

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

Что означает предупреждение о повторяющемся ключе?

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

Сортирует ли форматтер свойства по алфавиту?

Нет. Порядок свойств сохраняется. Автоматическая сортировка могла бы создать большой лишний diff и не должна подменять отдельное решение пользователя.

Отправляется ли вставленный JSON на сервер?

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

Есть что добавить?

Напишите своё мнение, комментарий или предложение.