Binärdateien und Headerdateien

[Schmand Paste (Gast)]

Hi Leuts,

ich würde gern mal Eure Meinung hören.

Es müssen Messdaten in einer Datei abgelegt werden. Mehrere Messkanäle 
zeichnen die Daten auf. Die einzelnen Kanäle haben Merkmale wie Namen, 
Einheit ... . Auch muss bekannt sein, wie die binäre Datei aufgebaut 
ist.

Ist es sinnvoller, zwei Dateien zu erstellen - einmal den Header zu der 
binären Datei, wo allgemeine Infos drinnen stehen wie Bezeichnung der 
Kanäle, Zahlenformat ... und dann die binäre Datei separat abzuspeichern 
- oder alles in eine Datei zu packen und dann ein Steuerzeichen zu 
nehmen, dass signalisiert, hier ist der Dateiheader zu Ende, ab der 
nächsten Position fangen die Binärdaten an?

Bin mir da etwas unschlüssig, was besser ist und würd mich freuen, wenn 
mir der eine oder andere von Euch dazu was sagen koennte.

[Udo S. (urschmitt)]

XML Datei

[Schmand Paste (Gast)]

XML heisst zwei separate Dateien? Die XML-Datei als Header zur allg. 
Beschreibung und dann die binäre Datendatei?

[Udo S. (urschmitt)]

http://de.wikipedia.org/wiki/Extensible_Markup_Language

[gk (Gast)]

Schmand Paste schrieb:
> Ist es sinnvoller, zwei Dateien zu erstellen

Das hat man in der Steinzeit der Messtechnik so gemacht. Vermutlich weil 
es Messkarten gab, die nach dem Start die Rohdaten direkt auf die Platte 
geschrieben haben.

gk

[Sven P. (Gast)]

Kommt drauf an. Neuer Trend ist aber in der Tat, alles was bei drei 
nicht auf den Bäumen ist, mit XML zu erschlagen. Davon rate ich dringend 
ab.

Ich würde das an der Menge der Messdaten festmachen. Wenn du tausende 
identisch strukturierte Messreihen in einzelne Dateien packst, sind die 
Header irgendwann größer als die Daten.

Warum willst du überhaupt Binärdaten? Die sind immer unpraktisch zu 
handhaben. Wenn es denn geht, würde ich einfach 
komma-/tabulatorseparierte Dateien verwenden. Erste Zeile mit 
Überschriften, fertig. Simpel und lesbar.

[Udo S. (urschmitt)]

Mal deutlicher:
Wer oder was soll das Lesen?
Dein eigenes Programm? Dann machs wie es für dich am einfachsten ist.
Excel und co?
Dann machs in ne CSV
Irgendjemand anderes? Dann CSV oder definiere eine XML.

Nachtrag: Sven war schneller: CSV mit ggf. 1. Zeile Beschreibung

[Schmand Paste (Gast)]

naja, mal rechnen - in der Regel 5 Messkanäle, Abtastfrequenz 2kHz, 
jeder Wert 8 Byte groß, eine Aufzeichnung kann auch mal 24h dauern ...

5*2000*8Byte*24*60*60 = 6912000000 Byte
= 675kByte
= 6591,8MByte

Naja, speicher ich nun alles im ASCIi-Format ab wie CSV oder so, dann 
ist ein Wert wohl einfach mal doppelt so groß, dann noch Trennzeichen 
... -ich würd einfach mal grob überschlagen - da brauch ich mindestens 
den 2,5fachen Speicherplatz anstelle im Binärformat ...

[Rufus Τ. F. (rufus)]

Schmand Paste schrieb:
> da brauch ich mindestens
> den 2,5fachen Speicherplatz anstelle im Binärformat

Du könntest die Daten der Handhabbarkeit in Häppchen aufteilen und mit 
ZIP o.ä. komprimieren.

Auch wenn die Rohdatengröße sich verdreifacht, ist der Vorzug von 
allgemein ohne Spezialsoftware verarbeitbare Daten nicht zu 
unterschätzen.

[Peter II (Gast)]

Rufus Τ. Firefly schrieb:
> Auch wenn die Rohdatengröße sich verdreifacht, ist der Vorzug von
> allgemein ohne Spezialsoftware verarbeitbare Daten nicht zu
> unterschätzen.

es gibt auch XML als Binary. z.b. ASN1 - das ist genauso standardisiert.

[Rufus Τ. F. (rufus)]

Peter II schrieb:
> ASN1 - das ist genauso standardisiert.

Aber ein Krampf im Arsch, wenn man es decodieren möchte.
Die Qualität der ASN.1-Decodierung war zur Hochzeit der ISDN-TK-Technik 
das Unterscheidungsmerkmal zwischen Firmen, die es tatsächlich 
draufhatten und denen, bei denen es meistens funktionierte ... das 
D-Kanal-Protokoll ist bei ISDN in ASN.1 codiert.

Außerdem: Kann Excel ASN.1-Dateien verarbeiten? Kann 
Libre/Open/Sonstwas-Office das?

[Sven P. (Gast)]

Vielleicht nicht ganz unerhebliche Anmerkung:
Eine solche Messreihe von etwa 6 Gigabytes geht spätestens auf FAT32 in 
die Hose. Auch das wäre schon ein Grund, kleinere Pakete zu binden.

[Thomas B. (escamoteur)]

Hängt immer sehr davon ab, wie Du die Daten weiterverarbeiten willst. 
Ich verwende in meinen aktuellen Projekten oft JSON als Format, ist 
übersichtlicher als XML und kann mit entsprechenden Biblitheken leicht 
geparst werden. Wenns mit Excel betrachtet werden soll, würde ich auch 
einfach CSV nehmen.