Dateiformat "erfinden" - gibt's da schon was in LAZARUS ?

[PeterS]

Hallo zusammen,

ich habe die letzte Zeit an einem Programm gearbeitet, das "Daten" einsammelt (konkret: von RS485).
Jetzt soll es (was im ersten Anlauf schon funktioniert) die Rohdaten binär speichern.
( In der tiefsten Entwicklungsphase waren es noch TXT-Dateien, also HEX als Text, damit ich den Mist besser lesen konnte .. )

Um die Daten selber geht es aber garnicht. Mich treibt um,
wie ich jetzt am besten ein "zukunftssicheres" Datei-Format für die Daten "erfinden" kann.
Selber habe ich schon "zu Fuß" RIFF-, BMP- und DBF-Dateien eingelesen.
Das sind aber - allein wegen der Längenbeschränkung durch 4-Byte-Felder - quasi veraltete Strukturen.
An MXF hatte ich mich auch mal probiert, aber das ist eine Höllenmaschine ..


Gibt es irgendein offenes CHUNK, TAGGED oder CONTAINER-Format, für das es in LAZARUS
schon eine Basis-Unterstützung gibt ? Ich möchte nicht vor die Pumpe laufen und das Rad neu erfinden.
XML kommt aus meiner Sicht nicht in Frage, wenn das XML-Dokument Binärdaten enthalten soll,
müssen diese Daten zu Text umkodiert werden. So einen sinnlosen rechenintensiven Schritt möchte ich vermeiden.


Gibt's da was in LAZARUS ?

[fliegermichl]

Am einfachsten ist es wohl die Daten in einem Stream zu speichern. Du musst halt nur die Informationen über die Länge der gespeicherten Daten mitspeichern, damit du beim lesen weisst, wieviel ausgelesen werden muss.

[af0815]

JSON und/oder XML ? Sind sehr verbreitet und können alles aufnehmen (wenn es entsprechend aufbereitet ist). Und der vermeintlich sinnlose Schritt ist aber genau der, der die Daten dann universell macht. Und Hex ist dort auch nicht unbedingt der schlechteste Container für Binärdaten)

[Joh]

Wenn du RS485 einliest, dann hast du doch wahrscheinlich auch Zusatzinfos:
- wann eingelesen
- von welchem Port
- etc.

Warum dann nicht eine Datenbank nehmen mit den Zusatzinfos als filterbare Felder und einem BLOB für den Stream?
Es muß ja nix weltbewegendes sein. Eventuell reicht ja SQLite oder auf jeden Fall Firebird portable.

[PeterS]

Am einfachsten ist es wohl die Daten in einem Stream zu speichern.
Du musst halt nur die Informationen über die Länge der gespeicherten Daten mitspeichern, damit du beim lesen weisst, wieviel ausgelesen werden muss.

ich schreibe die einzelnen Datenblöcke als String weg (mit TFileStream), die Strings haben von Natur aus eine Länge.
Das schreiben und lesen der Rohdaten im "Datenblock" ist also kein Problem - funktioniert.

[PeterS]

Wenn du RS485 einliest, dann hast du doch wahrscheinlich auch Zusatzinfos:
- wann eingelesen
- von welchem Port
- etc.

Exakt. Mit TDateTime als Zeitstempel.
Zur Zeit noch konvertiert zu einem String [YYYY-MM-DD, hh:mm:ss:mmm]

Die COM-Port-Nummer ist bei mir egal, die ist immer dieselbe.
Resp. es kommt über IP rein, per RS485 <=> LAN-Adapter.

Warum dann nicht eine Datenbank nehmen mit den Zusatzinfos als filterbare Felder und einem BLOB für den Stream?
Es muß ja nix weltbewegendes sein. Eventuell reicht ja SQLite oder auf jeden Fall Firebird portable.

Ich kann damit leben, die (unterschiedlich langen) RS485-Datenblöcke an Stück wegzuschreiben.
Mir kommt aber mit Sicherheit in den Sinn, Datenblöcke mit anderen Inhalten wegzuschreiben.
Da möchte ich mir keine Steine in den Weg legen.

Datenbank-Format habe ich im Auge, das kommt am Ende auch noch. Da sollen aber nur die sinnvollen, nötigsten Daten rein.
Die "Maschine" verschickt über RS485 jede Menge unnötigen, redundanten, aber auch völlig sinnlosen Datenmüll.

[PeterS]

JSON und/oder XML ? Sind sehr verbreitet und können alles aufnehmen (wenn es entsprechend aufbereitet ist). Und der vermeintlich sinnlose Schritt ist aber genau der, der die Daten dann universell macht. Und Hex ist dort auch nicht unbedingt der schlechteste Container für Binärdaten)

=>

XML kommt aus meiner Sicht nicht in Frage, wenn das XML-Dokument Binärdaten enthalten soll,
müssen diese Daten zu Text umkodiert werden. So einen sinnlosen rechenintensiven Schritt möchte ich vermeiden.

ich brauche die Rohdaten in binärer Form zum interpretieren.
Encodieren in TXT, und später wieder zurück in Binär finde ich nicht gut.
Das wäre ja das, was ich seit Beginn der Entwicklung des Programms mache - TXT-Dateien mit HEX-Ketten ..

Das Endprodukt wären aber am Ende nur die nötigen, herausgefilterten Daten, abgespeichert in einem Datenbank-File.
So weit bin ich aber noch nicht. Bin noch im tiefsten Schlamm der "ersten Phase" der Programm-Entwicklung.

[Zvoni]

Ist vom Prinzip her dasselbe wie ein "mp3": Du hast "Metadaten" (Zeitstempel, weiterführende Bezeichnungen, Bild, Interpret, Titel etc.) und die Binärdaten (die "Musik").

Heisst: Orientier dich daran, wie ein mp3 aufgebaut ist, und schau, ob du daraus was ableiten kannst.

Wäre zumindest mal ein erster Ansatz

[PeterS]

Okay, ich habe jetzt was gefunden, wo ich mich mal durchfresse ..

Designing File Formats
https://fadden.com/tech/file-formats.html

[PeterS]

JSON und/oder XML ? Sind sehr verbreitet und können alles aufnehmen ..

Das hier habe ich auch noch gefunden gerade :

Binary XML
https://en.wikipedia.org/wiki/Binary_XML

[PeterS]

JSON und/oder XML ? Sind sehr verbreitet und können alles aufnehmen ..

Das hier habe ich auch noch gefunden gerade :

Binary XML
https://en.wikipedia.org/wiki/Binary_XML

... bin aber auf Anhieb wenig begeistert ..

"It really depends on what you're doing. It should be as simple as possible and not simpler. I see a lot of other people pushing XML. I strongly discourage the use of XML. XML is an over-specified mess. The first question would be do your data structures have branches. Meaning are they lists of lists or lists of maps or such? If no, then a simple sequence of text records might be good."

[PeterS]

Nachdem ich jetzt einiges gelesen habe, probiere ich es wohl mal mit der prinzipiellen Architektur von PNG.

http://libpng.org/pub/png/spec/iso/inde ... -signature

Das scheint mir durchdachter und logischer als die älteren Datei-Konstrukte.
Ist aber immer noch sehr "simpel" von der Architektur her.

[af0815]

Es geht ja auch mit TCollection https://wiki.freepascal.org/TCollection

Du bringst deine Daten in ein TCollectionItem ein und die ganze Collection serialisiert das für dich. Die TCollection Geschichte ist was altes, was stabil läuft. Damit kannst du genaugenommen alles serialisieren und somit speichern und laden.

Ist ein alter Hut, was du da über PNG ausgegraben hast. Das ging schon unter BP3 unter DOS. Header (Type, Länge) und dann die Daten und zu letzt ein CRC. Damit hat man Daten auf die Floppy gebracht oder mit einem Modem auf einen anderen Computer

[PeterS]

Es geht ja auch mit TCollection https://wiki.freepascal.org/TCollection

Du bringst deine Daten in ein TCollectionItem ein und die ganze Collection serialisiert das für dich. Die TCollection Geschichte ist was altes, was stabil läuft. Damit kannst du genaugenommen alles serialisieren und somit speichern und laden.

Vielen Dank für den Hinweis - das muss ich mir genauer anschauen !

Bei mir sind die Raw Daten zur Zeit in einem TStringArray.
Da ist das wegschreiben ja auch kein Problem.


Aber wie gesagt, es geht nicht um den Inhalt (die Daten),
ich suche nach einem Template für ein (modernes) Fileformat,
das nicht aus Tradition das alte 2 oder 4 GB Dateigrößen-Limit hat.

Ist ein alter Hut, was du da über PNG ausgegraben hast. Das ging schon unter BP3 unter DOS. Header (Type, Länge) und dann die Daten und zu letzt ein CRC. Damit hat man Daten auf die Floppy gebracht oder mit einem Modem auf einen anderen Computer

Wenn ich nix finde, muß ich halt auf alte Hüte zurückgreifen

[schoschy]

Wenn du deine Daten zuordnen kannst, dann würde ich JSON machen.
Ich hab hier beispielsweise AT commands oft anliegen.

Da pack ich mir die einzelnen anfragen in JSON

also frei runtergebrochen
request:xy
value1:1
value2:2
value3:3

"echo antwort"
irgendwelche zusatzinfos
OK

Und das setz ich dan in eine JSON zur darstellung auf der console, wenn ich mitlesen will.

Code: Alles auswählen

{"anfrage":
{"command":"request",
"type":"xy",
"Value1":1,
"Value2":2,
value3:3},
"Antwort":[...Ich hätte ein besseres beispiel machen sollen, keine lust weiter zu tippen:)...] //Hier ein Array, weil durchaus mehrere Sachen vor dem OK kommen. 
}

Hat natürlich den Vorteil, dass man es direkt in Objekte usw. umwandeln kann und auch anhand von Feldern an Funktionen "casen".
Ich hab das auch mit Bytes - Da ist die JSON textausgabe halt noch als Hex umgebaut.
Mit xml usw. ist es genauso.
Da musst du halt die spec dazu kennen oder erstmal durch die weiten der Hexwelt durchtesten.

Das ist bei mir aber auch geräteabhängig.
Irgend ne Kiste die einen kontakt auf und zu macht, klassifizier ich auch nicht.

Gruß