Lire un fichier outlook .pst

Version imprimable

28/06/2007, 19h47
archonte

Lire un fichier outlook .pst

Bonjour,

je souhaite récuperer dans Delphi les infos du calendrier d'Outlook. Où puis-je trouver l'aide ?

Je n'ai rien lu sur le sujet dans la FAQ d'Outlook. La FAQ de Delphi n'explique pas comment lire une série de Rendez-vous.

Merci :roll:
29/06/2007, 13h44
Laurent Dardenne

Salut, recherche sur le forum .pst ou Outlook la question y a déjà été posée.
Mais je ne suis pas sûr que cela soit possible, à ma connaissance, sa structure n'est pas communiqué par MS.
29/06/2007, 20h28
CapJack

Oui, il s'agit d'un format propriétaire de Microsoft. Mais si le fichier n'est pas corrompu, il me semble qu'il est possible de récupérer les informations en effectuant une connexion OLE Automation.
30/06/2007, 10h08
Laurent Dardenne

Désolé mais je t'ai peut être répondu à coté car ton titre parle de fichier .pst. Tu souhaite lire un fichier .pst ou récupérer des informations via un objet Outlook ?
01/07/2007, 23h29
archonte

Bonjour,
merci pour vos réponses,

En fait je cherche à récupérer les données du calendrier sauvegardées par Outlook, pour les affichées dans une sorte de "Widget".

Faut-il passer par OLE et masquer l'appli pour récupérer [périodiquement] les données ?

Y a-t-il moyen de lire directement le fichier de sauvegarde ?

Merci
:roll:
02/07/2007, 19h16
Laurent Dardenne

Citation:

Envoyé par archonte

Faut-il passer par OLE et masquer l'appli pour récupérer [périodiquement] les données ?

Y a-t-il moyen de lire directement le fichier de sauvegarde ?

Pour la seconde question oui si tu en connais le format et en cas de migration tu devras réécrire cette partie. La première approche me semble limitée mais plus "tranquille".
Il y a peut être qq chose à faire avec les fonctions d'export...
03/07/2007, 14h38
CapJack

Bis repetita non placent, je redis et répète que le format .pst et non documenté et propriétaire. J'ajoute qu'il est complexe. J'en sais quelque chose pour avoir voulu développer un petit truc il y a quelques années, pour récupérer les informations récupérables d'un .pst corrompu, là où la connexion OLE échouait (finalement, je m'étais rabattu sur une solution commerciale, l'une des rares, la seule peut-être, à accéder directement au fichier).

Outre le fait qu'il s'agit d'une arborescence obscure, les données d'un fichier .pst sont, selon les cas, l'historique du fichier et les choix de l'utilisateur, compressées et/ou cryptées suivant des algorithmes eux aussi non documentés.

Alors l'accès par OLE n'est pas seulement "plus sûr". C'est le seul envisageable de façon raisonnable.
03/07/2007, 15h20
Laurent Dardenne

Citation:

Envoyé par CapJack

Bis repetita non placent, je redis et répète que le format .pst et non documenté et propriétaire.

Il faut savoir que Remixtech a créé il ya qq temps un outil sous Delphi qui permet de lire les .pst. C'est bien pour ça que laissait cette possibilité.
voir http://www.ratiatum.com/log412_Client_Mail_checker.html
Mais les sources ne sont pas fournies.

Citation:

Envoyé par CapJack

Alors l'accès par OLE n'est pas seulement "plus sûr". C'est le seul envisageable de façon raisonnable.

On est d'accord ;)
03/07/2007, 16h54
CapJack

Citation:

Envoyé par Laurent Dardenne

Il faut savoir que Remixtech a créé il ya qq temps un outil sous Delphi qui permet de lire les .pst.

Je suis prêt à parier ma main droite que ce logiciel, comme les autres, utilise une connexion OLE.
03/07/2007, 19h09
Laurent Dardenne

Citation:

Envoyé par CapJack

Je suis prêt à parier ma main droite que ce logiciel, comme les autres, utilise une connexion OLE.

N'étant pas bourreau de métier, le mieux serait de le contacter pour confirmation ;)

Ce ne sera pas nécessaire : je suis absolument certain de mon fait.

A l'époque où j'avais étudié la chose, à force de recherches j'avais trouvé des informations underground dans le monde Linux, de développeurs voulant lire les fichiers .pst sous Linux. Ces informations étaient très partielles et j'avais échoué à les utiliser.

De mémoire, les fichiers .pst ont une structure originale ayant fait l'objet d'un dépôt de brevet par Microsoft : il s'agit d'une structure d'index assez comparable à celle du formatage logique d'un périphérique. Une structure d'"e-mail" qui en réalité est conçue pour contenir toute sorte d'éléments est à la base de ce système, les données quant à elles, étant la plupart du temps sont compressés... je vous laisse imaginer.

En tout cas, c'est ce que j'avais vaguement compris. Si ça se trouve, j'ai tout faux. En tout cas, le code que j'avais créé n'arrivait à récupérer que quelques éléments même sur un pst sain. J'ai laissé tomber. Si ça vous intéresse, je peux publier, mais ne me posez aucune question.

Maintenant, si ça vous amuse, voilà le peu de doc que j'ai pu ramasser (la légalité est douteuse, si problème, je laisse un modérateur effacer) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
 
File format for Outlook pst files
=================================
 
Basically, we work on two indexes. One index associates an ID with each item,
and the second index associates a second ID with the original ID.
I see no real purpose for this yet.
 
0x00 - Signature [4 bytes] (0x4E444221)
0xA8 - File Size [4 bytes]
0xC4 - Pointer to Index of all Items in File, associating the first ID [4 bytes]
0xBC - Pointer to Index of controlling Items in File [4 bytes]
 
First All Items Index: - constists of a table of offsets pointing to the table of items.
======================
repeating:
0x0  - First id in this table   [4 bytes]
0x04 - Unknown                  [4 bytes]
0x08 - Offset of table          [4 bytes]
 
until "First id in this table" is zero
 
Table Of Items: - Pointed to by above records.
===============
repeating:
0x0  - Id1 of this item           [4 bytes]
0x04 - Offset of this item        [4 bytes]
0x08 - Size of data stored there  [2 bytes]
0x0A - Unknown                    [2 bytes]
 
until "Id1 of this item" is zero. When this is reached, you return to the above
table and read the next record
 
Second All Items Index: - Contains the descriptors for emails, and other items
=======================
repeating:
0x0  - First id2 of this table  [4 bytes]
0x04 - Unknown                  [4 bytes]
0x08 - Offset of table          [4 bytes]
 
until "First id2 of this table" is zero
 
Second Table of Items: - Pointed to by above records
======================
repeats 0x1F times
0x0  - Id2 of this item           [4 bytes]
0x04 - Id1 of the descriptor item [4 bytes]
0x08 - Id1 of the associated list [4 bytes] (this contains a list of id1 and id2
                                          that are to with this controlling item)
0x0C - Id2 of parent              [4 bytes]
 
 
Associated List: - pointed to by the above record.
Contains associations between id1 and id2 for the items controlled by the record
================
0x0  - Constant [2 bytes]  (0x0002)
0x02 - Count    [2 bytes] (the number of items that are about to follow)
 
repeating
0x0 - Id2 of record   [4 bytes]
0x04 - Id of record   [4 bytes] - This is an association between the two
0x08 - Unknown        [4 bytes]
until you have reached the "Count"
 
 
Descriptor Item: - Referenced from "Second Table of Items" -
Contains information about the item (email, contact...)
================
0x0  - Block Offset to Block Index  [2 bytes]
0x02 - Constant                     [2 bytes] (0xBCEC)
0x04 - Index Pos of Section1        [4 bytes]
 
NOTE: An index pos can be shifted left 4 times [ i_pos << 4 ] to get
an index offset (ie, an offset from the start of the block index)
 
 
Block Index: - contains offsets to points in the current block
============
0x0 - Count of offsets minus one. [2 bytes]
(In effect, each offset must be taken with the following one so that
the start and end of the referenced item can be established.
Therefore there is one extra to show the end of the last item.)
 
repeating
0x0  - Block Offset [2 bytes]
until you have one extra than the "Count"
 
 
Section1: - Referenced from "Descriptor Item" - contains not much
=========
0x0  - Constant? [4 bytes] (0x0602B5)
0x04 - Index Pos of Descriptor fields [4 bytes]
 
 
Descriptor Fields: - Contain the information needed to access the details
of the email
==================
repeats
0x0  - Item type        [2 bytes] (subject, from, to ...)
0x02 - Reference type   [2 bytes] (how to interpret the value)
0x04 - Value            [4 bytes]
until the alloted size of the record has been read. (The following Block Offset from the Index has been reached)
 
Reference Types: - I don't know if I have interpreted this field correctly.
It might have a completely different purpose
===============
0x0002 -
0x0003 - Value following is a value in it's own right
0x000B -
0x001E - (STRING) Value following is a Index Position (must be shifted left 4 times)
0x0040 - (DATE)       "         "              "              "              "
0x0048 -
0x0102 - (STRUCTURE)  "         "              "              "              "
0x1003 -
0x101E - (ARRAY OF STRING)
0x1102 -
 
Value:
======
When the value is of type Index Position, you can left shift the value 4 times to get an offset into the Block Index. Some descriptor types can have Id2 values. This is recognised by using a bitwise AND with the number. ie val & 0x0000000F.
if the result is 0xF, it is likely to be a Id2 reference.
 
 
Descriptor Types: - Types that are in "Descriptor Fields"
=================
 
All Values are Hex
 
Note: it appears that some types can have a IPOS value or a ID2 value depending
on the size of the field in question. It is safer to check every field
than for me to say what the "usually" contain.
Absolute values though, are generally going to be constant.
 
Type  Ref Type  Value   Desc
----  --------  -----   ----
001A  		[REF]	IPM Context. What type of message is this
0037  001E      [REF]   Email Subject. The referenced item is of type "Subject Type"
0039 		[REF]	Date. This is likely to be the arrival date
003B		[REF]	Outlook Address of Sender
003F		[REF]	Outlook structure describing the recipient
0040		[REF]	Name of the Outlook recipient structure
0041		[REF]	Outlook structure describing the sender
0042		[REF]	Name of the Outlook sender structure
0043		[REF]	Another structure describing the recipient
0044		[REF]	Name of the second recipient structure
004F		[REF]	Reply-To Outlook Structure
0050		[REF]	Name of the Reply-To structure
0051		[REF]	Outlook Name of recipient
0052		[REF]	Second Outlook name of recipient
0064		[REF]	Sender's Address access method (SMTP, EX)
0065		[REF]	Sender's Address
0070		[REF]	Processed Subject (with Fwd:, Re, ... removed)
0071		[REF]	Date. Another date
0075		[REF]	Recipient Address Access Method (SMTP, EX)
0076		[REF]	Recipient's Address
0077		[REF] 	Second Recipient Access Method (SMTP, EX)
0078		[REF]	Second Recipient Address
007D  001E      [REF]   Email Header. This is the header that was attached to the email
0C19		[REF]	Second sender struct
0C1A		[REF]	Name of second sender struct
0C1D		[REF]	Second outlook name of sender
0C1E		[REF]	Second sender access method (SMTP, EX)
0C1F		[REF]	Second Sender Address
0E03		[REF]	CC Address?
0E04		[REF]	SentTo Address
0E06		[REF]	Date.
0E07		[REF]	Flag - contains IsSeen value
0FF9		[REF]	binary record header
1000  001E      [REF]   Plain Text Email Body. Does not exist if the email doesn't have a plain text version
1013  001E      [REF]   HTML Email Body. Does not exist if the email doesn't have a HTML version
1035		[REF]	Message ID
1042		[REF]	In-Reply-To or Parent's Message ID
1046		[REF]	Return Path
3001		[REF]	Folder Name? I have seen this value used for the contacts record aswell
3007		[REF]	Date.
3008		[REF]	Date.
300B		[REF]	binary record header
35E0		[REF]	binary record found in first item. Contains the reference to "Top of Personal Folder" item
35E3		[REF]	binary record with a reference to "Deleted Items" item
35E7		[REF]	binary record with a refernece to "Search Root" item
3602		[REF]	the number of emails stored in a folder
3603		[REF]	the number of unread emails in a folder
3613		[REF]	the folder content description
8000-			Contain extra bits of information that have been taken from the email's header. I call them extra lines
 
Key:
[REF]  = Can be either Index Position, or an Id2 Reference

Même le logiciel auquel j'ai fait référence plus haut, et qui a "sauvé la vie" à la professionnelle concernée (Microsoft Outlook Recovery), se contente à ce que j'ai compris d'accéder directement au fichier pour collecter les objets perdus qui ne sont plus indexés et les mettre dans un .pst de sauvegarde. L'extraction, ensuite, est quand même faite avec une connexion OLE à Outlook.

04/07/2007, 17h45
remixtech

Citation:

Envoyé par CapJack

Je suis prêt à parier ma main droite que ce logiciel, comme les autres, utilise une connexion OLE.

Bingo ;). J'utilisais une connexion OLE
05/07/2007, 09h57
CapJack

Merci pour la confirmation ! :)
05/07/2007, 20h08
archonte

:D :D Merci pour toutes vos réponses (et commentaires) :D :D

D'aprés toutes vos réponses, il semble qu'il faille passer par un lien OLE.
Je vous tiendrai au courrant du resultat.

PS : pour des raison de calendrier (justement ;) ) professionnel je ne pourrais pas essayer avant septembre ...

Encore Merci :merci:
16/07/2007, 17h13
PomaH

Bonjour,

Je suis assez interessé par cet application moi aussi. Cependant je n'arrive pas à traduire le code en delphi car je n'ai aucune connaissance en VB.

Y aurai-t-il une ame généreuse pour faire la translation(Septembre c'est un peu loin la)?

(le code faisant une vingtaine une ligne avec les déclaration)

Merci
18/07/2007, 21h59
Laurent Dardenne

Citation:

Envoyé par CapJack

Merci pour la confirmation ! :)

Bon hé bien je me suis trompé mais j'ai appris qq chose.

Bon finalement j'ai réussi à récupérer mon calendrier outlook.

Je donne le code au cas ou ca interesserait du monde :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
procedure TForm2.FormCreate(Sender: TObject);
    var
  objFolder : MAPIFolder;
    j : Integer;
    rdv : variant ;
    st : string;
    begin
  Outlook.Connect;    //connection à Outlook
  Nom := Outlook.GetNameSpace('MAPI');
  Nom.logon('','', False, False);    //connection au compte de messagerie associé
  objFolder := Nom.GetDefaultFolder(olFolderCalendar);  // Access the Inbox
          For j := 1 To objFolder.Items.Count do
  begin
    rdv := objFolder.Items.Item(j);
          st := string(rdv.start)+' '+string(rdv.end)+ ' '+string(rdv.subject);
    ListBox1.Items.Add(st);
  end;
end;

19/07/2007, 10h10
Laurent Dardenne

Citation:

Envoyé par PomaH

Bon Je donne le code au cas ou ca interesserait du monde :

Merci, on l'insérera dans la prochaine FAQ Delphi.
19/07/2007, 15h46
PomaH

Pas de souci. Je vais ajouter quelques petites précisions alors :

-Ce code permet de se connecter sur le compte Outlook par défaut (associé à la session windows dans mon cas). Pour changer cela il faut rentrer le compte de messagerie puis le mot de passe de la facon suivante :
Nom.logon('COMPTE','PASS', False, False);

-Ce code récupère la date de début du rendez-vous, de fin de rendez-vous ainsi que le sujet du rendez-vous. Pour changer les données à afficher, il suffit de prendre d'autres méthodes. Par exemple rdv.location indiquera le lieu, rdv.duration la durée ect . Toutes ces méthodes sont expliqué dans l'aide Outlook et apparaissent avec la saisie semi-automatique.

Couplé à cela, si qqun à une piste pour afficher les rendez-vous saisi de manière graphique je suis preneur. J'ai regardé le post de Waskol mais c'est un peu trop compliqué pour moi....
Merci