«Сломанный» JSON — распространённая проблема: файл выглядит почти правильно, но парсер отказывается его читать. Чаще всего причина в небольших синтаксических отклонениях, которые легко допустить при ручном редактировании или при переносе данных из другого формата.
Типичные причины невалидного JSON
- Лишняя запятая перед закрывающей скобкой —
{"a": 1,}, которую JavaScript толерирует, а строгий JSON-парсер — нет. - Одинарные кавычки вместо двойных — частая ошибка при копировании из объектного литерала JavaScript.
- Незакавыченные ключи —
{name: "Анна"}вместо{"name": "Анна"}. - Комментарии — спецификация JSON не предусматривает их вообще, в отличие от JSON5 или JSONC.
- Обрезанный вывод — если ответ API или файл лога обрезаны на середине, документ остаётся незакрытым.
Запятая как разделитель дробной части — скрытая ловушка
В российской локали дробная часть числа отделяется запятой, а не точкой: цена «1234,50» — привычная запись для выгрузки из 1С или Excel. Если такое число скопировать как есть в JSON, парсер увидит {"price": 1234,50} и споткнётся на второй запятой внутри числа — с точки зрения JSON это не десятичная дробь, а два отдельных, синтаксически некорректно расположенных токена. Инструмент ремонта в такой ситуации не может надёжно понять, где заканчивается число: 1234 или 1234.50, — и это ровно тот случай, когда автоматическое исправление способно незаметно исказить значение.
Как работает автоматическое исправление
Инструмент ремонта JSON применяет эвристики: добавляет отсутствующие кавычки, убирает лишние запятые, закрывает незакрытые скобки на основе контекста. Это хорошо работает для типичных, распространённых ошибок, но не является магией — инструмент не может угадать, какое значение имелось в виду, если данные повреждены серьёзнее.
Границы возможного
Автоматический ремонт исправляет синтаксис, а не семантику. Если в данных пропущено целое поле или значение искажено логически, а не синтаксически, инструмент этого не обнаружит — нужна ручная проверка результата, особенно после переноса чисел из локализованных источников вроде банковских выписок или Excel-таблиц.
Когда ремонт неоднозначен
Некоторые повреждения имеют несколько одинаково правдоподобных исправлений. Например, оборванную строку {"a": 1, "b": 2 можно закрыть просто скобкой — и потерять данные, если на самом деле имелось в виду ещё одно поле. В таких случаях эвристика ремонта делает «наименее разрушительное» предположение, но это догадка, а не гарантия восстановления исходного намерения.