Ситуация, когда основная база данных (файл 1Cv8.1CD) безвозвратно удалена, а резервные копии отсутствуют или неактуальны, является критической для любого разработчика. Однако, если база хотя бы раз запускалась на компьютере пользователя, в системе остается так называемый пользовательский кэш. В этой статье мы подробно разберем, можно ли извлечь конфигурацию из этих остаточных файлов и как это сделать технически.
Прежде всего, проанализируем, где именно 1С хранит временные данные. Многие ошибочно полагают, что вся информация сосредоточена в файле cache.1CD. На самом деле, этот файл чаще всего содержит лишь служебные индексы или настройки связи. Основной интерес для нас представляет содержимое каталогов по пути: %AppData%\Local\1C\1Cv8\<GUID>.
Рассмотрим структуру этого каталога. Внутри него находится папка Config. Именно здесь платформа 1С сохраняет фрагменты конфигурации для ускорения последующих запусков. Давайте выясним причину, почему обычные средства восстановления, такие как Tool_1CD, здесь бессильны. Проблема в том, что в кэше конфигурация не хранится в виде единого файла (как привычный нам .cf), а «размазана» по тысячам мелких файлов без расширений. Имена этих файлов — это внутренние идентификаторы объектов (GUID).
Разберем типичные ошибки, которые совершают пользователи при попытке восстановить данные из кэша:
Посмотрим на ситуацию с точки зрения структуры данных. Файлы в папке Config представляют собой сжатые блоки. Платформа 1С использует алгоритм дефляции (zlib). Если мы проанализируем файл через HEX-редактор, то увидим характерные заголовки. Наша задача — найти эти фрагменты и распаковать их.
Рассмотрим пошагово процесс поиска текстов модулей и описаний форм:
Перейдем в папку %AppData%\Local\1C\1Cv8\... и найдем подпапку Config. Нас интересуют файлы, созданные или измененные в момент последнего успешного сеанса работы с удаленной базой. Проанализируем их размер: файлы модулей и форм обычно имеют размер от нескольких килобайт до нескольких мегабайт.
Выясним, как отличить полезный файл от мусора. Почти все файлы в Config — это упакованные «потоки» 1С. Если вы откроете такой файл в HEX-редакторе, в самом начале вы не увидите понятного текста. Однако после распаковки заголовка (который содержит информацию о версии потока) начинаются данные.
Для восстановления нам потребуется инструмент, способный работать с форматом файлов 1С. Поскольку готовой кнопки «Восстановить всё» не существует, разберем логику работы скрипта для распаковки:
// Пример логики на языке 1С (для внешней обработки)
// Предположим, мы читаем файл из кэша
Чтение = Новый ЧтениеДанных(ПутьКФайлуКэша);
// Файлы 1С часто упакованы со смещением
// Нужно найти начало блока zlib (обычно 78 9C или 78 DA)
// И применить распаковку
Если автоматизация невозможна, можно использовать утилиты типа v8unpack или специализированные парсеры, которые умеют «разбирать» составные файлы 1С. После распаковки вы получите текстовые файлы в формате XML (для форм) или обычный текст (для модулей).
Выясним важный нюанс: модули в кэше могут храниться в двух видах: исходный текст и скомпилированный байт-код. Если в исходной конфигурации не была установлена защита (пароль на модуль) и не было выполнено удаление исходных текстов при поставке, то в кэше с большой вероятностью сохраняются полные тексты модулей ActiveDocument.
Проанализируем структуру извлеченного текста. Вы увидите привычные конструкции:
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Ваш код, который был в удаленной базе
КонецПроцедуры
К сожалению, восстановить файл .cf целиком одной командой не получится. После извлечения фрагментов нам придется выполнить следующие действия:
Рассмотрим эффективный метод поиска нужных файлов в кэше, если их тысячи. Используйте любой инструмент поиска в файлах (например, Total Commander или специализированные утилиты для разработчиков), который умеет искать внутри файлов. Ищите уникальные строки, которые точно были в вашем коде (например, специфические названия переменных или комментарии). Если кэш не зашифрован и не сжат слишком агрессивно, вы быстро найдете GUID-файлы, содержащие ваш код.
Подведем итог нашего анализа. Восстановление из кэша — это трудоемкий процесс ручного разбора дампов памяти и временных файлов. Это оправдано только в том случае, если разработка была уникальной и на её повторное написание уйдет больше времени, чем на HEX-анализ папки Config.
Важные выводы:
Local, а не только в Roaming.zlib.Tool_1CD бесполезен для работы с кэшем.Config.В будущем, чтобы избежать подобных ситуаций, настоятельно рекомендуем настроить автоматическое резервное копирование или использовать системы контроля версий (Git/SVN) даже для самых маленьких и «почти пустых» баз.