XML in INI umwandeln

In vielen mittelständischen Fertigungsbetrieben läuft neben der modernen Anlagensteuerung noch immer ein handgeschriebenes Werkzeug, das seit der Jahrtausendwende niemand mehr angefasst hat, weil es zuverlässig läuft und der Ersteller längst in Rente ist. Solche Programme lesen üblicherweise INI-Dateien — einfache Zeilen mit Gleichheitszeichen, ohne Bibliothek zu parsen.

Neue Anlagenkomponenten oder ein aktualisiertes Engineering-Tool liefern ihre Konfiguration dagegen als XML, weil das heute der Standardexport ist. Zwischen beiden Welten steht diese Seite: Sie holt die Werte aus der XML-Datei heraus und schreibt sie so, wie das alte Programm sie erwartet.

Die Umwandlung baut zu jedem Wert einen Pfad mit Punkten und trennt ihn an der ersten Stelle: Was davor steht, wird der Abschnittsname, der Rest der Schlüssel. Eine XML-Datei hat genau einen Wurzelknoten, also ist dieses erste Stück bei jedem Wert der Datei identisch — heraus kommt ein einziger Abschnitt mit einer langen Liste von Schlüsseln.

Das unterscheidet sich deutlich von einer YAML- oder JSON-Quelle, wo mehrere oberste Schlüssel auch mehrere Abschnitte ergeben. Wer eine INI-Datei mit mehreren sinnvollen Abschnitten braucht, wandelt am besten jeden Kindknoten der Wurzel einzeln um, statt der Umwandlung zu überlassen, welche Ebene einen eigenen Kopf verdient.

Nimmt man eine typische Struktur mit einer Wurzel namens Konfiguration und darunter einem Block Parameter mit mehreren Eintrag-Elementen, die jeweils ein Attribut name und eins wert tragen, entsteht ein Abschnitt Konfiguration mit Schlüsseln wie Parameter.Eintrag.0.@name gleich Vorschub und Parameter.Eintrag.0.@wert gleich 30, dann derselbe Aufbau mit dem Index 1 für den nächsten Eintrag.

Das ist getreu und nicht schön zu lesen. Die eigentlich interessante Information — Vorschub ist 30 — verteilt sich auf zwei Zeilen, die nur über den gemeinsamen Index zusammengehören. Steht am Ende ein kleines Steuerungsprogramm, das diese Werte lesen soll, ist es meist weniger Aufwand, die zwei Zeilen zu lesen und Vorschub=30 selbst zu schreiben, als dem Programm dieses Muster beizubringen.

Jedes Attribut wird zu einem Schlüsselteil mit vorangestelltem @, ein Element mit einem Attribut id ergibt also einen Schlüssel, der auf @id endet. Trägt ein Element sowohl Attribute als auch einen eigenen Textinhalt, landet dieser Text unter einem Segment namens #text, weil die Attribute den Elementnamen bereits belegt haben.

Keines von beidem ist eine INI-Konvention, und kein INI-Parser behandelt es besonders. Es dient nur der Eindeutigkeit — ein Attribut namens wert und ein Kindelement namens wert würden sonst denselben Schlüssel beanspruchen — und ist meist das Erste, was man entfernt, bevor die Datei an ein Programm geht. Umbenennen ist gefahrlos, INI kennt keine Struktur, die dabei brechen könnte.

Zwei oder mehr gleichnamige Geschwisterelemente werden beim Einlesen zu einer Liste und tragen dann Nummern: Eintrag.0, Eintrag.1, Eintrag.2, in der Reihenfolge des Dokuments. Diese Reihenfolge bleibt erhalten, was bei einer Liste von Parametern durchaus wichtig ist.

Ein einzelnes Vorkommen bekommt dagegen keine Nummer, weil der Parser nicht wissen kann, dass das Element sich wiederholen könnte — ein Eintrag-Element ist dann einfach ein Objekt. Dieselbe Konfiguration mit einem und mit zwei Einträgen erzeugt also unterschiedliche Schlüsselnamen, und ein Skript, das auf Parameter.Eintrag.0.@name prüft, findet an dem Tag nichts, an dem die Datei nur einen einzigen Eintrag hat.

Beginnt das Dokument mit einer Versions- und Kodierungsangabe, erzeugt das einen eigenen Abschnitt mit dem Kopf ?xml, der genau diese Werte enthält. Und trägt der Wurzelknoten eine Namensraum-Deklaration, wird daraus ein Schlüssel wie @xmlns im Hauptabschnitt. Beides beschreibt die XML-Datei selbst, nicht die eigentlichen Einstellungen.

Beides gehört gelöscht, bevor die Datei ins alte Programm geht. Ein Abschnittskopf mit Fragezeichen verstößt gegen keine Spezifikation — INI hat keine, die es verletzen könnte —, verwirrt aber trotzdem jeden, der die Datei später öffnet, und mitunter auch den Parser. Der Kodierungswert ist ebenfalls nicht zu gebrauchen: Ein Attribut mit dem Wert 1.0 wird als Zahl gelesen und kommt als 1 heraus, sagt in der Ausgabe also nicht einmal mehr das, was das Original sagte.

Ein Lizenztext, ein eingebettetes Skript oder eine mehrzeilige Beschreibung ist im XML ein einzelnes Element mit mehreren Textzeilen, und ein INI-Eintrag ist genau eine Zeile. Bis zum 9. August 2026 schrieb der Konverter diese Zeilenumbrüche unverändert heraus, sodass jede Zeile nach der ersten ohne eigenen Schlüssel dastand — beim Zurücklesen verworfen, falls sie kein Gleichheitszeichen enthielt, und schlimmer, falls doch: Eine Zeile, die wie eine Kopfzeile in eckigen Klammern aussah, öffnete einen Abschnitt, den kein XML-Dokument je hatte, und die nächste echte Einstellung landete darin.

Der Konverter setzt einen solchen Wert inzwischen in Anführungszeichen und schreibt jeden Zeilenumbruch als Backslash und n, sodass das Element eine Zeile bleibt und beim Rückweg vollständig ankommt. Wichtig bleibt trotzdem zu wissen, welche Elemente mehrzeiligen Text enthalten, denn das Programm auf der anderen Seite liest den Backslash womöglich wörtlich. Wo das eine Rolle spielt, gehört der Textblock in eine eigene Datei, auf die die INI nur verweist.

Mehr, als man erwarten würde. Werte behalten ihre Semikolons, Schrägstriche, Leerzeichen und eingebetteten Gleichheitszeichen, weil INI-Parser nur am ersten Gleichheitszeichen trennen — ein Pfad wie Netz=192.168.1.10;Port=502 kommt also als ein einziger Wert unversehrt zurück.

Die Reihenfolge der Elemente bleibt durchgängig erhalten, ebenso die relative Position von Attributen und Kindern. Numerisch aussehende Werte werden beim Einlesen interpretiert, und genau dort liegen die Ausnahmen: Ein Attribut mit dem Wert 1.0 wird zu 1, eine mit Nullen aufgefüllte Kennung wie 007 wird zu 7. Alles, was als reine Zeichenkette gedacht war, sollte man in der Ausgabe einmal kontrollieren.

Kommentare fallen weg, und gerade in einer technischen Konfigurationsdatei ist das oft der wertvollste Text überhaupt. Namensräume bedeuten nichts mehr, sobald ihre Präfixe nur noch Zeichen in einem Schlüsselnamen sind. Der Unterschied zwischen Attribut und Kindelement überlebt nur noch als @ in einer Zeichenkette. Und nichts in der INI-Datei lässt sich validieren, weil INI keine Schemasprache kennt.

Das ist die ehrliche Bilanz der Richtung: XML trägt Schemas, XPath, Transformationen und ist seit 1998 W3C-Empfehlung; INI stammt aus den achtziger Jahren und kennt nur Zeilen. Wer diesen Weg geht, verliert das alles unwiderruflich — die XML-Originaldatei gehört deshalb weiterhin in die Versionsverwaltung, unabhängig davon, was aus der INI-Datei wird.

Ein großer Teil der Anfragen an dieses Seitenpaar betrifft eine Handvoll Werte, nicht ein ganzes flach gemachtes Dokument. Ist das der Fall, lohnt es sich, die paar Werte aus der XML-Datei abzulesen und in der Form in die INI-Datei zu tippen, die das Zielprogramm erwartet. Das dauert Minuten, das Ergebnis ist lesbar, und keiner der oben genannten Sonderfälle taucht darin auf.

Die Umwandlung lohnt sich, wenn die Datei so groß ist, dass beim Abtippen die Fehler entstehen, oder wenn ein vollständiger Überblick über eine Herstellerkonfiguration gebraucht wird, bevor entschieden wird, welche Teile überhaupt wichtig sind. Beides sind gute Gründe. Eine ganze XML-Konfiguration en bloc umzuwandeln und das Ergebnis ungeprüft als neue Einstellungsdatei einzusetzen, ist keiner davon.