NDJSON in INI umwandeln

Diese Kombination taucht meist bei einem Bruch zwischen zwei Systemen auf: Ein Monitoring-Tool, ein Exportskript oder ein selbst gehosteter Dienst schreibt seine Konfiguration oder seinen Export zeilenweise als NDJSON, während die Software, die das Ergebnis übernehmen soll — häufig ältere Windows-Anwendungen in kleineren Firmen, die seit Jahren unverändert laufen — ausschließlich INI liest.

Die Umwandlung überbrückt genau diese Lücke, allerdings nicht ohne Reibung. INI wurde nie für eine Liste von Datensätzen entworfen, NDJSON ist nichts anderes als genau das, und dieser Widerspruch prägt jede Zeile des Ergebnisses.

Der Bruch lässt sich nicht auflösen, nur benennen. Eine INI-Datei ist eine Sammlung benannter Abschnitte mit flachen Schlüssel-Wert-Zeilen darin — meist die Beschreibung einer einzelnen Konfiguration. Eine NDJSON-Datei ist eine Folge von Datensätzen ohne Namen, ohne bedeutungsvolle Reihenfolge und ohne feste Länge.

Es gibt keine Darstellung, die beides erfüllt. Die Umwandlung greift deshalb auf den einzigen Namen zurück, den ein Datensatz in einer Liste besitzt — seine Position: Die erste Zeile wird [0], die zweite [1] und so weiter. Das ist verlustfrei und zugleich eine Datei, deren Abschnittsnamen für sich genommen nichts aussagen.

Sind die Zeilen tatsächlich mehrere Konfigurationen — je eine pro Server, pro Umgebung, pro Mandant —, macht das Umbenennen von [0] und [1] in die tatsächlichen Namen die Datei sofort brauchbar, und die Schlüssel darunter stimmen bereits. Das ist dann die ganze Arbeit.

Handelt es sich dagegen um Daten statt um Konfiguration, hilft kein Umbenennen — die nummerierten Abschnitte sind dann die eigentliche Antwort der Umwandlung: eine Tabelle in der falschen Notation. CSV, JSON oder eine Datenbank sind das richtige Ziel für so etwas, und jedes davon ist von derselben Quelle aus nur einen Klick entfernt.

Das überrascht regelmäßig, deshalb ausdrücklich: Eine Datei mit genau einer Zeile ist immer noch eine Liste mit einem Element, und das Ergebnis ist ein Abschnitt [0] mit sämtlichen Feldern dieses Datensatzes — nicht die saubere INI-Datei, die derselbe Datensatz allein ergeben würde.

Die Lösung liegt beim Quellformat, nicht beim Nachbearbeiten: Diese eine Zeile mit der Endung .json speichern und stattdessen JSON in INI umwandeln — dort werden die obersten Felder des Datensatzes direkt zu den Abschnittsüberschriften, und die Datei sieht aus, als hätte sie jemand von Hand geschrieben. Derselbe Inhalt, ein anderer Weg, wenige Sekunden Aufwand.

INI unterstützt Abschnitte und nichts innerhalb von Abschnitten. Bei dieser Kombination ist diese eine Ebene bereits von der Datensatznummer belegt, also muss jedes Feld eines Datensatzes — einschließlich seiner ursprünglichen Verschachtelung — in den Schlüsselnamen selbst untergebracht werden.

Ein Datensatz mit einem verschachtelten Objekt für den Server, das darin einen Port trägt, ergibt eine Zeile server.port innerhalb des nummerierten Abschnitts. Nichts geht dabei verloren, aber zwei Datensätze mit derselben Struktur teilen sich strukturell nichts mehr — sie sind zwei Abschnitte, deren Schlüssel zufällig gleich geschrieben sind.

Ein Feld mit einer Liste erlaubter Hosts ergibt Schlüssel mit den Namen 0, 1 und 2 unter dem Pfad dieses Feldes. Zusammen mit den nummerierten Abschnitten kann das zu einer Zeile hosts.0 innerhalb eines Abschnitts [2] führen — lesbar, aber wenig elegant.

INI-Parser, die überhaupt Listen unterstützen, erwarten meist eine einzige Zeile mit kommagetrennten Werten, manche erwarten denselben Schlüssel mehrfach wiederholt. Keines davon entsteht hier automatisch. Kennt die Zielanwendung eine solche Konvention, ist es einfacher, die Liste bereits in der Quelle zu einer einzigen Zeichenkette zusammenzufügen, als jede Gruppe im Nachgang von Hand zu bearbeiten.

Ein JSON-true wird als true geschrieben, eine Zahl als ihre Ziffern, ein null als Schlüssel ohne alles nach dem Gleichheitszeichen, eine Zeichenkette genau wie sie war. Anführungszeichen erscheinen nur dort, wo der Wert sonst nicht wieder so ankäme, wie er hineinging — bei einem Leerzeichen am Rand, bei einem Wert, der bereits selbst mit einem Anführungszeichen beginnt und endet, oder bei einem Zeilenumbruch.

Der Zeilenumbruch ist der Fall, der es wert ist, genannt zu werden, weil ein INI-Eintrag genau eine Zeile ist. Er wird als Backslash und n innerhalb der Anführungszeichen geschrieben statt als echter Umbruch — das verhindert, dass der folgende Text zu losen Zeilen wird oder, sieht eine Folgezeile wie eine eckige Klammer aus, ein Abschnitt entsteht, der in keinem der Datensätze stand. Zertifikate, Schlüssel und eingebettete Skripte sind die üblichen Träger solcher Werte, und obwohl sie diesen Weg jetzt unversehrt überstehen, gehört ein Wert dieser Größe eigentlich in eine eigene Datei, auf die die INI-Zeile nur verweist.

INI unterstützt Kommentare, eine Zeile beginnend mit Semikolon oder Raute, und die Leseseite dieses Werkzeugs berücksichtigt beide Zeichen ebenfalls. JSON kennt so etwas nicht, also kommt die umgewandelte Datei zunächst ohne aus.

Da der eigentliche Grund für eine INI-Datei fast immer ist, dass ein Mensch sie liest oder bearbeitet, sind genau diese Zeilen die erste sinnvolle Ergänzung nach der Umwandlung: welcher Abschnitt umgebungsspezifisch ist, welcher Wert an anderer Stelle übereinstimmen muss, welchen die Anwendung ohnehin ignoriert — nichts davon konnte die Quelle mitbringen, und genau dafür ist das Zielformat gedacht.

Jeder Wert in einer INI-Datei ist Text. Ob 8080 eine Zahl ist, ob true ein Wahrheitswert ist und ob 007 seine führenden Nullen behält, entscheidet allein die Software, die die Datei einliest — Pythons configparser macht das mit getint und getboolean ausdrücklich, letzteres akzeptiert dabei auch yes, on und 1 als wahr.

Gegenüber der Quelle ist das ein Verlust, weil dort die Typen noch feststanden. In der Praxis fällt das selten ins Gewicht, weil eine Anwendung, die INI liest, ohnehin schon weiß, welchen Typ sie bei jeder Einstellung erwartet. Wichtig wird es bei Kennungen mit führenden Nullen, und die Lösung dafür liegt im Leseprogramm, nicht in der Datei.

Die einfache Faustregel für diese Kombination: Stehen im Ergebnis mehr als eine Handvoll nummerierter Abschnitte, denen sich kein echter Name geben lässt, hat die Umwandlung eine andere Frage beantwortet als die gestellte. INI beschreibt eine Sache; eine Liste von Datensätzen ist keine Sache.

Die Alternativen liegen aus derselben Datei einen Klick entfernt und passen in diesem Fall besser: CSV oder eine Tabelle, wenn ein Mensch die Datensätze ansehen soll, SQL oder Parquet, wenn eine Maschine sie abfragt, TOML, wenn tatsächlich eine Liste von Datensätzen in einer Konfigurationsdatei gewollt war — dort gibt es mit Array-of-Tables genau die Struktur, die INI fehlt.

Die Umwandlung ist reines JavaScript im Browser-Tab. Nichts wird hochgeladen, es gibt kein Konto und keine Warteschlange, und der kostenlose Tarif nimmt Dateien bis 100 MB an — eine Größe, die eine Konfigurationsdatei praktisch nie erreicht.

Das ist bei diesem Paar wichtiger, als die Dateigröße vermuten lässt. Ein Export aus einer Konfigurations- oder Monitoringquelle enthält häufig Verbindungszeichenketten, interne Hostnamen und, öfter als jemand zugeben möchte, ein Zugangsdatum, das eigentlich eine Umgebungsvariable sein sollte. So etwas an einen fremden Server zu schicken, nur um Klammern gegen Gleichheitszeichen zu tauschen, wäre ein schlechter Tausch — zu jedem Preis.