Какво е PST файл?
Файловете с разширение .pst представляват лични файлове за съхранение на Outlook (наричани още таблица за персонално съхранение), които съхраняват разнообразна потребителска информация. Потребителската информация се съхранява в папки от различни типове, които включват имейли, елементи от календара, бележки, контакти и няколко други файлови формата. PST файловете се използват за архивиране на данни за изпращане по имейл офлайн, които по-късно могат да бъдат заредени и прегледани в различни приложения.
Спецификации на PST файлов формат
PST файлов формат спецификации се предлагат от Microsoft като безплатно и неотменимо безплатно патентно лицензиране чрез Open Specification Promise .
Тип PST формати
PST файловите формати са категоризирани в два типа въз основа на кодирането на файловия тип. Кодираните по ANSI PST файлове са по-стари файлови формати и се поддържат само от Outlook 2002 и по-стари версии. Такива файлове имат ограничение за максимален размер от 2 GB (2^^31^^ байта) и не поддържат Unicode. По-модерен тип файлов формат, базиран на Unicode кодиране, премахва ограничението за размера на файла и може да достигне максимален размер на данните от 50 GB.
Логическа организация на PST файловия формат
В основата на файловия формат PST лежи B-Tree, което поддържа данните сортирани и позволява търсения, последователен достъп, вмъквания, изтривания и т.н. в логаритмично време. Цялостната структура на PST файл е организирана в три слоя.
Слой база данни на възли (NDB) - Слоят на база данни на възли се намира на по-ниското ниво на PST файл и включва база данни от възли. Тези възли всъщност представляват съоръжения за съхранение от по-ниско ниво на файловия формат PST. Слоят NDB се състои от заглавка, информация за разпределение на файлове, блокове и BTrees (Node BTree и Block BTree) от гледна точка на съхранение. Възлите и блоковете на NDB Layer са свързани чрез Data BID, което е едно от четирите свойства на референтния възел, т.е. NID (Node ID), Parent NID, Data BID (Block BID) и SubNode 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 байта) | Неизползвано пространство; ТРЯБВА да се настрои на нула. Само Unicode PST файлов формат. |
| корен (Unicode: 72 байта; ANSI: 40 байта) | ROOT структура (раздел 2.2.2.5). |
| dwAlign (4 байта) | Неизползвани байтове за подравняване; ТРЯБВА да се настрои на нула. Само Unicode PST файлов формат. |
| rgbFM (128 байта) | Отхвърлена FMmap. Това вече не се използва и ТРЯБВА да се попълни с 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. |
| dwРезервирано (4 байта) | Резервирано; ТРЯБВА да се настрои на нула. Само файлов формат ANSI PST. |
| rgbReserved2 (3 байта) | |
| bЗапазено (1 байт) | |
| rgbReserved3 (32 байта) |
Защита на данни
За сигурност PST файловете също могат да бъдат защитени с парола, което изисква зареждащото приложение да приложи парола, преди да може да бъде прегледано. Паролата, приложена към PST файла, се съхранява в хранилището за съобщения. Това обаче не осигурява силна защита на данните, тъй като паролата може да бъде премахната от наличните инструменти. Също така зададената от потребителя парола не се използва като част от ключ за кодиране и декодиране на шифър алгоритми. По този начин няма полза от защитата на данните за достъп от неупълномощени страни. Съхраняването на парола като CRC-32 хеш на оригиналния низ също го прави слаб метод за защита на данните срещу груба сила.
