INI ist nicht gleich INI: Dialekte, Kommentare und Stolperfallen beim Umwandeln

Warum es keinen INI-Standard gibt

Die meisten Datenformate haben eine Spezifikation, auf die sich alle einigen. JSON wird durch RFC 8259 und den ECMA-404-Standard beschrieben, YAML hat eine eigene, ausführliche Spezifikation, XML wird vom W3C definiert. Bei INI ist das anders: Es gibt kein offizielles, verbindliches Dokument, das festlegt, wie eine INI-Datei aussehen muss.

Das Format entstand in den frühen Windows-Versionen. Microsoft stellte mit Funktionen wie GetPrivateProfileString eine API bereit, um sogenannte Profile-Dateien mit der Endung .ini (von initialization) zu lesen. Diese API definierte zwar ein faktisches Verhalten, aber keine formale Grammatik. Andere Programme ahmten das Format nach und ergänzten es nach eigenem Geschmack. So entstanden im Laufe der Jahrzehnte viele Dialekte, die sich im Detail unterscheiden.

Für Sie als Anwender bedeutet das: Eine Datei mit der Endung .ini ist nicht automatisch nach festen Regeln aufgebaut. Ein Parser, also das Programm, das die Datei einliest, muss sich für eine Auslegung entscheiden. Genau hier entstehen die Stolperfallen, wenn Sie eine INI-Datei in JSON umwandeln. Was INI und JSON grundsätzlich unterscheidet, behandelt der Ratgeber INI oder JSON? Der Unterschied.

Die vier wichtigsten INI-Dialekte

In der Praxis begegnen Ihnen vor allem vier Dialekte. Sie sehen oberflächlich ähnlich aus, unterscheiden sich aber in wichtigen Details:

Windows-INI

Der Klassiker. Sektionen stehen in eckigen Klammern, darunter folgen key=value-Zeilen, Kommentare beginnen mit dem Strichpunkt. Werte stehen normalerweise ohne Anführungszeichen direkt nach dem Gleichheitszeichen. Diese Form ist die Grundlage, an der sich unser Konverter orientiert.

git config

Die Datei .git/config sieht aus wie INI, hat aber eine Besonderheit: Subsektionen. Eine Zeile wie [remote "origin"] definiert eine Untergruppe innerhalb der Sektion remote. Außerdem normalisiert git Schlüssel auf Kleinschreibung und erlaubt sowohl Strichpunkt als auch Raute als Kommentar.

php.ini

Die zentrale Konfigurationsdatei von PHP nutzt den Strichpunkt für Kommentare und kennt eigene Wortkonstanten wie On, Off, None sowie ausgewertete Ausdrücke wie E_ALL & ~E_DEPRECATED. Solche Konstrukte sind reines php.ini-Verhalten und werden von einem generischen Parser als gewöhnliche Strings behandelt. Mehr dazu im Ratgeber php.ini verstehen.

systemd-Unit

Service-Dateien wie nginx.service nutzen ausschließlich die Raute für Kommentare, behandeln Schlüssel case-sensitiv (es heißt ExecStart, nicht execstart) und erlauben denselben Schlüssel mehrfach, etwa mehrere ExecStartPre-Zeilen. Beim Umwandeln in JSON werden solche Mehrfach-Schlüssel typischerweise zu einem Array zusammengefasst.

Kommentarzeichen: Strichpunkt oder Raute

Die häufigste Verwirrung betrifft das Kommentarzeichen. In der klassischen Windows-INI leitet der Strichpunkt ; einen Kommentar ein. Im Unix-Umfeld hat sich dagegen die Raute # durchgesetzt, wie man sie auch aus Shell-Skripten kennt. Manche Werkzeuge akzeptieren beides, andere nur eines.

; Das ist ein Kommentar im Windows-Stil
# Das ist ein Kommentar im Unix-Stil
[server]
host=localhost
port=8080   ; Inline-Kommentar (nicht jeder Parser kann das)

Eine besonders tückische Stolperfalle ist der Inline-Kommentar, also ein Kommentar hinter einem Wert in derselben Zeile. Nicht jeder Dialekt unterstützt das. Wo er nicht unterstützt wird, landet der Text 8080 ; Inline-Kommentar komplett als Wert in JSON. Unser Konverter behandelt nur ganze Zeilen, die mit ; oder # beginnen, als Kommentar. Wenn Sie sicher gehen wollen, schreiben Sie Kommentare in eigene Zeilen.

Anführungszeichen und Leerzeichen

Wie ein Wert mit Leerzeichen oder Sonderzeichen behandelt wird, ist von Dialekt zu Dialekt verschieden. In manchen INI-Dateien stehen Werte in Anführungszeichen, in anderen nicht:

[pfade]
log="C:\Program Files\App\log.txt"
name = Max Mustermann
leer =

Hier gibt es mehrere Fragen, die jeder Dialekt anders beantwortet: Sollen die umschließenden Anführungszeichen Teil des Werts sein oder entfernt werden? Werden Leerzeichen am Anfang und Ende abgeschnitten (getrimmt)? Was bedeutet ein leerer Wert nach dem Gleichheitszeichen, ein leerer String oder kein Wert? Unser Konverter trimmt Schlüssel und Wert, entfernt ein Paar umschließender Anführungszeichen und behandelt einen leeren Wert als leeren String. Das ist eine verbreitete, vorhersehbare Auslegung, aber eben eine Entscheidung, keine universelle Regel.

Groß- und Kleinschreibung

Ob Server und server derselbe Schlüssel sind, hängt am Dialekt. Die klassische Windows-INI ignoriert die Groß- und Kleinschreibung von Sektions- und Schlüsselnamen, git config normalisiert Schlüssel auf Kleinschreibung, systemd unterscheidet strikt. JSON dagegen ist immer case-sensitiv.

Das hat eine wichtige Konsequenz: Enthält Ihre INI-Datei dieselbe Sektion einmal als [Server] und einmal als [server], dann werden daraus in JSON zwei getrennte Felder Server und server, auch wenn das ursprüngliche Programm sie als identisch betrachtet hätte. Prüfen Sie nach dem Umwandeln, ob unbeabsichtigt doppelte Felder entstanden sind, und vereinheitlichen Sie die Schreibweise in der INI vorher.

Mehrfache Schlüssel und Arrays

Ein heikler Punkt ist der gleiche Schlüssel mehrfach innerhalb einer Sektion. Manche Dialekte verbieten das, andere erwarten es geradezu, etwa systemd mit mehreren ExecStartPre-Zeilen oder Konfigurationen mit mehreren erlaubten Hosts:

[firewall]
allow=10.0.0.1
allow=10.0.0.2
allow=10.0.0.3

Ein naiver Parser würde hier nur den letzten Wert behalten und die ersten beiden überschreiben. Das wäre stiller Datenverlust. Unser Konverter erkennt den mehrfachen Schlüssel und fasst die Werte zu einem JSON-Array zusammen, sodass aus den drei allow-Zeilen "allow": ["10.0.0.1", "10.0.0.2", "10.0.0.3"] wird. Manche INI-Dialekte signalisieren ein Array auch explizit mit der Schreibweise allow[]=..., die der Konverter ebenfalls versteht. Wie der Rückweg funktioniert, zeigt der Ratgeber Verschachtelte INI-Sektionen in JSON abbilden.

Verschachtelte Sektionen

Klassisches INI ist flach: eine Ebene von Sektionen, darunter Schlüssel-Wert-Paare. Tiefere Strukturen werden je nach Dialekt sehr unterschiedlich ausgedrückt. Verbreitet ist die Punktnotation, bei der eine Sektion wie [server.database] eine Verschachtelung andeutet. git config nutzt stattdessen Subsektionen in Anführungszeichen wie [user "alice"].

Unser Konverter kann Punkt-Sektionen optional in verschachtelte JSON-Objekte auflösen: Aus [server.database] wird server mit einem inneren Objekt database. Schalten Sie diese Option aus, bleibt der Sektionsname als ein einziges, flaches Feld "server.database" erhalten. Welche Variante Sie brauchen, hängt davon ab, ob das Zielprogramm flache Schlüssel mit Punkten oder echte Verschachtelung erwartet.

Warum Kommentare verloren gehen

INI-Dateien sind oft reich an Kommentaren, die erklären, was eine Einstellung bewirkt. Beim Umwandeln in JSON stoßen Sie hier an eine harte Grenze: Das JSON-Format kennt laut Spezifikation keine Kommentare. Es gibt keine offizielle Syntax, um einer JSON-Datei eine Notiz beizufügen.

Die Folge: Beim Weg von INI nach JSON werden alle Kommentarzeilen verworfen. Der eigentliche Inhalt, also Sektionen, Schlüssel und Werte, bleibt vollständig und gleichwertig erhalten. Aber die Erklärungen sind weg. Und beim Rückweg von JSON nach INI tauchen sie nicht wieder auf, denn das JSON enthält sie ja nicht mehr. Eine verlustfreie Rundreise INI nach JSON nach INI mit identischen Kommentaren und identischer Formatierung ist deshalb grundsätzlich nicht möglich. Das ist keine Schwäche dieses Tools, sondern eine Eigenschaft der Formate. Wenn Sie Kommentare bewahren müssen, halten Sie eine Kopie der originalen INI-Datei vor.

Checkliste vor dem Umwandeln

Damit das JSON-Ergebnis genau das wird, was Sie erwarten, gehen Sie diese Punkte durch:

1. Kommentarzeichen prüfen: Nutzt Ihre Datei ;, # oder Inline-Kommentare? Verschieben Sie Inline-Kommentare sicherheitshalber in eigene Zeilen.
2. Schreibweise vereinheitlichen: Vermeiden Sie dieselbe Sektion in unterschiedlicher Groß- und Kleinschreibung, sonst entstehen in JSON doppelte Felder.
3. Mehrfach-Schlüssel erkennen: Soll ein mehrfach vorkommender Schlüssel zu einem Array werden? Das macht der Konverter automatisch.
4. Sektions-Verschachtelung wählen: Entscheiden Sie, ob Punkt-Sektionen flach bleiben oder in verschachtelte Objekte aufgelöst werden sollen.
5. Datentypen festlegen: Sollen true, false und Zahlen typisiert werden oder als Strings bleiben? Details im Ratgeber INI-Datentypen in JSON.
6. Ergebnis kontrollieren: Sehen Sie sich das JSON in der Vorschau an, bevor Sie es weiterverwenden.

Mit diesen Vorbereitungen liefert der INI-zu-JSON-Konverter ein vorhersehbares Ergebnis. Alles läuft dabei zu 100 Prozent lokal in Ihrem Browser, ohne Upload und ohne Anmeldung, Ihre Datei verlässt Ihr Gerät also nicht.

Häufige Fragen