Uraltdatenbank Zahlenformat

[Gast]

Hallo!

Aus einer uralten proprietären DOS-Datenbank aus dem Jahre 1985 bräuchte ich nochmal Daten. Mir ist es soweit gelungen, alle Datenformate zu erkennen und auszulesen. Nur mit den Zahlen kann ich im Moment nichts anfangen. Da ich noch einen Editor (ohne Quelltext) für die Datenbank habe, konnte ich Zahlen eingeben. Diese stellen sich wie folgt hexadezimal dar:
73 E2 58 17 B7 51 = 0.0001
74 E2 58 17 B7 51 = 0.0002
75 AA 82 51 49 1D = 0.0003
75 E2 58 17 B7 51 = 0.0004
76 8D 97 6E 12 03 = 0.0005
76 AA 82 51 49 1D = 0.0006
76 C6 6D 34 80 37 = 0.0007
76 E2 58 17 B7 51 = 0.0008
76 FE 43 FA ED 6B = 0.0009

81 00 00 00 00 00 = 1.0000
82 00 00 00 00 00 = 2.0000
82 00 00 00 00 40 = 3.0000
83 00 00 00 00 00 = 4.0000
83 00 00 00 00 20 = 5.0000
83 00 00 00 00 40 = 6.0000
83 00 00 00 00 60 = 7.0000
84 00 00 00 00 00 = 8.0000
84 00 00 00 00 10 = 9.0000Leider erscheint mir das ohne Sinn und nachvollziehbarer Folge. Hat einer von euch vielleicht eine Idee?

[Misda]

Also bei 1,2,3 hab ich ein Muster rausgelesen

1
erste Hexfolge auf 81
letzte Hexfolge auf 00

2 und 3
erste Hexfolge auf 82
letzte Hexfolge von 00 auf 40 (schein um 40 Hex zu springen)

4, 5, 6 und 7
erste Hexfolge auf 83
letzte Hexfolge springt jeweils um 20 Hex

D.h. jetzt müssten theoretisch 8x 84 Hex kommen und die letzten dürften jeweils um 10 Hex springen.

Beim Übernächsten sollte dann 16x 85 Hex kommen und die letzten sollten jeweils um 5 Hex springen.

Die ersten Werte sagen mir noch nicht so viel.

EDIT:

Vielleicht doch!


73 E2 58 17 B7 51 = 0.0001
74 E2 58 17 B7 51 = 0.0002
75 E2 58 17 B7 51 = 0.0004
76 E2 58 17 B7 51 = 0.0008


Die Hexfolge E2 58 17 B7 51 ist immer identisch, der erste Hexwert könnte das vielfache (in dem Fall immer doppelt) davon angeben.

Folgendes bestättigt dies:


75 AA 82 51 49 1D = 0.0003
76 AA 82 51 49 1D = 0.0006


Hoffe es hilft dir (Ich hab zwar keinerlei Kenntnis von Datenformaten und Codierungen, dass ist mir aber halt mal aufgefallen ^^)

[Monger]

Puh...

Erstens mal vermute ich, dass die Spalten verschoben sind. Die erste ist eigentlich die letzte.

Außerdem vermute ich eine Huffman Codierung. So perverses Zeug hat man früher manchmal gemacht, um die Schreibsicherheit zu erhöhen.

[Eruphus]

Kann es sein, dass DIESE Daten aus einer SAP Datenbank kommen?
Dort werden Fließkommazahlen auch kryptisch codiert.

Huffman würde ich ausschliesen, da dazu eine Häufigkeitsverteilung von Nöten wäre, und der Code sich bei allen Zahlen ändern müsste sobald die soch Häufigkeitsverteilung verschiebt. Sollte es dennoch ein Huffman sein, so müsste die Bibliothek (Schlüsselverzeichniss) auch geliefert werden.

Die Werte könnten auch ähnlich einer Längenangabe innerhalb von ID3v2.x TAGs codiert sein. Dort werden die Daten 7Bit-wertig im Small-Endian Format abgespeichert was eine nicht ersichtliche totale verschiebung ergibt.
Vorteilhaft ist, dass diese Daten Bit-Sicher abgespeichert werden und nur noch schwer einem Fehler zum Opfer fallen. Im Anbetracht, dass es sich um eine Datenbank handelt würde ich diese Option am Wahrscheinlichsten halten.

kannst du folgende Werte auch eingeben und das Ergebnis posten ?!
- 10.0000
- 00.0010

Auf Antwort wartend .... :)

Eruphus

//edit :

als reaktion auf MistaX antwort...
Daten werden meines erachtens immer in 2^n Bytes (n € N) gespeichert. (bez. ANSI-C)
Du zeigst uns 6 bytige Werte, was zur Folge haben würde, dass jeweils 2 Byte zu 4 oder 8 Byte-Werten fehlen...


zusätzlich möchte ich dich bitten, dass du auch folgende Werte postes :

10.0001
10.0002

10.0009
10.0010
10.0011

[Gast]

kannst du folgende Werte auch eingeben und das Ergebnis posten ?!
- 10.0000
- 00.0010

Auf Antwort wartend .... :)

EruphusErst mal danke für eure Hilfe bisher. Die Zahlen poste ich gleich morgen früh. Ich habe noch ein paar Beispiele, die merkwürdig sind.

Zuerst hatte ich auch an eine Verschlüsselung gedacht. Da es aber einfach Lagerbestände, Größenangaben usw. sind und alle anderen Werte in der Datenbank einfach im Klartext drinstehen, erschien mir das abwegig. Ich habe schon mit Hi- und Lowbyte herumgespielt, mit XOR experimentiert, von vorne und von hinten gerechnet, aber es ergab alles keinen Sinn.

[Monger]

Huffman würde ich ausschliesen, da dazu eine Häufigkeitsverteilung von Nöten wäre, und der Code sich bei allen Zahlen ändern müsste sobald die soch Häufigkeitsverteilung verschiebt. Sollte es dennoch ein Huffman sein, so müsste die Bibliothek (Schlüsselverzeichniss) auch geliefert werden.

Argh, sorry, ich meinte nicht Huffman.
Mir fällt grad der Name nicht mehr ein, aber ich meine dieses Verfahren, wo beim hochzählen immer nur ein einzelnes Bit gleichzeitig gekippt wird.

[Mdk]

Argh, sorry, ich meinte nicht Huffman.
Mir fällt grad der Name nicht mehr ein, aber ich meine dieses Verfahren, wo beim hochzählen immer nur ein einzelnes Bit gleichzeitig gekippt wird.

Gray? http://en.wikipedia.org/wiki/Gray_code

mfg
mdk

[Monger]

Gray? http://en.wikipedia.org/wiki/Gray_code

mfg
mdk
Ja genau, danke!

[Xmas]

Das sind ganz offensichtlich 48-Bit Gleitkommazahlen im Format s39e8, d.h. Vorzeichenbit, 39 Mantissenbits und 8 Bit Exponent mit 129 als Bias. Dazu kommt die übliche implizite 1 vor dem Komma.

Außerdem sind die Bytes in Little-Endian-Reihenfolge, d.h. das niedrigste Byte liegt auf der niedrigsten Speicheradresse.

double fp48toDouble(unsigned char* bytes)
{
unsigned __int64 bits = 0;
unsigned __int64 inbits;

// Vorzeichenbit
inbits = bytes[5] & 0x80;
inbits <<= 56;
bits |= inbits;

// Exponent
inbits = bytes[0];
inbits = 894 + inbits;
inbits <<= 52;
bits |= inbits;

// Mantisse
inbits = bytes[5];
inbits &= 0x7F;
inbits <<= 45;
bits |= inbits;

inbits = *((unsigned int*)&bytes[1]);
inbits <<= 13;
bits |= inbits;

return *((double*)&bits);
}

unsigned char data[6] = { 0x73, 0xE2, 0x58, 0x17, 0xB7, 0x51 };

double d = fp48toDouble(data);

[Gast]

Das sind ganz offensichtlich...Klar, jetzt wo du es sagst. ;)

Aber erstmal vielen vielen Dank für deine Hilfe. Das war es tatsächlich. Da wäre ich vermutlich nie alleine draufgekommen. Wo um alles in der Welt verwendet man solche Datenformate und zu welchem Zweck?

[Xmas]

Aber erstmal vielen vielen Dank für deine Hilfe. Das war es tatsächlich. Da wäre ich vermutlich nie alleine draufgekommen. Wo um alles in der Welt verwendet man solche Datenformate und zu welchem Zweck?
Nun ja, du sagst die Datenbank ist von 1985. Damals waren FPUs bzw. "mathematische Koprozessoren" sehr selten, womit es keinen Grund gab sich an die IEEE754 Float-Typen zu halten. Vielleicht war die Vorgabe für diese Datenbank, Zahlen mit mindestens 10 signifikanten Dezimalstellen zu speichern. Dafür braucht man eine Mantisse > 32 Bit sowie den Exponenten, und kommt damit fast schon zwangsläufig auf 6 Bytes.
Da Speicher damals extrem teuer war und ALU/Datenbus sowieso nur 16 Bit breit, hat man auch nicht auf 8 Bytes "aufgerundet".


Der "real"-Datentyp in Turbo Pascal war soweit ich weiß auch 6 Byte breit, möglicherweise sogar identisch mit dem hier genannten Datentyp.