Domino 9 und frühere Versionen > ND9: Entwicklung

Daos- Catalog: Hat jemand schonmal die $DAOSTicketList- Attachments analysiert?

<< < (2/2)

pram:
Habe mich soeben auch mal mit der $DAOSTicketlist beschäftigt und möchte meine momentane Erkenntnis teilen.

Analysiert wurde folgender Block

--- Code: --- 6B 34 00 00 1A 00 00 00.00 00 02 00 08 00 01 00 ; 000 k4..............
52 0F 09 00 48 8E 01 00.00 00 00 00 00 00 00 00 ; 001 R...H...........
46 32 36 34 34 43 33 39.37 45 32 46 31 38 31 43 ; 002 F2644C397E2F181C
32 37 36 33 31 42 36 45.36 43 34 32 39 30 46 37 ; 003 27631B6E6C4290F7
43 38 31 30 35 30 38 33.30 30 30 31 38 45 34 38 ; 004 C810508300018E48
00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 ; 005 ................
00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 ; 006 ................
00 36 01 00 00 1A 00 1A.00 00 00 00 00 02 00 08 ; 007 .6..............
00 01 00 9A 0F 09 00 53.78 2E 00 00 00 00 00 00 ; 008 .......Sx.......
00 00 00 32 44 42 36 30.39 43 41 30 43 35 33 35 ; 009 ...2DB609CA0C535
35 33 41 38 31 31 32 32.42 45 44 30 41 33 37 46 ; 00a 53A81122BED0A37F
46 32 44 39 46 33 35 38.35 42 39 30 30 32 45 37 ; 00b F2D9F3585B9002E7
38 35 33 00 00 00 00 00.00 00 00 00 00 00 00 00 ; 00c 853.............
00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 ; 00d ................
00 00 00 00 36 01 00 00.1A 00 1A 00 00 00 00 00 ; 00e ....6...........
02 00 08 00 01 00 9E 0F.09 00 9C 3B 2B 00 00 00 ; 00f ...........;+...
00 00 00 00 00 00 46 33.30 38 45 36 39 43 43 38 ; 010 ......F308E69CC8
42 41 33 41 33 35 39 41.30 45 41 42 30 33 36 41 ; 011 BA3A359A0EAB036A
44 45 46 36 46 44 45 44.46 44 31 44 35 38 30 30 ; 012 DEF6FDEDFD1D5800
32 42 33 42 39 43 00 00.00 00 00 00 00 00 00 00 ; 013 2B3B9C..........
00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 ; 014 ................
00 00 00 00 00 00 00 36.01 00 00 1A 00 1A 00 00 ; 015 .......6........
00 00 00 02 00 08 00 01.00 C2 0F 09 00 31 09 0D ; 016 .............1..

--- Ende Code ---

Die ersten 4 Bytes 6B 34 00 00 (=13419 dez) gibt die Anzahl der Records wieder. Ein Record ist 115 Bytes lang.

Exemplarisch habe ich 3 Records mal "aufgedröselt"

--- Code: ---1A 00 00 00.00 00 02 00 08 00 01 00 52 0F 09 00 48 8E 01 00.00 00 00 00 00 00 00 00 <ID> 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 36 01 00 00 1A 00
............R...H...........F2644C397E2F181C27631B6E6C4290F7C810508300018E48.................................6.....

1A.00 00 00 00 00 02 00 08 00 01 00 9A 0F 09 00 53.78 2E 00 00 00 00 00 00 00 00 00 <ID> 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 36 01 00 00.1A 00
................Sx..........2DB609CA0C53553A81122BED0A37FF2D9F3585B9002E7853.................................6.....

1A 00 00 00 00 00 02 00 08 00 01 00 9E 0F.09 00 9C 3B 2B 00 00 00 00 00 00 00 00 00 <ID> 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 36.01 00 00 1A 00
.................;+.........F308E69CC8BA3A359A0EAB036ADEF6FDEDFD1D58002B3B9C.................................6.....

--- Ende Code ---

Die ersten 12 Bytes sind immer gleich, dann folgen 4 Bytes 52 0F 09 00 (=0x90F52) welche mit der ObjectID des zugehörigen File-Items übereinstimmen.
die nächsten 4 Bytes 48 8E 01 00 (=101960) entsprechen der Dateigröße. Dann folgen 8 Nullbytes und dann der Name des *.nlo Files.

Das NLO-File ist um 425 Bytes größer als das Originalattachment.

Außer der Object-ID und der Dateigröße habe ich nichts "verwertbares" gefunden. Keine Replik-ID o.ä. Die restlichen Bytes sind entweder in jedem Record gleich, oder sowieso 00.

Gruß
Roland

Navigation

[0] Themen-Index

[*] Vorherige Sete