Ошибка «Непредвиденный символ при чтении JSON» в 1С: как найти причину и исправить

Ошибка «Непредвиденный символ при чтении JSON» возникает в 1С в момент вызова метода ПрочитатьJSON (или при выполнении ЗначениеИзСтрокиJSON, ПрочитатьВJSON) и означает, что переданная строка не соответствует формату JSON: парсер встретил символ, которого по правилам формата в этой позиции быть не должно. Это одна из самых частых ошибок при интеграциях с веб-сервисами, API банков, маркетплейсами и обмене данными между базами.

Проблема почти всегда находится не в коде 1С, а в самих данных: лишняя запятая, обрезанный ответ сервера, текст ошибки вместо JSON, «мусорные» символы в начале строки или неверная кодировка. Поэтому исправление начинается с анализа содержимого строки, а не с переписывания обработчика.

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

Что означает ошибка и где она возникает

Встроенный парсер JSON в платформе 1С строго следует спецификации формата. Валидный JSON начинается либо с фигурной скобки { (объект), либо с квадратной скобки [ (массив), либо с литералов true, false, null или числа. Любой другой символ на старте — «непредвиденный».

Также ошибка возникает внутри структуры: когда после значения парсер ждёт запятую или закрывающую скобку, а встречает что-то иное. Типичный текст сообщения содержит позицию символа, например: «Непредвиденный символ при чтении JSON (позиция 1)» — это ключевая подсказка для диагностики.

Чаще всего с ошибкой сталкиваются в сценариях: получение ответа от HTTP-сервиса через HTTPСоединение, загрузка файлов обмена, чтение настроек из JSON-файла, обработка данных от внешних компонент и веб-хуков.

Шаг 1. Посмотрите на сырую строку до парсинга

Первое и главное действие — вывести содержимое строки, которую вы передаёте в ПрочитатьJSON, до вызова метода. В девяти случаях из десяти причина видна невооружённым глазом.

Ответ = Соединение.Получить(Запрос);
ТелоОтвета = Ответ.ПолучитьТелоКакСтроку();

// Диагностика ДО парсинга
Сообщить("Код состояния: " + Ответ.КодСостояния);
Сообщить("Первые 500 символов: " + Лев(ТелоОтвета, 500));

ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(ТелоОтвета);
Данные = ПрочитатьJSON(ЧтениеJSON);

Обратите внимание на первые символы. Если строка начинается с <html>, <!DOCTYPE, слов вроде «Bad Request», «Unauthorized», «Proxy Error» — сервер вернул не JSON, а страницу ошибки. Парсер справедливо сообщает о непредвиденном символе на первой же позиции.

Если строка пустая — ошибка будет той же. Пустой ответ типичен при обрыве соединения, неверном URL или когда сервер отвечает только кодом состояния без тела.

1. 1
   Выведите в журнал регистрации или сообщением код состояния HTTP и первые 200–500 символов тела ответа
2. 2
   Проверьте первый символ: это должна быть {, [, цифра или литерал true/false/null
3. 3
   Если указана позиция ошибки — извлеките фрагмент строки вокруг неё через Сред() и найдите проблемный символ
4. 4
   Проверьте строку в любом онлайн-валидаторе JSON — он точно укажет место ошибки
5. 5
   Исправьте источник данных или очистите строку, затем повторите парсинг

Шаг 2. Устраните типовые причины по сценариям

Сервер вернул HTML или текст ошибки вместо JSON

Самая частая ситуация при работе с внешними API. Причины: неверный URL, истёкший токен авторизации, блокировка по IP, ошибка на стороне сервера. Вместо JSON приходит страница с описанием проблемы.

Правильное решение — проверять код состояния и заголовок Content-Type до разбора тела:

Если Ответ.КодСостояния <> 200 Тогда
ВызватьИсключение "Сервис вернул код " + Ответ.КодСостояния
+ ": " + Лев(Ответ.ПолучитьТелоКакСтроку(), 300);
КонецЕсли;

Так вы замените непонятную ошибку парсера на осмысленное сообщение, которое сразу укажет на реальную причину.

Символ BOM и лишние символы в начале строки

При чтении JSON из файла в начале строки может оказаться метка порядка байтов (BOM) или управляющие символы. Парсер воспринимает их как непредвиденный символ на позиции 1. Удалите их перед разбором:

// Убираем BOM и непечатаемые символы в начале
Пока СтрДлина(ТелоОтвета) > 0 И КодСимвола(Лев(ТелоОтвета, 1)) < 32 Цикл
ТелоОтвета = Сред(ТелоОтвета, 2);
КонецЦикла;
ТелоОтвета = СтрЗаменить(ТелоОтвета, Символ(65279), ""); // BOM UTF-8

Неэкранированные кавычки и спецсимволы внутри значений

Если JSON формируется вручную конкатенацией строк (так делать не стоит, но в старых обменах это встречается), значения с кавычками, обратными слэшами или переносами строк ломают структуру. Например, наименование товара Кабель "ВВГ" 3х2.5 без экранирования делает JSON невалидным.

Надёжное исправление — формировать JSON только штатными средствами платформы: ЗаписьJSON и ЗаписатьJSON автоматически экранируют все спецсимволы. Никогда не собирайте JSON строковыми операциями.

Обрезанный ответ и неверная кодировка

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

Проблемы кодировки проявляются, когда сервер отвечает в UTF-8, а строка читается как Windows-1251: кириллица превращается в «кракозябры», а в отдельных случаях ломается структура. Указывайте кодировку явно при чтении файла через ЧтениеТекста с параметром КодировкаТекста.UTF8, а при HTTP-запросах проверяйте заголовок Content-Type.

Шаг 3. Защитите код от повторения ошибки

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

Функция ПолучитьДанныеИзJSON(ТелоОтвета)
Если Не ЗначениеЗаполнено(ТелоОтвета) Тогда
ВызватьИсключение "Пустой ответ сервиса";
КонецЕсли;

ПервыйСимвол = Лев(СокрЛ(ТелоОтвета), 1);
Если ПервыйСимвол <> "{" И ПервыйСимвол <> "[" Тогда
ВызватьИсключение "Ответ не является JSON: "
+ Лев(ТелоОтвета, 200);
КонецЕсли;

Попытка
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(ТелоОтвета);
Возврат ПрочитатьJSON(ЧтениеJSON);
Исключение
ЗаписьЖурналаРегистрации("Обмен.JSON",
УровеньЖурналаРегистрации.Ошибка, , ,
ОписаниеОшибки() + " | Фрагмент: " + Лев(ТелоОтвета, 500));
ВызватьИсключение;
КонецПопытки;
КонецФункции

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

Как проверить, что проблема решена

После исправления прогоните обмен на том же наборе данных, на котором возникала ошибка. Успешный признак — ПрочитатьJSON возвращает структуру или соответствие без исключения, а ключевые поля содержат ожидаемые значения, а не обрезанные или «битые» строки.

Дополнительно проверьте граничные случаи: записи с кавычками и спецсимволами в наименованиях, кириллицу, длинные тексты, пустые ответы и ответы с кодом ошибки. Именно на них ошибка обычно всплывает повторно спустя время.

Контрольные точки

Как проверить результат

Разбор ответа

Норма

ПрочитатьJSON отрабатывает без исключения на реальных данных

Тревожный признак

Ошибка повторяется на тех же или новых записях

Значения полей

Норма

Кириллица, кавычки и спецсимволы читаются корректно

Тревожный признак

Кракозябры, обрезанные строки, потерянные фрагменты

Поведение при сбое сервиса

Норма

Код состояния не 200 — выводится понятное сообщение с кодом и фрагментом ответа

Тревожный признак

По-прежнему падает «Непредвиденный символ» без деталей

Журнал регистрации

Норма

При ошибках фиксируется фрагмент проблемных данных

Тревожный признак

Ошибки видны только пользователю и теряются

Типичные ошибки при исправлении

Отдельно выделим антипаттерн «глотания» ошибки: конструкция Попытка ... Исключение КонецПопытки; без логирования и оповещения превращает сбой обмена в тихую потерю данных. Если обмен загружает заказы или оплаты, последствия обнаружатся только при сверке — с уже устаревшими данными.

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

Почему ошибка возникает только на некоторых записях, а не на всех?

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

Что означает позиция символа в тексте ошибки?

Это порядковый номер символа в строке, на котором парсер остановился. Извлеките фрагмент функцией Сред(Строка, Позиция - 50, 100) и посмотрите, что находится вокруг: чаще всего это лишняя запятая перед закрывающей скобкой, незакрытая кавычка или неожиданный текст. Позиция 1 означает, что строка вообще не похожа на JSON.

Можно ли отличить JSON от HTML программно до разбора?

Да. Возьмите первый непустой символ строки: для JSON это {, [, цифра или начало литералов true/false/null. Символ < почти наверняка означает HTML-страницу. Дополнительно проверяйте заголовок ответа Content-Type: для JSON он обычно содержит application/json, для страницы ошибки — text/html.

Почему JSON из файла не читается, хотя в блокноте выглядит нормально?

Типичные причины — метка BOM в начале файла, неверная кодировка при чтении или невидимые управляющие символы. Читайте файл через ЧтениеТекста с явным указанием кодировки (обычно UTF-8), удалите символ с кодом 65279 и проверьте файл в онлайн-валидаторе JSON — он покажет точное место проблемы.

Как безопасно формировать JSON в 1С, чтобы не было ошибок у получателя?

Используйте объект ЗаписьJSON с методами ЗаписатьНачалоОбъекта, ЗаписатьСвойство, ЗаписатьЗначение или функцию ЗаписатьJSON для сериализации структур и соответствий. Эти механизмы автоматически экранируют кавычки, слэши и спецсимволы. Ручная сборка JSON через конкатенацию строк — главный источник невалидных документов.

Ошибка появляется при больших ответах, на маленьких всё работает. В чём дело?

Вероятно, ответ обрывается: соединение разрывается по таймауту, сервер обрезает тело или чтение из потока завершается раньше конца. Проверьте, что последние символы строки — это корректное закрытие структуры (} или ]), увеличьте таймаут соединения и убедитесь, что тело читается целиком, а не фиксированным буфером.