INI in JSON umwandeln

In vielen deutschen Mittelstandsbetrieben laufen Fertigungs- oder Warenwirtschaftsprogramme seit Jahrzehnten unverändert weiter, weil eine funktionierende Windows-Anwendung ohne zwingenden Grund nicht angerührt wird — und ihre Konfiguration liegt fast immer als INI-Datei neben der ausführbaren Datei. Wer heute ein Skript oder einen Dienst schreibt, der dieselben Einstellungen lesen soll, hat in praktisch jeder Sprache einen JSON-Parser zur Hand und selten einen zuverlässigen INI-Parser.

Diese Umwandlung übersetzt genau diese Datei einmalig in JSON, das sich anschließend versionieren, gegen ein Schema prüfen und in ein modernes Projekt einbinden lässt, ohne dass irgendwo im Code ein selbstgeschriebener INI-Parser mitgeschleppt werden muss.

Das Ergebnis ist ein einziges JSON-Objekt. Jede Abschnittsüberschrift wird zu einem eigenen Schlüssel mit einem verschachtelten Objekt, und die Schlüssel-Wert-Paare darunter werden zu dessen Eigenschaften. Zeilen, die vor der ersten Abschnittsüberschrift stehen — der globale Block, den viele Werkzeuge kennen —, landen auf der obersten Ebene, gleichberechtigt neben den Abschnittsobjekten.

Das ist die gesamte strukturelle Übersetzung, weil eine INI-Datei nichts weiter zu übersetzen bietet. Interessant wird es nicht bei der Form, sondern bei den Werten, die den Sprung nicht ganz so wörtlich überstehen wie die Struktur.

Eine INI-Datei kennt keine Typen. Alles hinter dem Gleichheitszeichen ist Zeichenkette, und jedes lesende Programm entscheidet selbst, was diese Zeichen bedeuten sollen. Diese Umwandlung entscheidet so: Die exakten Zeichenketten true und false werden zu JSON-Wahrheitswerten, alles, was sich als endliche Zahl lesen lässt, wird zu einer JSON-Zahl, und der Rest bleibt Zeichenkette.

Für die meisten Konfigurationswerte ist das die richtige Entscheidung und erspart einen eigenen Umwandlungsschritt auf der anderen Seite. Ein Port kommt als 8080 statt als „8080" heraus, ein Zeitlimit als 30. Der Preis ist, dass der Leser eine Menge nicht von einer Kennung unterscheiden kann, und genau dort entsteht der Schaden.

Vier Fälle scheitern leise, und alle vier tauchen in echten Konfigurationsdateien auf. Eine mit Nullen aufgefüllte Kennung wie 007 wird zur Zahl 7. Ein Unix-Dateimodus wie 0755 wird zu 755 — ein anderer Modus, der so auch angewendet würde. Eine hexadezimale Maske wie 0x1F wird zu 31, im Wert korrekt und in jeder Protokollzeile, die sie zurückschreibt, falsch lesbar. Eine als Versionsnummer gedachte 1.0 wird zur Zahl 1.

Der vierte Fall ist subtiler: Eine Ganzzahl über etwa neun Billiarden verliert Genauigkeit, weil JSON-Zahlen IEEE-Doubles sind. Eine 64-Bit-Kennung wie 9223372036854775807 kommt als 9223372036854776000 heraus, ohne jede Warnung. Steckt in einem Schlüssel eine Seriennummer oder eine Kontonummer, sollte der Wert in der INI-Datei mit einem nicht-numerischen Zeichen versehen werden, oder die Zahl wird anschließend im JSON von Hand korrigiert.

Es lohnt sich zu wissen, welche Schlüssel gar nicht geprüft werden müssen. Alles mit einer angehängten Einheit ist sicher — ein Speicherlimit wie 128M bleibt die Zeichenkette „128M". IP-Adressen wie 127.0.0.1 bleiben unangetastet, ebenso Uhrzeiten wie 08:00, Pfade und alles, was einen Buchstaben enthält, der nicht Teil einer Zahl ist.

Auch ein Wert mit einem Gleichheitszeichen bleibt erhalten, weil eine Zeile nur am ersten Gleichheitszeichen geteilt wird — praktisch für eine Verbindungszeichenkette. Umschließende Anführungszeichen werden entfernt, aber nur das äußere Paar; ein unquotierter Wert wird an beiden Enden getrimmt, ein in Anführungszeichen eingeschlossener behält seine innere Formatierung. Nur innerhalb solcher Anführungszeichen wirkt ein Backslash als Escape-Zeichen, was etwa einen Windows-Pfad wie C:\neu unquotiert wörtlich erhält, in Anführungszeichen aber nicht.

Windows-INI-Dateien und php.ini verwenden weit häufiger On und Off als true und false, und diese Umwandlung behandelt sie nicht als Wahrheitswerte. Sie kommen als die Zeichenketten „On" und „Off" heraus — nachvollziehbar, weil es eben Wörter sind, und trotzdem fast nie das, was ein Skript erwartet, das mit der JSON weiterarbeitet.

Genauso wenig werden yes und no erkannt und bleiben deshalb ebenfalls Zeichenketten. Anders 1 und 0, wenn sie als Schalter gemeint waren: Diese beiden gelten der Umwandlung als Zahlen und kommen als JSON-Zahlen 1 und 0 heraus, nicht als Wahrheitswerte. Eine Konfiguration mit engine gleich On und debug gleich false hat danach drei verschiedene Arten von Ja oder Nein in sich — Zeichenkette, Zahl, Wahrheitswert —, und die konsumierende Anwendung muss selbst entscheiden, was als wahr gilt.

Die Reihenfolge der Schlüssel bleibt fast überall erhalten, was bei einem Diff-Vergleich zählt: Abschnitte kommen in der Reihenfolge heraus, in der sie standen, und Schlüssel innerhalb eines Abschnitts behalten ihre Position.

Die Ausnahme sind numerische Schlüssel. JavaScript-Objekte stellen ganzzahlig aussehende Schlüssel aufsteigend sortiert an den Anfang, noch vor jeden anderen Schlüssel — ein Abschnitt, geschrieben als 10, 2, name, kommt deshalb als 2, 10, name heraus. Server-Listen, geordnete Regeln oder Playlist-Einträge, die Zahlen als Schlüssel nutzen, werden dadurch umsortiert. Trägt die Reihenfolge die eigentliche Bedeutung, gehört dieser Abschnitt eigentlich in ein JSON-Array, und das ist dann eine manuelle Nacharbeit.

INI hat keine feste Spezifikation, und Implementierungen gehen mit doppelten Abschnittsüberschriften unterschiedlich um. Dieser Reader beginnt bei jeder erneuten Überschrift einen frischen, leeren Abschnitt — eine Datei mit [logging] an zwei Stellen behält also nur die Schlüssel aus dem zweiten Block. Der erste ist weg, und die JSON ist trotzdem gültig; nichts meldet den Verlust.

Dieses Muster kommt vor, wenn Konfigurationen aus mehreren Dateien zusammengesetzt werden — eine Basisdatei plus ein umgebungsspezifischer Zusatz, angehängt. Vor der Umwandlung lohnt sich eine kurze Suche nach doppelten Überschriften. Doppelte Schlüssel innerhalb eines Abschnitts verhalten sich genauso: Die letzte Zuweisung gewinnt.

Das ist der Verlust, der strukturell bedingt ist, nicht zufällig. INI unterstützt Kommentare und macht davon reichlich Gebrauch; JSON kennt gemäß RFC 8259 überhaupt keine Kommentarsyntax. Selbst eine Umwandlung, die Kommentare erhalten wollte, hätte nirgendwo einen Platz dafür, außer eine Konvention wie einen _comment-Schlüssel zu erfinden, den ohnehin niemand ausliest.

Bei einer Konfigurationsdatei ist das häufig der größte Verlust überhaupt: die Notiz, warum ein Wert absichtlich vom Standard abweicht, der auskommentierte Block als Beispiel, die Zeile, die einen Wert als kundenspezifisch markiert — nichts davon kommt herüber. Die ursprüngliche INI-Datei gehört deshalb weiter in die Versionsverwaltung, nicht nur die JSON, die daraus entsteht.

Lesen der INI und Schreiben der JSON sind reines JavaScript in diesem Tab; die Konfiguration verlässt das eigene Gerät nicht. Das zählt bei diesem Paar besonders, weil INI-Dateien in Windows-Software regelmäßig Datenbankpasswörter, Servicekonten oder API-Schlüssel im Klartext enthalten, gerade in älteren Anwendungen, die vor der heutigen Selbstverständlichkeit von Secret-Management-Systemen entstanden.

Umwandlungen dieser Dateigröße sind augenblicklich fertig, mit einer Obergrenze von 100 MB auf der kostenlosen Stufe, die keine Konfigurationsdatei je erreicht. Die eigentliche Grenze ist nicht die Größe, sondern die Kontrolle: Die numerischen Werte in der Ausgabe einmal durchsehen, bevor die JSON zu der Datei wird, der alles andere vertraut.