JSON часто встречается в задачах 1С как формат обмена с внешним сервисом, сайтом или промежуточной системой. Чтение файла кажется простой операцией, но успешный разбор ещё не означает, что данные пригодны для учёта. Практическая работа состоит из нескольких этапов: проверить источник, прочитать файл, разобрать структуру, обработать ошибки и провалидировать результат. Ниже разберём эту последовательность. Имена объектов, методов и доступные настройки зависят от версии платформы и конфигурации, поэтому примеры нужно сверять с синтаксис-помощником.

Содержание

Подготовка к чтению JSON-файла

Перед чтением опишите источник: существует ли файл, доступен ли он на чтение, не пуст ли он, каков его размер и ожидаемая структура. Для JSON распространена кодировка UTF-8, но BOM и настройки чтения текста могут повлиять на результат, поэтому кодировку лучше подтвердить на тестовом файле.

Общая логика обычно такая: открыть файл, получить поток, создать объект чтения JSON, начать чтение, разобрать данные, завершить чтение и закрыть файл. Закрытие стоит размещать так, чтобы оно выполнялось и при ошибке. Точные имена методов и параметры проверяйте по документации своей версии.

Разделяйте ошибки ввода-вывода и ошибки разбора. Если файл не найден или недоступен, продолжать разбор обычно бессмысленно. Если повреждён JSON, нужно зафиксировать диагностику и запросить корректный файл. Текст исключения платформы логируют, но не показывают пользователю в сыром виде.

Что представляет собой структура после разбора

JSON состоит из объектов, массивов, строк, чисел, логических значений и null. После разбора эти конструкции представляются коллекциями и примитивами. Не стоит заранее считать, что JSON-объект обязательно станет структурой или соответствием: фактический тип зависит от способа чтения и версии. Его полезно проверять, например через ТипЗнч(), и уже потом выбирать способ доступа.

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

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

Типичные риски структуры удобно свести в короткий перечень:

  • отсутствует ожидаемое свойство;
  • вместо строки пришло null или число;
  • вместо массива пришла строка;
  • вложенность отличается от ожидаемой;
  • большое число теряет точность или дата пришла в неожиданном формате.

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

Уровни ошибок и реакция на них

Первый уровень связан с доступом к файлу: файл отсутствует, путь недоступен, нет прав, файл пуст. Здесь обработку обычно прекращают, записывают диагностику и сообщают ответственному лицу понятный текст. Повторный запрос файла фиксируют в регламенте обмена.

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

Третий уровень, несоответствие структуры: нет обязательного объекта или массива, поле имеет другой тип, вложенность не совпадает с ожиданием. Иногда можно пропустить некорректную запись и продолжить, иногда нужно остановить загрузку. Если частичная загрузка допустима, ошибки накапливают в списке и показывают в отчёте.

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

Для единообразия удобна функция-обёртка. Она принимает путь или поток, внутри использует Попытка и Исключение, отдельно фиксирует этап чтения и этап разбора и возвращает структуру с признаком успеха, данными и диагностическим сообщением.

Проверка результата и бизнес-валидация

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

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

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

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

Практический сценарий и проверка перед запуском

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

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

Перед запуском обмена полезно пройти по короткому чек-листу:

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

Чек-лист стоит адаптировать под свою задачу. Имена объектов и методов, поддержка кодировок и особенности отображения типов требуют сверки с документацией и проверки на тестовом файле.