Was ist eine XML-Datei?

XML ist ein reines Textformat, das sich in jedem Editor öffnen lässt. Eingesetzt wird es für den Austausch zwischen Programmen.

Die Endung lautet .xml, der volle Name Extensible Markup Language. Beides sagt weniger aus als das, was die Datei halten kann — und davon handelt der Rest dieser Seite.

W3C hat es 1998 veröffentlicht. Die Spezifikation ist XML 1.0.

Einem Format, das so lange lesbar geblieben ist, kann man etwas anvertrauen, das man in zehn Jahren wiederhaben will.

Sie ist vollständig veröffentlicht, das Format lässt sich also aus dem Dokument umsetzen statt durch Nachsehen. Deshalb taucht es in so vielen Programmen auf, und deshalb gehen Dateien von vor zwanzig Jahren heute noch auf. Veröffentlicht heißt allerdings nicht lizenzfrei: Wo ein Format einen Codec einpackt, ist die Patentfrage eine eigene, die der Standard nicht mitbeantwortet.

XML speichert seinen Inhalt exakt. Erneutes Speichern ändert nichts, es lässt sich also beliebig oft öffnen, bearbeiten und wieder ablegen, ohne dass sich Schaden ansammelt — genau das macht es zu einem Arbeitsformat und nicht zu einem Ausgabeformat.

XML hat eine Kommentarsyntax — das ist der Unterschied zwischen einer Datei, die ein Mensch pflegt, und einer, die ein Programm schreibt. Beim Umwandeln in ein Format ohne Kommentare sind sie das Erste, was verschwindet, und gewarnt wird nicht.

Visual Studio Code und oXygen XML Editor lesen es, und die meisten Programme derselben Art ebenfalls.

Wenn eine Datei nicht aufgeht, liegt es selten am Format — häufiger daran, dass das Programm älter ist als das Format. Die Umwandlung in etwas Älteres ist der verlässliche Weg daran vorbei, und dafür gibt es den Rest dieser Website.

Jeder aktuelle Browser liest es.

Damit lässt es sich bedenkenlos auf eine Seite stellen oder an eine Nachricht hängen, ohne sich zu fragen, was die Gegenseite installiert hat.

XML ist zum Öffnen und Ändern gedacht. Behalte die Datei in diesem Format, solange die Arbeit läuft, und exportiere daraus, wann immer eine fertige Fassung gebraucht wird.

XML beschreibt aus sich heraus nichts. Es ist ein Regelwerk, um ein Dokument mit verschachtelten Elementen und Attributen auszuzeichnen, und die eigentliche Bedeutung kommt von dem Vokabular, das darauf aufbaut — RSS, SVG, SOAP, die XRechnung der öffentlichen Verwaltung, Sitemap-Dateien, Android-Layouts, das Innenleben jeder Office- und OpenDocument-Datei.

„Eine XML-Datei" sagt also ungefähr so viel über den Inhalt wie „eine Textdatei". Entscheidend ist, welches Vokabular sie verwendet, und das steht meist im Wurzelelement oder in einem Schema, auf das das Dokument verweist.

Wohlgeformt heißt: die Syntax stimmt. Genau ein Wurzelelement, jedes Tag geschlossen, Elemente sauber verschachtelt, Attribute in Anführungszeichen, `&` und `<` überall maskiert, wo sie als Text gemeint sind. Die beiden übrigen reservierten Zeichen sind enger gefasst, als oft gelehrt wird: `>` muss nur innerhalb von `]]>` maskiert werden, Anführungszeichen nur dort, wo sie das Attribut beenden würden, in dem sie stehen. Ein Parser verweigert alles andere — XML ist absichtlich streng, und anders als HTML gibt es keine Fehlertoleranz.

Gültig heißt zusätzlich: konform zu einem Schema — dieses Element darf jene Elemente enthalten, dieses Attribut ist Pflicht, dieser Wert muss ein Datum sein. Ein Dokument kann tadellos wohlgeformt und trotzdem völlig falsch für seinen Zweck sein, und ein validierender Parser deckt genau diesen Unterschied auf. Bei der elektronischen Rechnung ist diese Prüfung praktisch der Vertrag: Eine XRechnung, die dem CEN-Schema nicht entspricht, wird von öffentlichen Auftraggebern zurückgewiesen, unabhängig davon, wie korrekt der Rechnungsbetrag ist.

Namensräume erlauben es, zwei Vokabulare in einem Dokument zu kombinieren, ohne dass sich ihre Elementnamen in die Quere kommen — eine XHTML-Tabelle und die Tabelle eines Möbelkatalogs im selben Dokument. Ein Namensraum wird über eine URI identifiziert, die ein Name ist und keine Adresse: Von dort wird nichts abgerufen, und sie muss zu nichts auflösen.

Sie sind zugleich die häufigste Fehlerquelle beim XML-Parsen. Eine Abfrage, die ohne Rücksicht auf den Namensraum eines Elements geschrieben ist, findet still gar nichts, während das Dokument einem Menschen völlig in Ordnung erscheint. Behauptet ein Parser, ein Element existiere nicht, obwohl es klar sichtbar dasteht, ist der Namensraum die erste Stelle, an der man nachsieht.

Die erste Zeile einer sauberen XML-Datei erklärt Version und Zeichenkodierung. Anders als bei einer reinen Textdatei macht das die Kodierung zu einem Teil des Dokuments statt zu einer Vermutung — deshalb geht XML mit internationalem Text zuverlässiger um als CSV oder INI es je taten.

Zwei Folgen sind es wert, gemerkt zu werden. Eine Datei, die eine Kodierung angibt und in einer anderen gespeichert wird, ist auf eine Weise kaputt, die verwirrende Parserfehler statt sichtbar falscher Zeichen erzeugt. Und ein Byte-Order-Mark vor der Deklaration bringt manche Parser durcheinander — „UTF-8 ohne BOM" ist hier wie überall sonst die Einstellung, die man wählen sollte.

XML kennt einen Mechanismus für Abkürzungen — eine Entität —, die klassisch auch auf eine externe Ressource verweisen konnte. Ein Parser, der das auflöst, liest lokale Dateien oder stellt Netzwerkanfragen im Namen desjenigen, der das Dokument geliefert hat.

Das ist die XXE-Schwachstelle, und sie hat reale Datenpannen verursacht, indem sie über einen ganz gewöhnlich aussehenden Upload Serverdateien offenlegte. Ein verwandter Trick, der Billion-Laughs-Angriff, verschachtelt Entitätsdefinitionen so, dass eine winzige Datei auf Gigabyte anwächst und den Arbeitsspeicher erschöpft. Ob externe Entitäten standardmäßig aufgelöst werden, hängt von der jeweiligen Bibliothek ab, statt einheitlich geregelt zu sein — Javas eingebaute Parser und Pythons lxml lösen sie auf, sofern man es ihnen nicht ausdrücklich verbietet. Das ist also eine Einstellung, die man prüfen sollte, statt sie anzunehmen. Jede von außen kommende XML-Datei ist nicht vertrauenswürdiger Input.

XPath adressiert jeden Teil eines Dokuments mit einem kompakten Ausdruck, und es ist wirklich gut gemacht — eine einzige Zeile zieht jedes Preis-Element aus einem Produkt, dessen Kategorie-Attribut passt. XSLT wandelt ein XML-Dokument deklarativ in ein anderes um, oder in HTML oder Text. XSD definiert und erzwingt ein Schema. Alle drei sind Standards, alle drei sind ausgereift, und die JSON-Entsprechungen kamen später und sind längst nicht so einheitlich unterstützt.

Das ist gemeint, wenn XML als umständlich, aber leistungsfähig beschrieben wird. Die spitzen Klammern sind der Preis; Abfrage-, Transformations- und Validierungswerkzeuge sind das, wofür man ihn zahlt — und in den Branchen, die das brauchen, gibt es dafür bis heute keine wirklich gleichwertige Alternative.

Jeder Texteditor öffnet eine XML-Datei, und ein Editor mit XML-Unterstützung lohnt sich: Er klappt Abschnitte zusammen, prüft die Wohlgeformtheit beim Tippen und formatiert eine Datei sauber, die als eine einzige riesige Zeile ankam — wie maschinell erzeugtes XML meistens aussieht. Auch Browser stellen XML als aufklappbaren Baum dar, was der schnellste Weg ist, sich eine unbekannte Datei anzusehen.

Die Umwandlung nach JSON ist üblich und in eine Richtung verlustbehaftet: Attribute haben keine JSON-Entsprechung und bekommen einen erfundenen Schlüsselnamen, und gemischter Inhalt — Text mit Auszeichnung mittendrin — hat gar keine Entsprechung. Datenförmiges XML wandelt sauber um; dokumentförmiges XML übersteht den Hin- und Rückweg nicht. Eine direkte Umwandlung nach CSV bietet diese Seite nicht — der Weg führt über JSON als Zwischenschritt, und der lohnt sich ohnehin nur, wenn das Dokument im Kern eine flache Liste von Datensätzen in spitzen Klammern ist, statt echter Dokumentstruktur.