Боюсь, нет ответа, который даст вам правильное решение этого вопроса.
MORK
— это текстовая база данных, содержащая файлы данных адресной книги (.mab
файлов) и сводки почтовых папок (.msf
файлов).
Формат, написанный Дэвидом Маккаскером, представляет собой смесь различных числовых пространств имен, недокументирован и, похоже, больше не разрабатывается/не поддерживается/поддерживается. Единственный способ, которым вы могли бы получить контроль над этим, - это реконструировать его параллельно с просмотром исходного кода с использованием этого формата.
Однако были опытные люди, которые безуспешно пытались написать парсеры для этого формата файлов. Согласно Википедии, бывший инженер Netscape Джейми Завински сказал об этом формате:
... самый повреждающий мозг формат файла, который я когда-либо видел за свою девятнадцатилетнюю карьеру
На на этой странице указано следующее:
Вкратце, посчитаем его (Морка) грехи:
- Два разных числовых пространства имен, которые перекрываются.
- Он не может решить, какой синтаксис кавычек использовать: обратную косую черту? Шестнадцатеричная кодировка со знаком доллара?
- Иногда допустимы строчные комментарии C++, но иногда // — это просто пара символов в URL-адресе.
- Он идет на все эти серьезные усилия по сжатию (две разные хеш-таблицы с промежуточной строкой), а затем записывает строки Unicode без использования UTF-8: записывает распакованные символы wchar_t!
- Хуже того, он шестнадцатерично кодирует каждый wchar_t с 3-байтовой кодировкой, что означает, что размер файла будет 3x или 6x (в зависимости от того, является ли whchar_t 2 байта или 4 байта).
- Он маскируется под «текстовый» формат файла, хотя на самом деле это просто еще один двоичный файл BLOB-объектов, за исключением того, что он представляет все свои магические числа в ASCII. Он не читается человеком, его нельзя редактировать вручную, поэтому единственное преимущество в том, что он использует короткие строки и не использует двоичные символы, заключается в том, что он делает файл больше. Ой, подождите, моя ошибка, на самом деле это вовсе не преимущество».
Здесь сквозит разочарование, и очевидно, что это непростая задача.
Следовательно, вне продуктов Mozilla, по-видимому, не существует парсеров, способных анализировать этот формат.
В прошлом я реконструировал сложные форматы файлов и знаю, что это можно сделать при наличии терпения и нужного количества энергии.
К сожалению, это, похоже, и ваш единственный вариант. Для начала неплохо было бы взглянуть на исходный код Thunderbird а>.
Я знаю, что это не дает вам прямого решения, но я думаю, что это единственный ответ на вопрос, учитывая обстоятельства для этого формата.
И, конечно же, вы всегда можете заглянуть в API расширений, чтобы узнать, позволяет ли это вам для доступа к нужным данным более структурированным способом, чем прямая обработка формата файла.
30.08.2013