Распространенные ошибки синтаксиса JSON: Руководство по стандарту RFC 8259

1. Валидация синтаксиса, JSON Schema и бизнес-правила: принципиальные различия

Распространенное заблуждение среди разработчиков — смешивать все уровни проверки данных JSON в один процесс. В современной архитектуре программного обеспечения функционируют три независимых уровня валидации:

• Валидация синтаксиса RFC 8259: Проверяет строгое соответствие лексической грамматике формата JSON: парность фигурных и квадратных скобок, обязательные двойные кавычки для ключей и строк, запятые в качестве разделителей и корректные примитивные литералы (строки, числа, булевы значения, null). Если пропущена хоть одна кавычка или скобка, текст не является валидным JSON.
• Валидация по JSON Schema: Оценивает, соответствует ли синтаксически корректный документ заранее заданному контракту данных (директивы $schema, ожидаемые типы свойств, обязательные поля, границы массивов). Документ может быть на 100% корректен синтаксически, но нарушать схему.
• Валидация бизнес-правил: Проверяет предметную логику конкретного приложения (например, баланс счета не может быть отрицательным или дата окончания должна быть позже даты начала). Ни синтаксические парсеры, ни общие схемы не проверяют инварианты предметной области.

Инструмент GoToolstack выполняет исключительно строгую валидацию синтаксиса по RFC 8259 и форматирование AST; он не осуществляет валидацию JSON Schema и не проверяет бизнес-правила приложения.

2. Форматирование — это не автоматическое исправление ошибок

Форматировщики JSON (инструменты структурирования и минификации) перераспределяют пробелы, переносы строк и отступы на основе абстрактного синтаксического дерева (AST), которое уже является синтаксически корректным. Они не являются механизмами автовосстановления поврежденных данных.

При вводе некорректного текста движок немедленно прерывает обработку на первом недопустимом байте, выводит исчерпывающую диагностику с указанием числовой позиции и фрагмента ошибки (например, Trailing comma in object is not allowed at position 45) и очищает панель вывода. Инструмент не пытается угадать намерения разработчика, не дописывает недостающие скобки, не удаляет лишние запятые и не заменяет одинарные кавычки в автоматическом режиме. Для успешного форматирования требуется ручное исправление синтаксической ошибки в исходном коде.

3. 5 наиболее распространенных синтаксических ошибок в JSON

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

{'status': 'success'}

{count: 42}

{"path": "C:\programs\data.json"}

// Настройки сервера
{"port": 8080}

4. Ловушка 64-битных целых чисел: Безупречное сохранение токенов vs. Риск потери точности во внешних системах

В стандартных движках JavaScript числа представляются в формате 64-битных чисел с плавающей запятой двойной точности IEEE 754. Верхняя граница безопасных целых чисел составляет:

Number.MAX_SAFE_INTEGER = 9,007,199,254,740,991 (2^53 - 1)

Когда API передает большие 64-битные идентификаторы, первичные ключи баз данных или хеши транзакций (например, 9007199254740993), стандартный вызов JSON.parse() незаметно округляет значение до 9007199254740992, искажая данные без генерации ошибки.

Движок GoToolstack использует специализированный парсер без потерь, который сохраняет числовые литералы в виде точных текстовых токенов в структуре AST. Благодаря этому при форматировании все цифры сохраняются неизменными. Однако локальное сохранение не гарантирует безопасности во внешних системах-получателях: если принимающий микросервис, драйвер БД или клиентское приложение затем распарсит полученный JSON стандартным парсером float64, потеря точности произойдет на их стороне. В распределенных системах большие 64-битные идентификаторы рекомендуется передавать в виде строк (например, "9007199254740993").

5. Дублирующиеся ключи объектов и неоднозначность синтаксического анализа по RFC 8259

Рассмотрим объект, содержащий повторяющиеся ключи с одинаковыми именами:

{"user": "alice", "user": "bob"}

Парсер AST GoToolstack сохраняет каждую пару ключ-значение в порядке поступления без автоматического удаления предыдущих записей. Однако раздел 4 стандарта RFC 8259 прямо указывает на то, что поведение парсеров при обработке повторяющихся ключей непредсказуемо в различном ПО:

• Некоторые парсеры учитывают только первый встретившийся ключ и игнорируют все последующие.
• Большинство стандартных библиотек (включая JSON.parse() в JS и json.loads() в Python) перезаписывают предыдущее значение, оставляя только последний ключ.
• Некоторые строгие парсеры полностью отклоняют документ, выбрасывая синтаксическую ошибку.

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

6. Технические ограничения и границы возможностей инструмента

• Отсутствие древовидного представления и валидации схем: Инструмент представляет собой лаконичный двухпанельный текстовый редактор с мгновенной диагностикой. Он не содержит интерактивного древовидного просмотрщика DOM или валидатора JSON Schema.
• Недопустимые значения: NaN, Infinity и -Infinity не допускаются спецификацией RFC 8259. Значения JavaScript, такие как undefined, функции и циклические ссылки, не могут быть сериализованы в JSON.
• Локальное выполнение на стороне клиента: Все операции синтаксического анализа и форматирования выполняются исключительно в памяти браузера пользователя; исходные данные никогда не отправляются на удаленные серверы.