Как Валидировать JSON Онлайн: Синтаксис, Схема и Частые Ошибки

У JSON (JavaScript Object Notation) есть формальная спецификация, определённая RFC 8259 и стандартом ECMA-404. Документ JSON валиден, когда полностью соответствует этой спецификации — не больше и не меньше. Правила строже, чем ожидают многие, и несколько вещей, которые разрешает JavaScript, в JSON явно запрещены.

Правила спецификации JSON

• Строки должны быть в двойных кавычках - строки в одинарных кавычках (`'value'`) не являются валидным JSON, даже если JavaScript их принимает.
• Без висячих запятых - `[1, 2, 3,]` и `{"a": 1,}` невалидны; запятую после последнего элемента нужно убрать.
• Без комментариев - `// строчные комментарии` и `/* блочные комментарии */` не входят в спецификацию JSON.
• Без значений undefined - `undefined` — концепция JavaScript; JSON допускает только `null`, числа, строки, булевы значения, массивы и объекты.
• У чисел не может быть ведущих нулей - `012` не валидный JSON; используйте `12`.
• Ключи объектов должны быть строками - `{1: "value"}` невалиден; ключи должны быть строками в двойных кавычках.
• Без управляющих символов в строках - сырые переводы строк, табуляции и другие управляющие символы нужно экранировать (`\n`, `\t` и т. д.).

Синтаксически валидный против семантически валидного

Документ JSON может быть синтаксически валидным (правильно сформирован по спецификации), но семантически невалидным для вашего приложения. Например, JSON-объект с "age" = -5 — это валидный JSON, но некорректный возраст для профиля пользователя. Валидация синтаксиса — то, что проверяет JSON-парсер; валидация по схеме — то, что ловит семантические ошибки. Оба уровня важны, и это руководство охватывает оба.

Самый быстрый способ проверить, валидна ли строка JSON, — вставить её в онлайн-валидатор JSON. Без установки, без настройки, без аккаунта. Результат мгновенный, а при использовании браузерного инструмента ваши данные никогда не покидают ваше устройство.

Текст JSON — это сериализованное значение. Заметьте, что некоторые прежние спецификации JSON ограничивали текст JSON объектом или массивом.

Использование форматера и валидатора JSON

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

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

Большинство невалидных JSON-документов терпят неудачу по одной из пяти причин. Знание этих шаблонов позволяет быстро исправлять ошибки, не полагаясь целиком на инструмент для диагностики.

// ❌ Невалидно - запятая после последнего свойства
{
  "name": "Alice",
  "age": 30,
}

// ✓ Валидно - без висячей запятой
{
  "name": "Alice",
  "age": 30
}

// ❌ Невалидно - ключ и значение в одинарных кавычках
{'city': 'London'}

// ✓ Валидно - ключ и значение в двойных кавычках
{"city": "London"}

// ❌ Невалидно - комментарии не входят в спецификацию JSON
{
  // Это объект пользователя
  "name": "Alice",
  "role": "admin" /* повышенные права */
}

// ❌ Невалидно - сырой перевод строки внутри значения
{"message": "line one
line two"}

// ✓ Валидно - экранированный перевод строки
{"message": "line one\nline two"}

// ❌ Невалидно - открыт массив, закрыт объект
{
  "items": [1, 2, 3
}

// ✓ Валидно - скобки парные
{
  "items": [1, 2, 3]
}

Валидация синтаксиса подтверждает, что JSON корректно сформирован. Валидация по схеме подтверждает, что JSON содержит правильные данные - правильные поля, правильные типы, правильные диапазоны значений. Это две разные проверки, и в продакшен-системах нужны обе.

Что такое JSON Schema?

JSON Schema — словарь для описания структуры и ограничений JSON-документа. Документ-схема указывает, какие поля обязательны, какого типа должно быть каждое поле, минимальные и максимальные значения чисел, допустимые шаблоны строк и другое. Валидируя JSON-документ по схеме, вы получаете точные ошибки вроде «поле 'email' обязательно» или «поле 'age' должно быть положительным целым» - а не просто «невалидный JSON».

Использование валидатора JSON Schema

Валидатор JSON Schema на Aback Tools принимает JSON-payload и JSON Schema и валидирует payload по ограничениям схемы. Он сообщает об ошибках на уровне правил с точным путём поля, которое не прошло проверку, - вы знаете не только, что валидация провалилась, но и какое поле нарушило какое правило. Это подходящий инструмент, когда нужно проверить, что ответ API соответствует контракту или что конфиг содержит все обязательные настройки.

Валидация синтаксиса против валидации по схеме

Генерация схемы из существующего payload

Самый быстрый способ добавить валидацию по схеме в существующий проект - сгенерировать схему из заведомо корректного payload. Вставьте репрезентативный JSON-объект в Генератор JSON Schema, и он создаст полную схему с определениями типов, обязательными полями и подсказками формата. Скопируйте вывод в проект и используйте как контракт валидации для всех будущих payload этого типа.

Онлайн-инструменты — быстрейший выбор для разовых проверок, но продакшен-системам нужна валидация JSON, встроенная в код. В каждом крупном языке программирования есть хотя бы одна хорошо поддерживаемая библиотека разбора JSON, а у большинства — ещё и библиотеки валидации по схеме.

JavaScript и TypeScript

В JavaScript `JSON.parse()` выбрасывает `SyntaxError` при невалидном JSON - оберните его в try/catch, чтобы обработать ошибку аккуратно. Для валидации по схеме AJV (Another JSON Validator) — самая распространённая библиотека, поддерживающая JSON Schema от Draft-07 до Draft 2020-12 с высокой производительностью. Zod — популярная TypeScript-first альтернатива, валидирующая JSON по схемам типов в рантайме с полной TypeScript-инференцией. Конвертер JSON в схему Zod на Aback Tools автоматически генерирует схему Zod из любого JSON-payload.

function isValidJson(input: string): boolean {
  try {
    JSON.parse(input);
    return true;
  } catch {
    return false;
  }
}

// Or get the parsed value and the error together:
function parseJson<T>(input: string): { data: T } | { error: string } {
  try {
    return { data: JSON.parse(input) as T };
  } catch (e) {
    return { error: (e as SyntaxError).message };
  }
}

Python

Встроенный модуль `json` в Python выбрасывает `json.JSONDecodeError` (подкласс `ValueError`), когда разбор не удаётся. Объект ошибки содержит номер строки, столбец и описание. Для валидации по схеме стандартный выбор - jsonschema и pydantic; pydantic особенно популярен в проектах FastAPI, потому что валидирует и десериализует JSON в типизированные Python-объекты за один шаг.

import json

def is_valid_json(text: str) -> bool:
    try:
        json.loads(text)
        return True
    except json.JSONDecodeError as e:
        print(f"Invalid JSON at line {e.lineno}, col {e.colno}: {e.msg}")
        return False

Командная строка

На любой системе с установленным Python команда `python3 -m json.tool input.json` валидирует и красиво форматирует JSON-файл одной командой. Код выхода ненулевой при сбое, что делает её подходящей для shell-скриптов и CI-конвейеров. Инструмент `jq` - более мощная альтернатива: `jq . input.json` валидирует и форматирует, а `jq 'empty' input.json` валидирует без вывода.

# Validate and pretty-print with Python (built-in, no install)
python3 -m json.tool input.json

# Validate silently with jq (exit code 0 = valid, 1 = invalid)
jq empty input.json && echo "Valid" || echo "Invalid"

# Validate multiple files with a loop
for f in *.json; do
  jq empty "$f" && echo "$f: valid" || echo "$f: INVALID"
done

Стандартная валидация JSON покрывает файлы `.json` и API-payload. Но JSON встречается и в других форматах со своими требованиями к валидации - форматах, где стандартный JSON-парсер либо выдаёт неверные результаты, либо отклоняет весь вход.

JSONL и NDJSON (JSON Lines)

Файлы JSON Lines (`.jsonl`) содержат один JSON-объект на строку без объемлющего массива. Этот формат стандартен для лог-файлов, ML-датасетов и стриминговых API. Стандартный JSON-парсер отклонит JSONL-файл, потому что файл целиком не является валидным JSON-документом - каждую строку нужно разбирать отдельно. Валидатор и исправитель JSON Lines валидирует каждую строку по отдельности, сообщает, в каких номерах строк есть ошибки, и предлагает безопасные автоправки для частых проблем форматирования.

JSON с дублирующимися ключами

Спецификация JSON технически допускает дублирующиеся ключи в объектах, но поведение не определено - разные парсеры обрабатывают это по-разному. `json.loads()` в Python сохраняет последнее значение; некоторые парсеры - первое; иные выбрасывают ошибку. На практике дублирующиеся ключи почти всегда баг - неудачное слияние или ошибка шаблонизации. Детектор дублирующихся ключей JSON находит все повторяющиеся ключи и точно сообщает, где они встречаются.

JSON в YAML-конфигурационных файлах

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

Провалидировать JSON один раз перед важной операцией - хорошо. Встроить валидацию в каждую точку, где JSON входит или выходит из вашей системы, - лучше. Эти практики применимы, строите ли вы API, обрабатываете data-пайплайны или управляете конфигурационными файлами.

Валидируйте на приёме, а не на потреблении

Правильный момент для валидации JSON - когда он впервые входит в вашу систему: на границе API, в обработчике загрузки файлов, в консьюмере очереди сообщений. Валидация на потреблении (в функции, которая читает значение в глубине вашего кода) означает, что невалидные данные распространяются дальше до сбоя, и ошибку труднее отследить. Валидируйте рано и отклоняйте невалидный ввод на входной точке.

Используйте схему, а не только проверку синтаксиса

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

Обрабатывайте ошибки валидации явно

Вызов `JSON.parse()` в try/catch, который глотает ошибку и возвращает null, хуже, чем отсутствие валидации, - он прячет проблему. Когда валидация JSON проваливается, логируйте ошибку с источником ввода, точным сообщением об ошибке и достаточным контекстом для воспроизведения. Возвращайте вызывающему осмысленную ошибку, а не пустой результат, который вызовет вторичную ошибку в другом месте.

• Логируйте сырой ввод - когда валидация JSON падает в продакшене, сырой ввод - самый ценный артефакт для отладки. Логируйте усечённую версию (первые 500 символов) вместе с ошибкой.
• Включайте контекст источника - отмечайте, откуда пришёл JSON: какой эндпоинт API, какой файл, какое сообщение очереди. Это превращает общий ошибку разбора в действенный инцидент.
• Настройте алерты на сбои разбора - всплеск ошибок валидации JSON часто сигнализирует о ломающем изменении в апстрим-API или о деплое, привнёсшем баг сериализации.
• Тестируйте невалидными входами - включите невалидный JSON (висячая запятая, пропущенная кавычка, неверный тип) в тест-сьют, чтобы убедиться, что обработка ошибок работает корректно.