[abgeschlossen] Zugriff auf dBase Blob von "Hand"

[H4ndy]

Hallo!

Aufgrund eines Übungsprojektes, muss ich auf Arbeit von "Hand" auf eine ACT! 6 (ist eine
Kontaktverwaltung) dBase-Datenbank zugreifen. Der Zugriff auf die Grundtabellen
(.DBF-Datei) war kein Problem, da sich massig Formatbeschreibungen im Netz dazu finden.

Allerding muss ich jetzt auch auf ein "Binary Large Object" zugreifen.
Dabei werden in einer .blb-Datei alle Daten gespeichert, welche größer als
die maximal 255 Zeichen einer normalen Spalte sind. In der Spalte befindet
sich dann nur noch eine Referenz auf das Object in der blb-Datei.

Das Problem dabei ist jetzt, dass ich keinerlei Ahnung habe, wie ich die Referenz
auszuwerten habe, um an die richtige Position in der blb-Datei zu kommen :-/

Hier der konkrete Fall:

Die Referenz ist genau 6 Zeichen lang.
ASCII: "<space><space><space>/SG"
HEX: 2020 202F 5347

Ich glaube, dass die benötigten Daten an der Adresse $43E540 in der blb-Datei stehen,
bin mir da aber nicht sicher. Auf jeden fall hab ich bis jetzt keine Möglichkeit oder
Beschreibung gefunden, wie ich die Referenz zu lesen hab

Mir reicht schon irgendeine Formatbeschreibung, die das alles mit abdeckt.
Schonmal Danke für jede Antwort =)

[alzaimar]

Du darfst keine DBase-Treiber (ADO, TDBF etc.) verwenden? Is ja fies...

[marabu]

Hallo.

dBase III o.ä. ist keine gute Beschreibung, da sich zwischen den Versionen einiges geändert hatte. Welches Dateiformat genau vorliegt, das kannst du anhand der Einträge im Header der DBF-Datei bestimmen. Interessant ist die dBase-Versionskennung. dBase III arbeitete in der Memo-Datei mit einer festen Blockgröße von 512 Byte. Bei späteren Versionen konnte die Blockgröße konfiguriert werden.

Grüße vom marabu

[H4ndy]

Hallo!

Also dem Header nach zu urteilen (Struktur), ist es eine dBase III PLUS Datenbank
(oder zumindest kompatibel zu dieser, da meine Lese-Routinen eine dB III+
Formatbeschreibung zum (bisher fehlerfreien) Auslesen benutzen).
(Laut Header ist auch keine Memo-Datei vorhanden (Byte 1 is $03))

Das mit der Blockgröße habe ich gestern auch noch herausgefunden,
und es scheint tatsächlich eine Aufteilung in 512-Byte-Blöcke vorhanden zu sein.
Allerdings stellt sich jetzt die Frage, wie ich da die Referenz zu deuten habe.

Gestern hab ich auch noch folgendes gefunden:
Nach einer Info, ist die Referenz 6 Zeichen lang und rechtbündig ausgerichtet
und dabei mit Leerzeichen gefüllt (erklärt die drei Leerzeichen im Anfang).

Also müsste man nur die drei Zeichen "/SG" irgendwie auslesen.
Fakt ist aber, dass es mal zwei und mal drei Zeichen sind

Hier mal noch ein paar Beispiele für Referenzen:

Code:

ASCII Hex
-(6   2D 28 36
!#M   21 23 4D
'(    27 28
('    28 27
.Z    2E 5A

Irgendwie beschleicht mich das Gefühl, dass die Referenzen "ASCII-tauglich" gemacht wurden,
um sie in Textfelder speichern zu können :/

[marabu]

Hallo Manuel,

Symantec verwendet bewusst ein zu dBase teilweise inkompatibles Speicherformat. Namhafte Konkurrenten sind bislang an der Datenübernahme gescheitert, da die Daten in der BLB-Datei anscheinend auch noch teilweise verschlüsselt werden. Betroffen scheinen E-Mail-Adressen, Kontakthistorie und Freitext-Angaben zu sein. Gelegentlich findet sich ein Verweis auf ACT!Look als Wunderwaffe - ich kann das nicht beurteilen.

Unverschlüsselt oder nicht - eine eindeutige Zuordnung von Referenz zu BLOB-Datenblock sollte leicht möglich sein, wenn man Testdaten per ACT!6 eintragen kann. Ich vermute, dass auch die Decodierung der Referenz keine unlösbare Aufgabe ist. Als "Unlösbar" könnte sich dann aber die Decodierung einer eventuellen Verschlüsselung der Datenblöcke herausstellen. Auf jeden Fall ist das kein Übungsprojekt.

Grüße vom marabu

[H4ndy]

Danke für die Informationen marabu!

Also ich habs jetzt sein lassen, die blob-Datei auszulesen.
Wie du schon gesagt hast, wär ich vielleicht noch auf die richtige Position
gekommem, hätte aber keine Daten auslesen können.
(Irgendeine Firma hats geschafft, aber ich glaub nicht, dass die ihr Know-How rausgeben werden)

Die Referenz scheint noch eine Abart einer Base64-Kodierung o.ä. zu sein,
ganz decodieren konnte ich sie aber noch nicht.

Trotz alledem danke für die Hilfe!
Muss ich mich eben nur mit den "normalen" Daten abgeben.

Gruß