Как убрать ошибку «Формат потока» в 1С 8.3: разбор по шагам

Первое, что проверяют при «Ошибке формата потока» в 1С, — локальный кэш конфигурации. Закройте программу и удалите временные папки платформы в профиле пользователя: %LOCALAPPDATA%\1C\1cv8\ и %APPDATA%\1C\1cv8\. В большинстве случаев после входа база снова открывается — кэш пересобирается с нуля.

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

Отчего возникает ошибка формата потока

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

• 🗂 Повреждённый кэш конфигурации. Временные файлы платформы в профиле пользователя. Самая частая причина, когда ошибка вылетает при входе в базу или при открытии формы.
• 💽 Повреждение файла базы .1CD (файловый вариант). Сбой диска, аварийное выключение компьютера во время записи, переполнение диска.
• 📎 Битый внешний файл — отчёт или обработка .epf / .erf, файл сохранённых настроек, выгруженный несовместимой версией платформы.
• 🔁 Повреждённый или неполный файл обмена (XML, JSON) — выгрузка оборвалась или сделана другой версией правил обмена.
• 🧩 Несовпадение версий платформы между тем, кто сохранял файл, и тем, кто его открывает.
• 🌐 Нестабильная сеть у файловой базы по локальной сети. Если .1CD лежит в общей папке, а работают с ней по сети, обрыв связи в момент записи повреждает файл или кэш. Файловый вариант по сети — отдельный источник таких сбоев.

Важно: сама по себе ошибка не говорит, какой файл повреждён. Поэтому лечение начинается не с кнопки «Исправить», а с диагностики — где платформа читает сбойный поток.

С чего начать: ищем источник сбоя

Задайте себе один вопрос: когда именно появляется ошибка? Ответ почти всегда указывает на виновника.

• Ошибка при запуске у всех пользователей одной базы → повреждена база или общий ресурс.
• Ошибка только у одного пользователя, у остальных вход нормальный → его локальный кэш.
• Ошибка при открытии конкретного отчёта или обработки → внешний файл .epf / .erf.
• Ошибка при загрузке или выгрузке данных → файл обмена.
• Ошибка при печати или сохранении настройки → повреждён макет печатной формы или сохранённая настройка отчёта.

Этот разбор экономит часы: нет смысла тестировать базу на три гигабайта, если проблема в одной внешней обработке.

Второй источник подсказок — полный текст ошибки на экране. Платформа часто пишет имя файла, строку правил обмена или объект, на котором споткнулась. Нажмите «Подробнее» в окне ошибки и прочитайте нижние строки: если в них видно имя внешней обработки или путь к файлу обмена — вы уже знаете, где искать. Если же в тексте фигурирует внутренний путь кэша в профиле пользователя, причина почти наверняка во временных файлах платформы.

Файловая база: чистим кэш и проверяем .1CD

Для файлового варианта (база лежит файлом 1Cv8.1CD) порядок такой — от безопасного к глубокому.

1. Очистите кэш. Закройте все окна 1С и удалите папки конкретной базы внутри %LOCALAPPDATA%\1C\1cv8\ и %APPDATA%\1C\1cv8\. Имя папки — длинный хэш, по одному каталогу на каждую базу. Удаление кэша не трогает данные: слетают только локальные настройки интерфейса и форм, они пересоберутся.

2. Проверьте физическую целостность файла. Если кэш ни при чём, запустите утилиту chdbfl.exe из каталога платформы, например C:\Program Files\1cv8\<номер версии>\bin\chdbfl.exe. Укажите путь к 1Cv8.1CD, поставьте флажок «Исправлять обнаруженные ошибки» и запустите проверку.

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

3. Проверьте логическую целостность. Откройте базу в Конфигураторе и запустите Администрирование → Тестирование и исправление. Этот инструмент чинит уже не байты файла, а внутренние ссылки и объекты. Запускается монопольно — других пользователей в базе быть не должно.

4. Восстановитесь из копии. Если база не чинится, загрузите последнюю резервную копию: Администрирование → Загрузить информационную базу для файла .dt либо подмените 1Cv8.1CD из бэкапа каталога.

Клиент-серверная база: кэш клиента и работа на сервере

В клиент-серверном варианте (база в СУБД, работает сервер 1С) логика та же, но «этажей» больше.

Кэш на стороне клиента живёт у каждого пользователя отдельно — в тех же папках %LOCALAPPDATA%\1C\1cv8\ и %APPDATA%\1C\1cv8\ на его машине. Если ошибка у одного-двух человек, начните с их кэша, сервер трогать не нужно.

Кэш и сеансовые данные на сервере лежат в рабочем каталоге сервера (srvinfo). Чистить его можно только при остановленной службе агента сервера ragent.

Саму базу в СУБД утилитой chdbfl.exe не чинят — она только для файловых .1CD. Для серверной базы доступны два пути:

• Логическую целостность — через Администрирование → Тестирование и исправление в Конфигураторе (монопольно).
• Физическую целостность хранилища — средствами самой СУБД или восстановлением из резервной копии базы данных SQL.

Если ошибка привязана к одному зависшему сеансу, его можно завершить через консоль администрирования серверов — она обращается к кластеру через агент. Из командной строки список и завершение сеансов делают утилитой rac; точные команды смотрите в справке rac help, чтобы не ошибиться с синтаксисом конкретной версии.

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

Ошибка при обмене данными и внешних файлах

Отдельный большой класс — «Ошибка формата потока» при загрузке файла обмена, внешней обработки или .dt.

Файл обмена (XML, JSON). Откройте выгрузку обычным текстовым редактором. Нормальный XML начинается с <?xml version=... и не обрывается на середине тега. Если файл пустой, короткий или заканчивается посреди строки — выгрузка прервалась, его нужно сформировать заново.

Вторая причина — несовпадение версий формата. При обмене через ЕnterpriseData (УниверсальныйФормат) выгрузка и загрузка должны идти совместимыми версиями формата и правил. Файл, собранный старой версией конфигурации, новая может не принять.

• Перевыгрузите данные из базы-источника заново.
• Сверьте версии правил обмена в обеих базах.
• Проверьте, что при передаче (почта, диск, сеть) файл не «обрезался».

Обратите внимание и на кодировку: файл обмена 1С обычно в UTF-8. Если его открывали и пересохраняли сторонним редактором в другой кодировке или добавили лишние символы в начало, загрузка упадёт. Сравните размер файла у отправителя и получателя — расхождение в байтах прямо укажет на потерю данных при пересылке.

Внешние отчёты и обработки (.epf, .erf). Если формат потока вылетает при открытии конкретной обработки — файл повреждён либо сохранён платформой другой версии. Возьмите исходный, заведомо рабочий экземпляр у поставщика обработки. Открывать .epf лучше той же версией платформы, в которой он создавался, или более новой. Если обработка хранится в справочнике дополнительных отчётов и обработок внутри базы, перезагрузите её туда из исходного файла заново — запись в справочнике могла повредиться вместе с кэшем.

Выгрузка .dt. Если резервная копия .dt не загружается с той же ошибкой — сам файл выгрузки повреждён или сделан несовместимой версией. Возьмите другую копию или восстановитесь из копии каталога базы.

Как не поймать ошибку снова

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

• 💾 Делайте резервные копии регулярно и автоматически: выгрузка .dt плюс копия каталога для файловой базы, бэкап SQL — для серверной. Копия нужна не «когда-нибудь», а по расписанию.
• 🔌 Не выключайте компьютер и сервер аварийно во время работы 1С. Для сервера — источник бесперебойного питания: обрыв записи базы на диск и даёт битый поток.
• 📉 Следите за свободным местом на диске с базой. Переполнение в момент записи повреждает .1CD.
• 🛡 Исключите каталоги баз и кэша из активной проверки антивирусом. Он иногда блокирует или подменяет файлы платформы, и чтение срывается на формате потока.
• ⬆️ Открывайте файлы и базы совместимой версией платформы. Не держите «зоопарк» версий 1С на разных машинах, работающих с одной базой.
• 🧹 Периодически чистите кэш планово, не дожидаясь ошибки. Раз в пару месяцев удалённые временные папки платформы — дешёвая профилактика, особенно на машинах, где 1С часто обновляется.

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

Чего нельзя делать при восстановлении

Половина проблем при лечении этой ошибки — от резких движений. Вот что только навредит.

• ❌ Удалять саму базу вместо кэша. Чистят папки в AppData — временные файлы. Каталог с 1Cv8.1CD трогать нельзя, в нём данные.
• ❌ Гонять chdbfl.exe по серверной базе. Утилита работает только с файловыми .1CD. Для базы в СУБД она бесполезна.
• ❌ Запускать Тестирование и исправление без копии. Режимы с удалением «битых» объектов могут вычистить нужные данные. Сначала резервная копия, потом исправление.
• ❌ Править XML обмена руками «на глаз». Проще и надёжнее перевыгрузить файл из источника, чем дописывать теги вручную.
• ❌ Чистить серверный кэш и перезапускать службу среди рабочего дня. Вы оборвёте сеансы всем. Это операция для технологического окна.