Що таке файл PST?
Файли з розширенням .pst представляють особисті файли зберігання Outlook (також звані персональною таблицею зберігання), у яких зберігається різноманітна інформація користувача. Інформація про користувача зберігається в папках різних типів, які включають електронні листи, елементи календаря, нотатки, контакти та декілька інших форматів файлів. Файли PST використовуються для архівування даних електронної пошти в автономному режимі, які пізніше можна завантажити та переглянути в різних програмах.
Специфікації формату файлу PST
Формат файлу PST специфікації доступний від Microsoft як безкоштовне та безвідкличне безкоштовне ліцензування патенту через Open Specification Promise .
Тип форматів PST
Формати файлів PST поділяються на два типи на основі кодування типу файлу. Файли PST із кодуванням ANSI є старішими форматами файлів і підтримуються лише Outlook 2002 і попередніми версіями. Такі файли мають максимальний розмір 2 ГБ (2^^31^^ байт) і не підтримують Unicode. Більш сучасний тип формату файлу, заснований на кодуванні Unicode, усуває обмеження на розмір файлу та може досягати максимального розміру даних у 50 ГБ.
Логічна організація формату файлу PST
В основі формату файлів PST лежить B-Tree, яке зберігає дані впорядкованими та дозволяє здійснювати пошук, послідовний доступ, вставки, видалення тощо в логарифмічному часі. Загальна структура файлу PST складається з трьох рівнів.
«Рівень бази даних вузлів (NDB)» — рівень бази даних вузлів знаходиться на нижньому рівні файлу PST і включає базу даних вузлів. Ці вузли фактично представляють засоби зберігання файлів нижчого рівня у форматі PST. Рівень NDB складається із заголовка, інформації про розміщення файлів, блоків і BT-дерев (Node BTree і Block BTree) з точки зору зберігання. Вузли та блоки рівня NDB пов’язуються через BID даних, який є одним із чотирьох властивостей посилання на вузол, тобто NID (ідентифікатор вузла), батьківський NID, BID даних (BID блоку) і BID підвузла.
Рівень «Списки, таблиці та властивості» — рівень LTP забезпечує логічне розуміння концепцій вищого рівня поверх NDB. Крім інших елементів, рівень LTP в основному складається з контексту властивостей (PC) і контексту таблиці (TC). PC — це набір властивостей, тоді як TC — двовимірна матриця набору властивостей проти їх наявності. Ефективна реалізація ПК і TC, рівень LTP використовує наступні два типи структур даних на вершині NDB Node:
- Heap On Node (HN) — дозволяє розподіляти потік даних вузла на невеликі фрагменти змінного розміру.
- BTree on Heap (BTH) – BTH забезпечує зручний і практичний спосіб пошуку даних. Комп’ютери, описані вище, реалізовані як BTH, і тому його реалізовано шляхом вбудовування в структуру HN.
`Рівень обміну повідомленнями — на цьому рівні реалізовано правила вищого рівня та бізнес-логіку для роботи з файлами PST. Логічний результат цього рівня – це об’єкти папки, об’єкти повідомлення, об’єкти вкладення та властивості, що стало можливим завдяки поєднанню рівнів LTP і NDB. Правила та вимоги, яких необхідно дотримуватися під час зміни вмісту PST, також визначаються на цьому рівні.
Фізична організація формату файлу PST
Високий рівень організації файлу PST показано на малюнку нижче. Це лише огляд різних концепцій логічних елементів файлу PST.
Інформація заголовка PST
Структура HEADER файлу PST розташована на самому початку файлу зі зміщенням 0. Він містить інформацію метаданих про файл PST і інформацію ROOT для доступу до структур даних рівня NDB, описаних вище. Структура HEADER відрізняється для версій Unicode та ANSI формату файлу PST.
Заголовок починається з 4-байтового магічного слова !BDN, представленого байтами (0x21, 0x42, 0x44, 0x4E). Інше 2-байтове магічне число, SM (0x53, 0x4D), розташоване на зміщенні 8 від початку файлу. Інформація про версію (ANSI або Unicode) міститься зі зміщенням 10 від початку файлу. Шістнадцяткове значення (0x17) визначає файл Unicode PST, тоді як 0x0E або 0x0F представляє формат файлу ANSI.
| Поле | Опис |
|---|---|
| dwMagic (4 байти) | МАЄ бути “{ 0x21, 0x42, 0x44, 0x4E } ("!BDN”)" |
| dwCRCPartial (4 байти) | 32-бітне значення CRC 471 байта даних, починаючи з wMagicClient (0ffset 0x0008) |
| wMagicClient (2 байти) | МАЄ бути “{ 0x53, 0x4D}”. |
| wVer (2 байти) | Версія формату файлу. Це значення ПОВИННО бути 14 або 15, якщо файл є файлом ANSI PST, і ПОВИННО бути 23, якщо файл є файлом Unicode PST. |
| wVerClient (2 байти) | Версія формату файлу клієнта. Версія, яка відповідає формату, описаному в цьому документі, — 19. Творці нового файлу PST на основі цього документа СЛІД ініціалізувати це значення 19. |
| bPlatformCreate (1 байт) | Це значення ПОВИННО мати значення 0x01. |
| bPlatformAccess (1 байт) | Це значення ПОВИННО мати значення 0x01. |
| dwЗарезервовано (8 байтів) | |
| bidUnused (тільки 8 байтів Unicode) | Невикористане доповнення додано під час створення формату файлу Unicode PST. |
| bidNextP (Unicode: 8 байтів; ANSI: 4 байти) | BID наступної сторінки. Сторінки мають спеціальний лічильник для призначення значень bidIndex. Значення bidIndex для BID для сторінок виділяється з цього лічильника. |
| bidNextB (лише 4 байти ANSI): | Наступний BID. Це значення є монотонним лічильником, який вказує BID, який буде призначено для наступного виділеного блоку. Значення BID збільшуються з кроком 4. Для отримання додаткової інформації див. розділ 2.2.2.2. |
| dwUnique (4 байти) | Це монотонно зростаюче значення, яке змінюється щоразу, коли змінюється структура HEADER файлу PST. Функція цього значення полягає в тому, щоб надати унікальне значення та переконатися, що CRC HEADER відрізняються після кожної модифікації заголовка. |
| rgnid[] (128 байтів) | Фіксований масив із 32 NID, кожен з яких відповідає одному з 32 можливих NID_TYPE (NID_TYPE, NID_TYPE_NORMAL_FOLDER, NID_TYPE_SEARCH_FOLDER, NID_TYPE_NORMAL_MESSAGE,NID_TYPE_ASSOC_MESSAGE) |
| qwUnused (8 bytes) | Невикористаний простір; ПОВИНЕН бути встановлений на нуль. Лише формат файлу Unicode PST. |
| корінь (Unicode: 72 байти; ANSI: 40 байтів) | КОРЕНЕВА структура (розділ 2.2.2.5). |
| dwAlign (4 bytes) | Невикористані байти вирівнювання; ПОВИНЕН бути встановлений на нуль. Лише формат файлу Unicode PST. |
| rgbFM (128 байтів) | Застаріла FMap. Це більше не використовується і ПОВИННО бути заповнене 0xFF. Читачі ПОВИННІ ігнорувати значення цих байтів. |
| rgbFP (128 байтів) | Застаріла FPMap. Це більше не використовується і ПОВИННО бути заповнене 0xFF. Читачі ПОВИННІ ігнорувати значення цих байтів. |
| bSentinel (1 байт) | МАЄ бути встановлено на 0x80. |
| bCryptMethod (1 байт) | Вказує, як закодовано дані у файлі PST. ПОВИННО бути встановлено одне із попередньо визначених значень (NDB_CRYPT_NONE, NDB_CRYPT_PERMUTE, NDB_CRYPT_CYCLIC). |
| rgbЗарезервовано (2 байти) | Зарезервований; ПОВИНЕН бути встановлений на нуль. |
| bidNextB (8 байтів) | Вказує на наступне доступне значення BID. Лише формат файлу Unicode PST. |
| bidNextB (ТІЛЬКИ Unicode: 8 байтів) | Наступна BID. Це значення є монотонним лічильником, який вказує BID, який буде призначено для наступного виділеного блоку. Значення BID збільшуються з кроком 4. Для отримання додаткової інформації див. розділ 2.2.2.2. |
| dwCRCFull (4 байти) | 32-бітне значення CRC 516 байтів даних, починаючи від wMagicClient до bidNextB включно. Лише формат файлу Unicode PST. |
| ullReserved (8 байтів) | Зарезервовано; ПОВИНЕН бути встановлений на нуль. Лише формат файлу ANSI PST. |
| dwReserved (4 байти) | Reserved; ПОВИНЕН бути встановлений на нуль. Лише формат файлу ANSI PST. |
| rgbReserved2 (3 байти) | |
| bЗарезервовано (1 байт) | |
| rgbReserved3 (32 байти) |
Захист даних
З міркувань безпеки файли PST можна також захистити паролем, що вимагає від програми для завантаження застосувати пароль, перш ніж їх можна буде переглянути. Пароль, застосований до файлу PST, зберігається в сховищі повідомлень. Однак це не забезпечує надійного захисту даних, оскільки пароль можна видалити доступними інструментами. Крім того, вказаний користувачем пароль не використовується як частина ключа для кодування та декодування алгоритмів шифру. Таким чином, захист даних від доступу неавторизованих сторін не приносить жодних переваг. Зберігання пароля як хешу CRC-32 оригінального рядка також робить його слабким методом захисту даних від підходу грубої сили.
