Konvertierung IEEE 754 (8 Byte) --> Dezimal

Ich habe hier eine Binärdatei, die Fließkommazahlen im 64 Bit-Format ("Doppelte Genauigkeit" nach IEEE 754) enthält. Ich will diese Zahlen in Excel einlesen und ins Dezimalformat bringen. Leider kenne ich mich mit IEEE 754 überhaupt nicht aus. Ich habe zwar gelesen, was z.B. in der Wikipedia darüber steht, aber das ist mir ehrlich gesagt zu hoch. Jedenfalls zu hoch, als daß ich daraus ein Excel-Makro basteln könnte.
Das Einlesen der Bytes ist kein Problem, so weit bin ich schon. Auch die Umwandlung in Hexadezimalschreibweise ist kein Thema. Aber wie kriege ich jetzt die dahintersteckenden Fließkommazahlen heraus? Ich habe es schon mit Funktionen wie CDbl() probiert, aber was dabei rauskommt, hat mit den tatsächlichen Zahlen, die ich von einer Auflistung kenne, nichts zu tun. Es ist schon komisch: Excel basiert auf IEEE 754, bietet aber keine Konvertierungsfunktion. Oder sehe ich hier nur den Wald vor lauter Bäumen nicht?
Es geht übrigens nicht um eine 1:1 Umsetzung von IEEE 754. Leichte Rundungsfehler und Spezialfälle sind kein Thema. Es geht lediglich um positive und negative Zahlen im Bereich von etwa +/-2000 mit maximal 4 Nachkommastellen. Der Rest ist uninteressant.
Frage also: Kennt jemand ein Excel-Makro oder ein Add-In, das IEEE 754 nach Dezimal konvertieren kann?

Beiträge zum Forumthread

Beiträge zu diesem Forumthread

Betreff

Datum

Anwender

Nein, das funktioniert leider auch nicht. Damit bekomme ich dieselben falschen Werte wie mit meiner Methode. Ich hatte die Bytes nacheinander eingelesen, in Hex umgewandelt (das macht mein Makro sowieso für andere Zwecke) und dann an CDbl() verfüttert. Mit beiden Methoden bekomme ich viel zu große oder viel zu kleine Zahlen, oft auch mit falschem Vorzeichen.
Beispiel: Sollwert ist 138,538.
Die Bytefolge in der Datei ist (in Hex): 40 61 51 38 57 91 97 E4.
Dein Beispiel oben ergibt den Wert -3,736...E+176. Und das, obwohl da korrekt 8 Bytes eingelesen werden, das habe ich überprüft.
Ich vermute, daß Excel bzw. VBA hier erst noch eine Interpretation der eingelesenen Bytes vornimmt (z.B. als "normale" Hex-Zahl), bevor die eigentliche interne Speicherung als Double passiert.
Aber egal. Ich habe die Lösung selber gefunden. Folgendes stammt aus einem archivierten Usenet-Posting in microsoft.public.de.vb und funktioniert hervorragend (ich habe nur die Benennung der Typen und den Source-String verändert):


Public Type IEEEDouble
Value As Double
End Type
Public Type IEEEBytes
Bytes(7) As Byte
End Type
Public Sub Main()
Dim MD As IEEEDouble
Dim MB As IEEEBytes
Dim I As Long, J As Long
Dim Source As String
Source = "40615138579197E4"
For I = 15 To 0 Step -2
MB.Bytes(J) = CByte("&H" & Mid$(Source, I, 2))
J = J + 1
Next
LSet MD = MB
Debug.Print MD.Value
End Sub

So ganz 100-prozentig verstehe ich zwar noch nicht, was da passiert, aber der Trick ist wohl - neben der umgedrehten Reihenfolge der Bytes - daß hier eine direkte Konvertierung der Variablen im Speicher mittels LSet gemacht wird, damit Excel bzw. VB(A) nicht interpretierend dazwischenfunkt. Das geniale daran ist, daß sich diese Methode auch sehr leicht so modifizieren läßt, daß ich direkt die eingelesene Bytefolge auswerten kann, ohne sie erst in Hex umwandeln zu müssen, was mir sehr entgegenkommt.
Übrigens haben CDbl() und Co. bei mir auch mit umgedrehter Bytefolge keine vernünftigen Ergebnisse gebracht. Das hier scheint also wirklich der einzige Weg zu sein, "Interpretationen" der Zahlen zu verhindern.

Beliebteste Forumthreads (12 Monate)

Konvertierung IEEE 754 (8 Byte) --> Dezimal

2 Beiträge zum Forumthread Beiträge zu diesem Forumthread

VBA Beispiele zu verwandten Themen

Beliebteste Forumthreads (12 Monate)

Beliebteste Forumthreads (12 Monate)

2
Beiträge zum Forumthread

Beiträge zu diesem Forumthread