Программы уже нет, а архив остался: как читать проприетарный формат

MAATRIX

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

Сначала — что у вас вообще за файл

Прежде чем искать инструмент для чтения, разберитесь, с чем имеете дело. Смотреть только на расширение — плохая идея: оно может быть переименовано, потеряно при копировании по FAT32 или просто ничего не говорить (.dat, .bin, .001). Правильный первый шаг — посмотреть на сигнатуру файла, то есть на первые байты, которые почти всегда однозначно указывают формат контейнера, даже если внутри — проприетарная структура поверх него.

На Linux или в WSL:

file archiv.dat
xxd archiv.dat | head -5

file определяет тип по базе сигнатур (magic numbers) — иногда прямо назовёт формат («dBase III data file», «Microsoft Access Database», «SQLite 3.x database»), иногда просто скажет «data», и тогда смотрите на xxd руками. Несколько сигнатур, которые стоит запомнить:

Если в начале файла видно PK (это 50 4B в hex) — почти наверняка внутри zip-контейнер, и его можно распаковать обычным архиватором даже без родной программы: unzip -l archiv.dat покажет список файлов внутри, и часто там обнаруживаются XML или текстовые метаданные, которые читаются напрямую. Многие «проприетарные» форматы 2000–2020-х годов — это на самом деле zip или OLE2 с частной схемой внутри, и это сильно упрощает задачу.

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

Поиск альтернативной программы для чтения

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

Что стоит проверить по порядку:

• Универсальные конвертеры документов и таблиц. Для старых текстовых и табличных форматов (WordPerfect, старые версии Lotus 1-2-3, Quattro Pro, старые CAD-форматы) часто помогает LibreOffice — у него исторически широкий список импортируемых форматов, шире, чем у современного MS Office. Стоит попробовать Файл → Открыть даже для расширений, которые LibreOffice явно не рекламирует как поддерживаемые — движок импорта иногда угадывает формат по содержимому.
• Специализированные форензик- и архивные утилиты. Для баз данных старых бухгалтерских и учётных систем существуют независимые утилиты чтения, написанные сторонними разработчиками именно потому, что клиенты этих систем регулярно оказываются в вашей ситуации. Ищите по названию формата или производителя плюс слова «viewer», «reader», «export tool» — но об осторожности при скачивании таких утилит ниже.
• Форумы и сообщества бывших пользователей продукта. Если программа была нишевой (отраслевой CRM, специфичный CAD, узкоспециализированная база), у неё почти наверняка был форум пользователей, и на нём кто-то уже сталкивался с точно такой же проблемой после закрытия вендора. Поиск по названию программы плюс «export» / «migrate» / «read file without» часто выводит на самодельный скрипт или инструкцию.
• Виртуальная машина со старой ОС. Если сама программа существует, но не запускается на современной системе (несовместимость с 64-битной Windows, отсутствующие библиотеки, требование древней версии .NET или Java), проще поднять виртуалку с той ОС, под которую программа писалась, чем искать альтернативный ридер. Это не «поиск альтернативы» в чистом виде, но по трудозатратам часто дешевле, чем разбор бинарного формата с нуля.

Отдельно: если у формата было официальное API или SDK для сторонних разработчиков (даже если сам продукт умер), поищите архив этой документации — например, через веб-архив. Наличие когда-то опубликованного SDK резко повышает шанс, что кто-то уже написал открытый парсер.

Если готового решения нет: разбор по документации формата

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

Где искать:

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

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

1. Откройте файл в hex-редакторе (xxd, hexdump -C, или GUI-редактор вроде HxD/ImHex) и поищите читаемые ASCII-строки — strings archiv.dat часто вытаскивает названия полей, пути, куски текстовых данных прямо из бинарной каши.
2. Найдите заголовок — обычно это первые 16–256 байт с константными «магическими» значениями, версией формата и, часто, смещениями к остальным блокам данных.
3. Если формат содержит повторяющиеся записи одинакового размера (типично для баз данных и каталогов) — определите размер записи по расстоянию между повторяющимися паттернами и попробуйте нарезать файл на записи скриптом на Python со struct.unpack.

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

import struct

with open("archiv.dat", "rb") as f:
    header = f.read(64)

magic, version, record_count, record_size = struct.unpack("<4sHII", header[:14])
print(magic, version, record_count, record_size)

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

Что делать, если внутри — база данных известного движка

Отдельный частый случай: программа была написана поверх стандартного движка баз данных, но открыла для чтения только через собственный интерфейс, зашив путь к файлу и схему внутри инсталлятора. Если сигнатура файла показала SQLite (53 51 4C 69, «SQLite format 3») — вам повезло: это открытый, задокументированный формат, и данные читаются напрямую, без всякой оригинальной программы:

sqlite3 archiv.dat ".tables"
sqlite3 archiv.dat ".schema"
sqlite3 archiv.dat "SELECT * FROM clients LIMIT 10;"

Похожая ситуация с файлами dBase (.dbf) — древний, но открытый и хорошо задокументированный формат, который использовался как основа для множества учётных систем 1990–2000-х. Он читается напрямую библиотеками вроде dbfread в Python без какой-либо связи с исходной программой.

Если внутри контейнера обнаружился MS Access (.mdb/.accdb, сигнатура OLE2) — на Linux его можно прочитать без Access через mdbtools:

apt install mdbtools
mdb-tables archiv.mdb
mdb-export archiv.mdb Clients > clients.csv

Стоит проверять это в первую очередь, потому что переход от «непонятного проприетарного формата» к «это просто известная СУБД с непубличной схемой сверху» экономит почти всё время разбора — остаётся только понять смысл таблиц и полей, а не формат хранения байтов.

Специалисты по восстановлению данных — когда это оправдано

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

Это оправдано, когда одновременно верны три вещи:

• Данные объективно ценные — юридически значимый архив, единственная копия финансовой отчётности, невоспроизводимые исходные материалы.
• Альтернативы (переввод данных вручную, восстановление из другого источника) дороже или невозможны.
• Собственные попытки уже упёрлись в реальный технический тупик, а не в нехватку часа-двух на эксперименты.

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

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

Профилактика: не ждите, пока формат станет проблемой

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

Практический минимум для данных, которые действительно важны:

• Раз в год-два открывайте архивные файлы в актуальном окружении. Не обязательно проверять каждый файл — достаточно выборочно открыть представителей каждого формата хранения, который у вас используется, и убедиться, что он всё ещё читается текущими версиями программ или системными утилитами.
• При закрытии проекта или отказе от программы — экспортируйте данные в открытый формат сразу, пока программа ещё работает и лицензия действует, а не когда понадобится через три года. CSV, SQL-дамп, plain text, PDF/A для документов — всё, что не зависит от конкретного вендора. Это на порядок дешевле, чем реверс-инжиниринг формата постфактум.
• Держите вместе с архивом описание того, чем он был создан — название программы, версия, ОС, по возможности сам установщик или образ виртуалки, если экспорт в открытый формат почему-то невозможен. Файл без контекста о происхождении разбирать значительно сложнее.
• Не полагайтесь на то, что расширение файла говорит правду. При переносах между файловыми системами и облачными синками расширения иногда теряются или меняются регистром — если это критично, храните контрольную сумму и сигнатуру файла отдельной строкой в описи архива.
• Для готовых продуктов на открытых СУБД (SQLite, PostgreSQL, MySQL) не позволяйте прикладному слою быть единственным способом чтения. Если данные лежат в стандартном движке, а бизнес-логика программы — это просто удобный интерфейс поверх него, то потеря программы не означает потерю доступа к данным, и это стоит учитывать уже на этапе выбора нового ПО для важных архивов.

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

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