nicht angemeldet
Hi Rolf,
ich habe Deinen Code mal ein bischen aufgeräumt und zwar so, daß er nachvollzogen werden kann. D.h., daß man auch anhand des Codes sehen sollte wie die Datei aufgebaut ist. Den EAV Datentyp kann man sich ja auf verschiedene Art und Weise verinnerlichen, am Anschaulichsten als INI-Datei:
[Entity]
Attribute = Value
Und so ergibt die Datenabstraktion genau 3 Felder, die sich auch in einer binär serialisierten Datei wiederfinden: Jedes dieser Tupel besteht aus einem Teil mit konstanter und einem Teil mit variabler Länge. Konstante Länge hat, und das ist für die Wiederherstellung der Daten entscheidend, die Offsetangabe: Jeder Uint32 hat stets eine Länge von genau 4 Byte.
// elen => Länge Entity
let elen = dv.getUint32(offs, false);
offs += 4;
// alen => Länge Attribute
let alen = dv.getUint32(offs, false);
offs += 4;
// vlen => Länge Value
let vlen = dv.getUint32(offs, false);
offs += 4;
Mit diesen Längenangaben werden E, A, V bytegenau aus der Sequenz gelesen und danach die Variable offs für den nächsten Lesezyklus um diese Beträge hochgesetzt.
Wobei bytegenau bedeutet, daß man beim Serialisieren nicht etwa die Länge eines Zeichen ermittelt, sondern die Anzahl der Oktetten (Bytesemantic vs. Charactersemantic). Ansonsten ist dieser extrem einfach zu verstehende Algorithmus in jeder Programmiersprache umsetzbar.
Dateien dieser Art eignen sich hervorragend als Multimediadatein wo Texte mit Grafiken, Audio und Video gleichermaßen transportiert werden können (Hypermediadatei). Mit Sicherheit ist dieses Dateiformat auch die zwckmäßigere Alternative für multipart/form-data -- Allein hieran sehen wir doch wie hoffnungslos überholt manche Standards sind, auch der ganze MIME (Mail) Schrott der nie über ASCII 7Bit hinausgekommen ist.
Schönen Sonntag 😉
Rolf B
Matthias Apsel