Разработка и Конфигурация · 11 мин
Непредвиденный символ при чтении JSON в 1С: как найти и исправить ошибку
Ошибка «Непредвиденный символ при чтении JSON» в 1С: главные причины, как найти проблемный символ, исправить код и обезопасить обмен данными. Пошаговая инструкция.
Ошибка «Непредвиденный символ при чтении JSON» возникает в 1С, когда метод ПрочитатьJSON получает строку, которая не соответствует формату JSON. Платформа ожидает строгую структуру — фигурные или квадратные скобки, кавычки, запятые — и прерывает разбор на первом символе, который нарушает правила. При этом текст ошибки обычно содержит позицию символа, что позволяет быстро локализовать проблему.
На практике чаще всего причина не в самом JSON, а в том, что вместо него пришло совсем другое содержимое: HTML-страница ошибки веб-сервера, пустой ответ, текст в неверной кодировке или обрезанный фрагмент. Поэтому диагностику стоит начинать не с поиска «битой» запятой, а с проверки того, что реально вернул источник данных.
Ошибка типична для обменов с веб-сервисами, HTTP-API, загрузки файлов от контрагентов, интеграций с сайтами и банками. Ниже разобраны основные причины, способы найти проблемный символ, варианты исправления кода и меры защиты от повторения сбоя.
Что означает ошибка и где она возникает
Метод ПрочитатьJSON(ЧтениеJSON) разбирает текст посимвольно. Как только парсер встречает символ, который не может стоять в данной позиции по спецификации JSON, он выбрасывает исключение вида «Непредвиденный символ при чтении JSON: позиция N». Позиция отсчитывается от начала строки, начиная с единицы.
Типичные места возникновения: обработка ответа HTTPСоединение.Получить(), чтение файла обмена через ЧтениеJSON, разбор текста из регистра сведений или константы, загрузка настроек интеграции. Если ошибка появляется периодически, почти всегда виноват источник: сервер иногда отдаёт страницу с ошибкой вместо данных.
Основные причины появления ошибки
Первая и самая частая причина — вместо JSON пришёл HTML. Веб-сервер при ошибке 404, 500 или при истёкшей авторизации возвращает страницу, начинающуюся с <html> или <!DOCTYPE. Парсер падает на первом же символе «<», и позиция в ошибке обычно равна 1.
Вторая причина — BOM (метка порядка байтов) в начале файла. Файл, сохранённый в UTF-8 with BOM, начинается со служебных байтов, которые при чтении превращаются в невидимый символ. Внешне строка выглядит корректно, но разбор падает на позиции 1.
Третья группа причин — нарушения синтаксиса: одинарные кавычки вместо двойных, лишняя запятая перед закрывающей скобкой, незакрытая скобка из-за обрезанного ответа, неэкранированные кавычки и переводы строк внутри значений. Такое бывает, когда JSON формируется вручную конкатенацией строк, а не через ЗаписьJSON.
Четвёртая причина — неверная кодировка. Если сервер отдаёт текст в windows-1251, а 1С читает его как UTF-8 (или наоборот), кириллица превращается в «кракозябры», а служебные байты могут попасть на позицию, где ожидается структурный символ.
Скорее всего пришёл HTML, пустая строка или BOM — проверьте начало ответа
Ищите лишнюю запятую, одинарные кавычки или неэкранированный символ
Сервер иногда отдаёт страницу ошибки — логируйте код HTTP-ответа
Ответ не дочитан или файл усечён — проверьте размер и целостность
Как найти проблемный символ
Первый шаг — увидеть фактическое содержимое строки до вызова ПрочитатьJSON. Временно добавьте вывод текста в сообщение или запись в журнал регистрации. Если строка длинная, выведите первые 200–300 символов и фрагмент вокруг позиции из текста ошибки.
Функция Сред(ТекстОтвета, Позиция - 20, 40) покажет контекст вокруг сбойного места. Часто там обнаруживается лишняя запятая, одинарная кавычка или незакрытый тег. Для невидимых символов полезно проверить коды: КодСимвола(Текст, Позиция) — BOM даст код 65279, перевод строки — 10, неразрывный пробел — 160.
Если данные приходят по HTTP, обязательно проверьте Ответ.КодСостояния до разбора. Код 200 не гарантирует JSON, но коды 4xx и 5xx почти всегда означают, что в теле ответа — страница ошибки, а не данные.
Если источник данных — внешний сервис
Когда JSON формирует чужая система, возможности исправления ограничены. Проверьте заголовок запроса Accept: application/json — некоторые API без него возвращают HTML или XML. Уточните в документации сервиса кодировку ответа и формат ошибок: многие API при неверном токене отвечают кодом 401 и HTML-страницей.
Полезно зафиксировать проблемный ответ в файл и передать его разработчикам сервиса. Если сервис периодически отдаёт обрезанный JSON при больших выгрузках, запрашивайте данные порциями — это снижает и риск усечения, и нагрузку на соединение.
Как выбрать действие
Проверка результата и профилактика
После исправления прогоните обмен на проблемном пакете данных и на типовом. Убедитесь, что разбор проходит, все ожидаемые поля присутствуют в структуре, а журнал регистрации не содержит новых ошибок. Для интеграций, работающих по расписанию, оставьте логирование первых символов ответа хотя бы на период наблюдения.
Профилактика сводится к трём правилам: всегда проверять код состояния HTTP до разбора, никогда не собирать JSON конкатенацией строк и обрабатывать исключение ПрочитатьJSON с записью контекста в журнал. Это превращает непонятный сбой в диагностируемую ситуацию.
Как проверить результат
ПрочитатьJSON отрабатывает без исключения, структура заполнена
Исключение повторяется на том же или новом символе
Все ожидаемые поля на месте, типы значений корректны
Поля отсутствуют или пришли строками вместо чисел
Нет ошибок обмена за период наблюдения
Периодические ошибки с HTML в начале ответа
Всегда 200 (или иной успешный код по документации API)
Встречаются 401, 403, 500 — значит, проблема в доступе или сервере
Что важно запомнить
Ошибка «Непредвиденный символ при чтении JSON» почти всегда означает, что в ПрочитатьJSON попало не-JSON-содержимое: HTML-страница, BOM, текст в другой кодировке или обрезанный ответ. Диагностируйте по позиции символа и первым знакам строки, проверяйте код HTTP-ответа до разбора, формируйте JSON только через ЗаписьJSON и всегда логируйте контекст ошибки.
Частые вопросы
Ошибка указывает позицию 1, но строка выглядит нормально. Что делать?
Почти наверняка в начале строки стоит невидимый символ — чаще всего BOM (код 65279). Проверьте КодСимвола(Текст, 1) и удалите символ через СтрЗаменить. Если файл читается с диска, используйте ЧтениеТекста с явной кодировкой UTF-8.
Можно ли заставить 1С игнорировать ошибки и прочитать «почти правильный» JSON?
Штатного «мягкого» режима у ПрочитатьJSON нет — любой синтаксический сбой вызывает исключение. Правильный путь — исправить формирование данных на стороне источника. Костыльные замены символов допустимы только как временная мера и с обязательным контролем результата.
Ошибка возникает только при больших объёмах данных. В чём причина?
Вероятно, ответ обрезается: по таймауту соединения, ограничению прокси или сервера. Признак — сбойная позиция находится в самом конце строки. Решения: разбить выгрузку на порции, увеличить таймаут HTTPСоединения, проверить настройки веб-сервера.
Как отличить ошибку в данных от ошибки в моём коде?
Сохраните проблемную строку и проверьте её в любом валидаторе JSON. Если валидатор тоже ругается — проблема в данных, код ни при чём. Если валидатор говорит, что JSON корректен, проверьте кодировку чтения и наличие BOM — возможно, строка искажается до вызова ПрочитатьJSON.
Одинарные кавычки в JSON допустимы?
Нет. Спецификация JSON требует двойные кавычки для строк и имён свойств. Одинарные кавычки — частая ошибка при ручной сборке или при передаче данных из JavaScript-объектов, где они допустимы. Такой текст нужно исправлять на стороне источника, а не в 1С.
Нужно ли проверять код состояния HTTP, если обмен раньше работал?
Да. Сервис может начать требовать авторизацию, изменить адрес API или периодически отдавать ошибки под нагрузкой — и вместо JSON вы получите HTML. Проверка кода состояния до разбора занимает одну строку и снимает большинство «внезапных» сбоев разбора.