Cookies für Statistik und Werbung
Wir setzen Cookies für Statistik und Werbung ein, beides geht an Google. Wenn du ablehnst, ändert sich für dich sichtbar nichts.Zur Datenschutzseite
INI kannst du hier kostenlos und ohne Konto in XML umwandeln: Datei oben ablegen, und ein, zwei Sekunden später steht das Ergebnis zum Herunterladen bereit. Die Umwandlung läuft in deinem eigenen Browser, die Datei wird also nie hochgeladen — das klappt unter Windows, macOS und Linux ebenso wie auf iPhone und Android, und es funktioniert selbst dann noch, wenn du das Netz abschaltest.
Bis zu 100 Dateien auf einmal. Gemischte Formate sind kein Problem.
Sie werden nacheinander umgewandelt und kommen zusammen als ZIP zurück.
INI in XML
In vielen deutschen Kommunen und Landesbehörden laufen bis heute Fachverfahren, deren Konfiguration aus der Windows-Ära der Neunziger- und Nullerjahre stammt: eine INI-Datei mit Datenbankpfad, Benutzergruppen und Formularvorgaben. Im Zuge der Digitalisierung nach dem Onlinezugangsgesetz wird ein solches Verfahren häufig gegen eine modernere Fassung ausgetauscht oder an eine Schnittstelle angebunden, die XML erwartet — etwa weil ein XÖV-konformer Datenaustausch mit einer anderen Behörde ansteht oder eine .NET-Anwendung ihre Einstellungen in einer App.config erwartet. Die INI-Datei zieht dabei nicht um, sie wechselt die Form.
Wer das übernimmt, verschiebt keine Daten — die Konfiguration wandert in eine Welt, in der sie gegen ein Schema geprüft werden kann. Das braucht keine Interpretation der Werte, nur eine verlässliche Abbildung von Struktur auf Struktur, und genau das leistet diese Umwandlung.
Die Abbildung ist unmittelbar genug, um sie vorherzusagen. Ein Abschnittskopf wird zu einem Element, jeder Schlüssel darunter zu einem Kindelement, und der Wert wird zum Text dieses Elements. Eine INI-Datei mit [db] und darunter host und port kommt als db-Element mit einem host- und einem port-Kindelement heraus, mit zwei Leerzeichen Einrückung je Ebene.
Diese Vorhersagbarkeit ist der Grund, warum sich dafür ein Werkzeug lohnt statt eines eigenen Skripts. Es gibt kaum etwas zu interpretieren, weil eine INI-Datei einem Konverter fast nichts zur Auslegung überlässt: eine Gruppierungsebene, ein Schlüssel, ein Wert je Zeile. Alles Interessante passiert an den Rändern, und der Rest dieser Seite handelt von diesen Rändern.
XML verlangt genau ein äußerstes Element, eine INI-Datei kennt so etwas nicht. Der Konverter löst das anhand dessen, was er gelesen hat: Enthielt die Datei genau einen Abschnitt und sonst nichts, wird dieser Abschnitt zur Wurzel — eine Datei mit einem Abschnitt namens [einstellungen] erzeugt also ein Dokument, dessen Wurzelelement einstellungen heißt. Alles andere — zwei Abschnitte oder Schlüssel oberhalb des ersten Abschnittskopfs — wird in ein allgemeines Wurzelelement gepackt.
Das lohnt sich zu wissen, bevor gegen das Ergebnis ein Schema oder eine XPath-Abfrage geschrieben wird. Ein zweiter Abschnitt in der Quelle ändert das Wurzelelement der Ausgabe still von einstellungen zu root, und jede Pfadangabe, die gegen die erste Fassung geschrieben wurde, passt danach nicht mehr. Ist die Dokumentform für die Weiterverarbeitung wichtig, den Wurzelnamen selbst festlegen und stabil halten, statt ihn von der Abschnittszahl abhängen zu lassen.
INI hat kein Typsystem: Alles rechts vom Gleichheitszeichen ist Zeichenkette. Der Leser rät trotzdem — true und false werden zu Booleschen Werten, alles, was sich als Zahl lesen lässt, wird zur Zahl —, und der XML-Schreiber gibt das Ergebnis wieder als Text aus. Für die meisten Schlüssel bleibt der Umweg unsichtbar.
Für manche nicht. Ein Wert wie 007 wird als Zahl 7 gelesen und als 7 zurückgeschrieben. Eine Versionsangabe wie 1.0 wird zu 1. Eine hexadezimale Maske wie 0x1F kommt als 31 heraus, und ein Unix-Dateimodus wie 0755 kommt als 755 an — ein anderer Modus. Alles mit angehängter Einheit bleibt unangetastet, 128M bleibt 128M, und ebenso IP-Adressen wie 127.0.0.1 und Uhrzeiten wie 08:00, weil keines von beiden als einzelne Zahl gelesen wird.
XML ist bei Namen deutlich strenger als INI. Ein INI-Schlüssel darf Leerzeichen, Schrägstriche, Doppelpunkte und Klammern enthalten; ein Elementname darf im Wesentlichen nur Buchstaben, Ziffern, Unterstriche, Bindestriche und Punkte enthalten und nicht mit einer Ziffer beginnen. Der Schreiber ersetzt deshalb jedes unzulässige Zeichen durch einen Unterstrich und stellt einen Unterstrich voran, wenn der Name nicht mit einem Buchstaben oder Unterstrich beginnt.
Diese Ersetzung ist nicht umkehrbar, zwei Schlüssel, die sich nur in der Zeichensetzung unterscheiden, können also im selben Elementnamen zusammenfallen — „log level" und „log-level" nicht, weil der Bindestrich gültig ist, aber „log level" und „log/level" werden beide zu log_level. Gibt es solche Schlüssel in der eigenen INI-Datei, lohnt es, sie vor der Umwandlung umzubenennen, statt hinterher zu raten, welches Element aus welcher Zeile stammt.
Ein Abschnittskopf wie [database.pool] sieht aus, als sollte er sich verschachteln, und in TOML wäre das so. Hier nicht: Der Leser nimmt alles zwischen den Klammern als einen einzigen Abschnittsnamen, die Ausgabe enthält also ein einziges Element namens database.pool mit den Schlüsseln darin. Punkte sind in XML-Elementnamen zulässig, das Dokument ist also gültig — nur flacher, als vielleicht erwartet.
Will das Zielschema echte Verschachtelung, muss diese Struktur nachträglich erzeugt werden, nicht als Teil der Umwandlung. Der ehrliche Weg ist, erst umzuwandeln und das entstandene XML dann per XSLT oder von Hand umzuformen, denn ein Konverter, der aus Interpunktion auf Verschachtelung schließen wollte, würde bei jeder INI-Datei falschliegen, in der ein Punkt Teil eines Namens ist und kein Trennzeichen — und PHP-Konfigurationsdateien mit Schlüsseln wie date.timezone sind genau dieser Fall.
INI kennt keinen Standard, nur Gewohnheiten, und eine der Stellen, an denen sich Implementierungen unterscheiden, ist die Bedeutung eines wiederholten Abschnittskopfs. Manche führen die beiden Blöcke zusammen. Dieser Leser tut das nicht: Er legt bei jedem gesehenen Kopf einen neuen, leeren Abschnitt an, eine Datei mit zweimal [protokoll] behält also nur die Schlüssel aus dem zweiten Vorkommen und verliert den ersten Block vollständig, ohne Fehlermeldung.
Wiederholte Köpfe sind in von Hand geschriebenen Dateien selten und in zusammengesetzten Dateien häufig — eine Basiskonfiguration, an die ein Umgebungs-Overlay angehängt wurde, ein reales Muster beim Ausrollen von Konfigurationen über mehrere Umgebungen. Vor der Umwandlung die Quelle nach doppelten Köpfen durchsuchen, denn der Fehler ist lautlos, und das Ergebnis ist ein einwandfrei geformtes XML-Dokument, dem schlicht Einstellungen fehlen.
Beide Formate unterstützen Kommentare. INI kennzeichnet sie mit Semikolon oder Raute, XML mit einem spitzen Klammerblock, und diese Umwandlung überträgt keinen von beiden: Kommentarzeilen werden beim Lesen übersprungen und tauchen nie wieder auf. Beide Formate gelten hier als kommentarfähig, was den Verlust zu einer Eigenschaft der Verarbeitungskette macht, nicht zu einer Einschränkung des Zielformats.
Bei einer Konfigurationsdatei wiegt das schwerer, als es klingt. Die Zeile über einem Timeout, die erklärt, warum es wegen eines langsamen Berichts auf 90 Sekunden erhöht wurde, ist oft der einzige Beleg dieser Entscheidung, den es überhaupt gibt. Die kommentierte Originaldatei vor der Umwandlung in die Versionsverwaltung sichern und die Erklärungen anschließend von Hand an das XML anhängen — eine automatische Umwandlung dieser Art kann das für niemanden erledigen.
Der Grund für diesen Wechsel liegt fast nie in der Syntax. XML 1.0 ist seit 1998 eine W3C-Empfehlung, und darum herum steht die Maschinerie, die INI nie hatte: XSD-Schemata, die eine Konfiguration mit einem falsch geschriebenen Schlüssel schon vor dem Start der Anwendung zurückweisen, XPath, um einen einzelnen Wert aus einem großen Dokument zu ziehen, XSLT zum Umformen, digitale XML-Signaturen, um zu belegen, dass eine Konfigurationsdatei nicht verändert wurde — Eigenschaften, die für eine Ablage in einem Behördenumfeld oft den eigentlichen Ausschlag geben.
Nichts davon kommt mit der Umwandlung von selbst. Die Ausgabe ist ein wohlgeformtes Dokument ohne angehängtes Schema und ohne deklarierten Namensraum, und das Schema zu schreiben ist die eigentliche Arbeit — die Umwandlung liefert nur das Startdokument, gegen das geschrieben wird. Wird gar nicht validiert, signiert oder transformiert, kauft die Migration nur mehr Text ein und sonst nichts.
Liest dieselbe Anwendung die Datei, die sie geschrieben hat, und braucht nichts nachgelagert ein Schema, ist die Umwandlung ein Aufwand ohne Gegenwert. Eine INI-Datei kann jeder öffnen und bearbeiten, der mit einem Texteditor umgehen kann, und das ist eine echte betriebliche Eigenschaft, wenn die Person, die um zwei Uhr nachts eine Einstellung ändert, keine Entwicklerin ist.
Die Umwandlung ist auch das falsche Werkzeug, wenn eigentlich nur zwei oder drei Werte aus der Datei gebraucht werden statt der ganzen. Diese direkt auslesen. Dieser Konverter ist für den Fall gedacht, dass die INI-Datei die Konfiguration ist und die Konfiguration umzieht — nicht für das Herausziehen eines einzelnen Ausschnitts.
| INI | XML | |
|---|---|---|
| Vollständiger Name | INI-Konfiguration | Extensible Markup Language |
| Dateiendung | .ini, .cfg, .conf | .xml |
| Medientyp | text/plain | application/xml |
| Erstmals veröffentlicht | 1985 | 1998 |
| Herausgegeben von | — | W3C |
| Spezifikation | — | XML 1.0 |
| Lizenzlage | Offener Standard | Offener Standard |
| Heutiger Stand | Alt, wird überall noch gelesen | Aktuell |
| Öffnet im Browser | Kein Browser | Jeder Browser |
| Stattdessen erwogen | TOML, YAML | JSON, YAML |
Kommentare kommen mit. INI und XML kennen beide eine Kommentarsyntax, Notizen für die nächste Person gehen also nicht still verloren.
XML öffnet sich in jedem aktuellen Browser. INI unterstützen noch weniger Browser. Wenn die Datei auf eine Webseite oder in ein Formular soll, ist das meist der ganze Grund für die Umwandlung.
INI stammt aus 1985 und wird kaum noch verwendet. XML ist das, was aktuelle Software schreibt — bei der Umwandlung geht es also auch darum, lesbar zu bleiben.
Visual Studio Code liest sowohl INI als auch XML — du kannst das Ergebnis also gegen das Original prüfen, ohne ein zweites Programm zu brauchen.
Die beiden zielen auf verschiedene Arbeit: INI auf die Bearbeitung, XML auf den Austausch zwischen Programmen. Das lohnt sich vorher abzuwägen — der Grund, aus dem es das eine gibt, ist meist der Grund, aus dem das andere unpraktisch ist.
XML kommt von W3C und stammt aus 1998, festgehalten in XML 1.0. Visual Studio Code und oXygen XML Editor lesen das Format.
Nein. Diese Umwandlung läuft vollständig in deinem Browser, die Datei verlässt dein Gerät also nicht. Du kannst das selbst nachprüfen: Öffne den Netzwerk-Tab der Entwicklerwerkzeuge und wandle etwas um. Zu sehen sind die Seite selbst und die Statistik- und Werbeanfragen, mit denen dieser Dienst bezahlt wird — und keine einzige, die deine Datei trägt.
Ja. Kein Konto, kein Wasserzeichen und kein Tageskontingent, das sich verbraucht — es läuft auf deinem eigenen Rechner, du darfst also so oft wiederkommen, wie du willst. Dateien bis 100 MB verarbeitet der Browser, 100 auf einmal.
Nein. XML speichert denselben Inhalt, ohne etwas wegzuwerfen — das Ergebnis ist qualitativ mit dem Original identisch.
Für die Umwandlung selbst nicht — sie läuft in dem Browser, den du ohnehin offen hast. Zum Öffnen brauchst du danach das Programm, das auf deinem Gerät üblicherweise Extensible Markup Language anzeigt.