Требуется помощь с древней неизвестной системой хранения

Готов поспорить, что файл .dbf находится в формате DBase, что очень просто. Содержимое этого может дать подсказки остальным.

Утилита unix «file» может использоваться для распознавания многих типов файлов по их «магическому номеру». Он проверяет содержимое файла и сравнивает его с тысячами известных форматов. Если файлы имеют какой-либо распространенный формат, это, вероятно, может сэкономить вам много работы.

если они НЕ в общем формате, это может заставить вас гоняться за отвлекающими маневрами. Воспринимайте его предложения просто как предложения.

В дополнение к сайтам, предложенным Greg и Дмитрий, также есть хранилище форматов файлов по адресу http://www.wotsit.org ("Какой формат?").

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

Может быть что угодно. Лучше всего открыть в шестнадцатеричном редакторе и посмотреть что ты видишь

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

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

Когда вы найдете файл с данными, попробуйте найти известную запись, например. "Мистер Смит" и посмотрите, сможете ли вы разобраться в других областях. Целые числа часто представляются байт за байтом, даты часто закодированы, а дни от известной даты начала, деньги могут быть в двоично-десятичном коде.

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

Многие старые системы написаны на COBOL. Существует много информации о форматах net re cobol, а некоторые компании даже продают драйверы COBOL ODBC!

Я думаю, что Грег прав насчет файла .dbf. Вам следует попытаться найти информацию о других форматах файлов на таких сайтах, как http://filext.com и http://dotwhat.net. Файл .bak обычно является копией другого файла с тем же именем, но с другим расширением. Например, может быть файл database.dbf и файл database.bak с его резервной копией. Вы должны запросить (если это возможно) какие-либо подробности/документацию/исходный код приложения, которое использовало эти файлы, у вашего клиента.

Еще во времена DOS программисты создавали свои собственные расширения файлов почти так, как они считали нужным. DBF вполне может быть файлом DBase, который достаточно легко читать, а .BAK, вероятно, является резервной копией одного из других важных файлов или просто резервной копией, оставленной текстовым редактором.

Что касается остальных файлов, первое, что я сделал бы, это проверил бы их в читаемом формате ASCII, открыв их в текстовом редакторе.

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

Удачного взлома!

.DBF — это база данных dBASE или ранней версии FoxPro.

.DAT использовался Btrieve и IIRC Paradox для DOS.

Файлы .DBE и .00x, вероятно, являются либо временными, либо индексными файлами, связанными с файлами .DAT.

.DBF — это просто. Они будут открываться с помощью MS Access или Excel (во всяком случае, версий Office до 2007 г.) или с помощью ADO или ODBC.

Если файлы .DAT действительно принадлежат Btrieve, вы сильно пострадали. Это беспорядок, даже если вы сможете достать правильную версию словаря данных и копию структуры Btrieve. (Был там, сделал это, изнашивал футболку до того, как закончил.)

Как и другие, я рекомендую шестнадцатеричный редактор, если вы не можете понять, что это за файлы, и этот dbf, вероятно, является Dbase.

BAK, похоже, является файлом резервной копии. Я думаю, что *.001, *.002 и т. д. могут быть частью резервной копии. Они все одного размера? Может быть, резервная копия была разбита на более мелкие части, чтобы ее можно было поместить на съемный носитель?

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

Удачи!

Обязательно используйте дату изменения файлов в качестве подсказки, если .001, .002 и т. Д. Все имеют одинаковые отметки времени, возможно, вместе с .BAK они могут быть частью резервной копии. Также в каталоге может быть какой-то старый хлам, который вы можете (несколько безопасно) игнорировать. Найдите файлы .BAT и попробуйте их также проанализировать.

Одна подсказка, если файлы .dbf принадлежат DBase, FoxPro или одному из других продуктов, использующих этот формат. Тогда вы сможете прочитать их с помощью ODBC. В моей системе все еще есть драйвер ODBC для .dbf (Vista, с VS 2008 - как он туда попал, мне придется искать, но я предполагаю, что это был MDAC Microsoft Data Access, который поместил его туда). Таким образом, у вас может не быть «мира распаковки», если драйвер ODBC будет читать файлы .dbf.

Я, кажется, помню (с небольшой уверенностью, что 20 с лишним лет назад возился с DBase III), что DBase использовал .001, .002, ... файл для полей memo (большой текст).

Удачи в попытке спасти данные.

Формат DBF довольно распространен.

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

Теперь это часть Pervasive, но много лет назад я использовал Data Junction для переноса данных из множества типов файлов в другие. Посмотрите, если вы не хотите писать парсер.

.dat также может быть старыми файлами Clarion 2.1... Он также работает на основе ISAM с файлами ключей/индексов.