Yjuq's File Format - *.yff

  • Hallo o/

    Aus verschiedenen Gründen brauchte ich ein Dateiformat, welches Hauptsächlich Konfigurationen speichert. Mein erster Gedanke war logischerweise eine simple *.ini Datei. Jedoch war das Format leider noch viel zu unflexibel für mein Vorhaben. Andere Dateiformate waren und sind auch viel zu kompliziert (z.B. JSON) um schnell mal einen Parser dafür zu schreiben. Also hatte ich mir überlegt, wie kann man ein Dateiformat so simpel wie möglich halten und dennoch sämtliche Möglichkeiten offen halten?

    Lustigerweise hatte ich dann auch eine Idee. Der Parser dazu war auch schnell geschrieben (obwohl dieser sicherlich mit String Funktionen um einiges schneller wäre). Ich nenne das Format Yjuq's File Format oder kurz: YFF - *.yff

    Das Prinzip dieses Formates ist extrem simpel. Du wählst dir dein Delimeter und Escape Zeichen aus. Man kann sich auch mehrere aussuchen. Zu einfachen Demonstationszwecken benutze ich folgende:

    Delimeter: < und >

    Escape: \

    Alles was zwischen den Delimeter ist wird als Datensatz gewertet, alles was direkt nach einem Escape Zeichen in einem Datensatz kommt, wird ebenfalls als Datensatz gewertet. Das bedeutet dass die Escape Zeichen hauptsächlich dazu dienen, ebenfalls die Delimeter als Datensatz zu erkennen. Logischerweise kannst du damit auch Escape Zeichen als Datensatz werten lassen. Alles andere, was nicht zwischen Delimeter steht, wird schlichtweg ignoriert.

    Dieses Dateiformat erlaubt es das Dateiformat frei zu bestimmen und dennoch die Datensätze zu deklarieren. Die ignorierten Zeichen können als Kommentare genutzt werden oder für weitere Datensätze für andere Delimeter und Escape Einstellungen. Da bleibt es eurer Fantasie überlassen.

    Hier einmal ein Beispielskript mit dem Parser dazu:

    Der Parser selber schmeißt euch einfach eine Liste mit allen Datensätzen zu. Im Index 0 ist immer die Anzahl der Datensätze im Array. Wie Ihr die Datensätze interpretiert bleibt euch überlassen. Hier mal ein einfaches Beispiel um Daten im Key = Value Format zu speichern:

    Und hier das Skript:

    Nun denn, für meine Zwecke jedenfalls nutzbar. Ich dachte ich teile das mit euch. Wer einen besseren Parser schreiben möchte, nur zu. Ich hantiere mit eine kleine Menge an Daten dh. reicht mir die Geschwindigkeit aus. Jedoch würde ich mich natürlich über ein free update freuen. :P

    Hauptsächtlich geht es bei dem Post darum eine einfache Möglichkeit zu haben Datensätze in menschenlesbarer Form zu speichern und abzurufen. Dabei sollte das Format nicht kompliziert sein aber funktionsreich genug um auch Datensätze zu erzeugen die via Software dann richtig aufbereitet werden können. Eine einfache Array Liste reicht da meiner Ansicht nach aus. Darauf lassen sich weitere Filter und Bedingungen anknüpfen um das Dateiformat zu extenden. Sprich: Datensätze weiter auswerten und entsprechend so zu kategorisieren wie gewünscht.

    4 Mal editiert, zuletzt von Yjuq (16. August 2020 um 23:52)

    • Offizieller Beitrag

    Mein erster Gedanke war logischerweise eine simple *.ini Datei. Jedoch war das Format leider noch viel zu unflexibel für mein Vorhaben.

    Vielleicht solltest du mal eine Bsp. generieren, dass die erforderliche Flexibilität beinhaltet. Das hier gezeigte Bsp. ist (deutlich einfacher lesbar) auch in einer INI abbildbar.

    Das Prinzip dieses Formates ist extrem simpel. Du wählst dir dein Delimeter und Escape Zeichen aus.

    Wenn diese Parameter frei wählbar sind, sollten sie auch im erstellten Dokument extra beschrieben werden, damit der Parser weiß, welche in der aktuellen Datei verwendet werden.

    Sind keine definiert, kann man ja Standardwerte verwenden.

  • Vielleicht solltest du mal eine Bsp. generieren, dass die erforderliche Flexibilität beinhaltet. Das hier gezeigte Bsp. ist (deutlich einfacher lesbar) auch in einer INI abbildbar.

    Verstehe dein Einwand nicht. Die INI Datei zwingt dich in folgendes Format:

    [Section]

    Key=Value

    Kommentare müssen mit einen ; am Zeilenanfang beginnen

    Zumal es auch nicht möglich ist folgendes zu machen:

    [Section]

    Key==Value

    Wie kann ich den Key jetzt "Key=" nennen und den Value auf "Value" setzen?

    Kurz, die INI und dazugehörigen AutoIt Funktionen schränken dich ein. Mein Format soll eben das Problem umgehen. Es geht hauptsächlich darum die Einschränkungen, wie die Datensätze in der Datei hinterlegt werden müssen, lockerer zu gestalten. Ich hab meine Gründe dazu und auch sogar ein Anwendungsfall wo die INI schlichtweg versagt. Ich dachte ich teile meine Gedanken dazu weil ein Parser für diese Variante schnell geschrieben ist.

    • Offizieller Beitrag

    den Key jetzt "Key=" nennen

    Genau das meinte ich doch mit dem Hinweis auf die Flexibilität.

    Hättest du einfach geschrieben, ich möchte auch ein "=" (oder Ähnliches) im Key verwenden können, wäre das Ziel klarer.
    Ich hatte keineswegs die Absicht, dein Werk madig zu machen, mir war nur nicht klar, welchen Vorteil ich damit erreichen kann.

    Also genieße bei der Hitze ein Hopfenkaltgetränk und kühle deinen Geist. ;)

  • Ich hatte keineswegs die Absicht, dein Werk madig zu machen

    Huh, davon bin ich auch nicht ausgegangen. Text im Internet ist sowieso immer schwierig zu interpretieren wenn es um die momentane emotionslage des Author geht. ^^

    Hauptsächlich sollte mein Beispiel demonstrieren wie das Dateiformat funktioniert, nicht welche Vorteile es gegenüber anderen bietet und welche Nachteile. Darum geht es auch gar nicht. Das ist nur entstanden da ich einen spezifischen Anwendungsfall hatte wo vorhandene Dateiformate schlichtweg versagen oder es eben kein Parser dafür existiert für meine genutzte Programmiersprache. Beispiel JSON - Es gibt zwar zig implementationen, diese sind aber alle Programmiersprachen spezifisch.

    Welp, es musste was her was extrem einfach zu parsen ist. Letzten endes ist das ganze gestern Nacht in einer halben Stunde entstanden. xD

    Einmal editiert, zuletzt von Yjuq (17. August 2020 um 15:49)

  • Da du ja so nett fragst 8o

    Hier die kurze/schnelle Variante mit RegExp:

    Ich hatte mal wieder lust auf etwas RegExp ^^

    MfG Kanashius :)

  • Kannst du das genauer erläutern?

    Ich meine damit dass es keinen generellen Parser gibt den du für jede Programmiersprache einfach nutzen kannst. Einen JSON Parser in Form einer DLL zum Beispiel. Stattdessen hat jede Programmiersprache eine eigene Implementation dafür.

    https://www.json.org/json-en.html

    Scroll mal runter auf der Seite, da fängt es schon an. Sagen wir mal, ich hab jetzt eine Programmiersprache die keinen JSON Parser von sich aus hat, viel spaß den Parser zu schreiben.

  • Ich meine damit dass es keinen generellen Parser gibt den du für jede Programmiersprache einfach nutzen kannst. Einen JSON Parser in Form einer DLL zum Beispiel.

    Es gibt JSMN den du als DLL kompilieren und einbinden kannst und es gibt jq den du von jeder beliebigen Programmiersprache aus über die Kommandozeile bedienen kannst..

    Wurde beides übrigens schon für AutoIt umgesetzt.

    Und warum muss überhaupt unbedingt ein und derselbe Parser in allen Programmiersprachen zur Verfügung stehen? Es reicht doch das alle Parser in den jeweiligen Programmiersprachen sich an den Standard halten und gut ist. Wo ist da ein Mehrwert? Zumal dein Dateiformat an diesen Umstand ja auch gar nichts ändert - es liegt ja nur für AutoIt ein Parser vor und der kann eben nicht z.B. als DLL in anderen Programmiersprachen weiterverwendet werden.

    Mal abgesehen davon, dass mit JSON halt noch viel viel mehr möglich ist - insbesondere Verschachtelung von Daten.

    Sagen wir mal, ich hab jetzt eine Programmiersprache die keinen JSON Parser von sich aus hat, viel spaß den Parser zu schreiben.

    "Sagen wir mal" - welche denn genau? Selbst für COBOL gibt es JSON Impementierungen.

    Und zum Thema "viel Spaß den Parser zu schreiben": Jo hat wirklich Spaß gemacht ;)

    Einmal editiert, zuletzt von AspirinJunkie (17. August 2020 um 21:41)