Как форматировать JSON без изменения больших чисел и записи дробей

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

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

Проверенный пример форматирования

Все значения ниже синтетические. Откройте JSON formatter и вставьте:

{"id":9007199254740993,"amount":1.2300,"scale":1e3}

Для indent=2, trailing_newline=false проверенный результат json.format версии 1:

{
  "id": 9007199254740993,
  "amount": 1.2300,
  "scale": 1e3
}

Число 9007199254740993 не округлено. Запись 1.2300 не заменена на 1.23, а 1e3 — на 1000. При минификации JSON удаляются незначащие пробелы, но эти последовательности символов тоже остаются.

Инструменты также сохраняют порядок ключей и написание escape-последовательностей строк. Если исходный текст содержит повторяющиеся ключи, форматирование сохраняет их: это не проверка уникальности ключей и не выбор «правильного» значения.

Почему обычный parse/stringify может дать другой текст

JSON допускает числа с дробью и экспонентой, а конкретные парсеры могут ограничивать диапазон и точность. Для распространённого двоичного представления RFC выделяет диапазон целых от -(2^53)+1 до (2^53)-1, в котором реализации согласуются на точных значениях. RFC 8259, раздел 6, декабрь 2017; проверено 05.10.2026.

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

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

Форматирование и конвертация имеют разные границы

Сохранение текста json.format не переносится автоматически на JSON → CSV или JSON → YAML. Эти операции разбирают значения для преобразования в другой формат. В Neraviko они отклоняют небезопасные числа вместо молчаливого округления.

Например, синтетический вход для json.to_csv:

[{"n":9007199254740993}]

возвращает UNSAFE_JSON_NUMBER. Это проверено локальным вызовом версии 1. Сначала успешное форматирование большого числа, а затем отказ конвертера — ожидаемое различие задач. Удаление пробелов не сделало число совместимым с преобразованием.

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

Сравните токены, а не только отображение

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

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

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

Проверка перед передачей

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

Форматирование принимает исходный JSON-текст; общий лимит запроса операции — 262 144 байта. Обработка серверная. По контракту сырые входы и выходы не сохраняются и не логируются по умолчанию; это не означает локальную работу браузера. Для первоначальной проверки используйте искусственный документ, как в примере.