Zwei XML-Dateien vergleichen und Änderungen sehen

Der schnellste Weg, zwei XML-Dateien zu vergleichen, besteht darin, beide in ein nebeneinander angeordnetes Diff-Tool einzufügen, sie gleich zu formatieren und die hervorgehobenen Zeilen zu lesen. Das Vergleichen ist der einfache Teil. Das Rauschen verwirrt die Leute: umgeordnete Attribute, Leerzeichen zwischen Tags und Namespace-Präfixe können dazu führen, dass zwei Dateien, die dasselbe bedeuten, aussehen, als hätten sie nichts gemeinsam.

Dieser Leitfaden erklärt, wie man einen sauberen, zuverlässigen XML-Diff erhält. Wir schauen uns an, warum zwei äquivalente Dokumente auf dem Papier auseinander driften, welche Methoden es wert sind zu kennen, und ein ausgearbeitetes Beispiel zum Nachvollziehen. Wer einfach nur das Tool möchte, kann auf unserer XML-Vergleichsseite all das im Browser erledigen.

Warum XML-Dateien trügerisch schwer zu vergleichen sind

XML hat eine strenge Grammatik (siehe die XML-Spezifikation des W3C), gibt Autoren aber viel Freiheit bei der Textformatierung. Zwei Dokumente können exakt dieselben Daten beschreiben und trotzdem Byte für Byte unterschiedlich sein. Ein einfacher Textvergleich versteht nichts davon und markiert daher alles.

Hier ist das Wichtigste, das man sich merken sollte: In XML ist die Reihenfolge der Attribute eines Elements nicht signifikant. Das XML Information Set behandelt Attribute als ungeordnete Menge. Also tragen <user id="7" role="admin"/> und <user role="admin" id="7"/> dieselbe Information, auch wenn ein Zeilendiff sie rot und grün anzeigt. Die Reihenfolge der Elemente hingegen ist meist wichtig.

Sieht wie eine Änderung aus, ist es meist nicht

Was man im Diff sieht	Ist es eine echte Änderung?	Was zu tun ist
Attribute in anderer Reihenfolge	Nein, die Attributreihenfolge ist nicht signifikant	Beide Seiten kanonisieren
2-Leerzeichen vs. 4-Leerzeichen-Einrückung	Nein	Beide Seiten gleich formatieren
Leerzeichen zwischen Elementen	Meist nicht	Formatieren oder unbedeutende Leerzeichen entfernen
<br/> vs. <br></br>	Nein, dasselbe leere Element	Beide Seiten kanonisieren
Ein anderes Namespace-Präfix für denselben URI	Nein, Präfixe sind beliebige Bezeichner	Nach Namespace-URI vergleichen, nicht nach Präfix
Kindelemente in anderer Reihenfolge	Meist ja, die Elementreihenfolge zählt	Untersuchen, das ist wahrscheinlich echt

Die letzte Zeile ist die, auf die man achten muss. Die Attributreihenfolge ist frei, aber die Reihenfolge der Kindelemente ist in den meisten Schemata Teil des Dokuments. Wer das Detail dazu nachlesen möchte, wie ein Parser all das sieht, findet bei MDN eine solide Referenz zum Parsen von XML mit DOMParser.

Vier Methoden zum Vergleichen von XML und wann man zu welcher greift

Es gibt keine einzige beste Methode. Es hängt davon ab, wo die Dateien liegen und was man herausfinden möchte. So schneiden die gängigen Optionen ab.

Methode	Am besten für	Aufwand	Versteht XML?
Manuell durchlesen	Winzige Dateien, ein oder zwei Elemente	Gering	Nein, man ist der Parser
Online-Diff-Tool	Schnelle Prüfungen, Einfügen von überall	Gering	Mit Formatierung ja
Befehlszeile (xmllint)	Dateien auf der Festplatte, Scripting, kanonische Form	Mittel	Ja, mit --c14n
IDE oder git diff	Dateien bereits in einem Repository	Gering bei Commits	Standardmäßig zeilenbasiert

Für die meisten Menschen gewinnt ein Browser-Tool an Geschwindigkeit: nichts zu installieren, und man kann einen Ausschnitt direkt aus einer Konfigurationsdatei oder einer SOAP-Antwort einfügen. Der Haken ist Formatierungsrauschen, das wir als nächstes behandeln. Wer viel im Terminal arbeitet, sollte xmllint von libxml2 kennen.

Der schnellste saubere Vergleich, Schritt für Schritt

Das ist die Vorgehensweise, die ich verwende, wenn mir jemand zwei Konfigurationsdateien gibt und fragt: "Was ist anders?" Es dauert etwa fünfzehn Sekunden.

1. Das XML-Vergleichstool öffnen.
2. Das Original links einfügen, die neue Version rechts.
3. Auf beiden Seiten auf Formatieren klicken, damit sie die gleiche Einrückung verwenden.
4. Nach echten Unterschieden suchen. Grün ist hinzugefügt, rot ist entfernt, und ein geänderter Wert erscheint als eines von beidem.
5. Die Zeilen ignorieren, die nur Attribut-Umsortierung oder Leerzeichen sind.

Schritt drei ist der größte Teil des Tricks. Sobald beide Dokumente dieselbe Einrückung verwenden, bleibt nur noch hervorgehoben, was sich tatsächlich geändert hat. Unser Diff-Engine basiert auf Googles diff-match-patch, das zuerst zeilenweise vergleicht und so auch bei langen Dateien schnell bleibt.

Ein ausgearbeitetes Beispiel

Angenommen, man prüft eine Änderung an einer Service-Konfiguration. Hier ist der Vorher-Stand:

<user id="7" role="editor">
  <name>Ada Lovelace</name>
  <active>true</active>
  <seats>3</seats>
</user>

Und hier ist der Nachher-Stand, wie ein Teammitglied ihn übergeben hat:

<user role="admin" id="7">
  <name>Ada Lovelace</name>
  <active>true</active>
  <seats>5</seats>
  <team>platform</team>
</user>

Wirft man diese in einen rohen Zeilendiff, sieht die allererste Zeile geändert aus, weil id und role die Plätze getauscht haben. Formatiert man beide und vergleicht nach Bedeutung, ist die eigentliche Geschichte kurz:

Was sich tatsächlich geändert hat

Knoten	Vorher	Nachher	Änderung
@role	editor	admin	Geändert
seats	3	5	Geändert
team	—	platform	Hinzugefügt
@id	7	7	Keine Änderung (nur verschoben)
name	Ada Lovelace	Ada Lovelace	Keine Änderung

Drei echte Bearbeitungen: eine Rollenerhöhung, eine Sitzanzahl und ein neues Team-Element. Der Attributtausch war Rauschen. Diese Beförderung von editor zu admin ist genau die Art von Sache, die man im Review erkennen möchte, und sie ist leicht zu übersehen, wenn sie unter einer Zeile vergraben ist, die der Diff fälschlicherweise markiert hat.

Kanonisches XML: der richtige Weg, Rauschen zu ignorieren

Das Formatieren beider Seiten regelt die Einrückung, aber es gibt einen Standard, der genau für dieses Problem gebaut wurde. Kanonisches XML, vom W3C in Canonical XML 1.1 definiert, schreibt ein Dokument in eine einzige normalisierte Form um: Attribute sortiert, leere Elemente expandiert, Leerzeichen in Tags normalisiert und Standardattribute explizit gemacht. Zwei äquivalente Dokumente erzeugen identische kanonische Ausgabe. Es ist das XML-Äquivalent zum Sortieren von JSON-Schlüsseln.

xmllint --c14n old.xml > old.c14n.xml
xmllint --c14n new.xml > new.c14n.xml
diff old.c14n.xml new.c14n.xml

Jetzt meldet diff nur noch Inhalt, der sich wirklich geändert hat, weil beide Dateien auf dieselbe Weise normalisiert wurden. Wenn man nur eine lesbare Einrückung statt der strengen kanonischen Form möchte, formatiert xmllint --format file.xml sie, was das Terminal-Äquivalent zum Klick auf Formatieren im Browser ist.

Namespaces: der Teil, der alle verwirrt

XML-Namespaces erlauben zwei Dokumenten, dasselbe Vokabular mit unterschiedlichen Präfix-Bezeichnern zu verwenden. <ns1:user> gebunden an einen URI und <u:user> gebunden an denselben URI sind dasselbe Element; das Präfix ist nur ein lokaler Spitzname. Ein Textdiff sieht ns1 gegen u und markiert eine Änderung, die keine ist. Die Lösung ist, nach dem Namespace-URI statt nach dem Präfix zu vergleichen, was genau das ist, was die Kanonisierung tut. Die Spezifikation Namespaces in XML ist die Referenz, falls man eine Diskussion darüber beilegen muss.

Häufige Fallstricke, auf die man achten sollte

Fallstrick	Warum er zuschlägt	Lösung
Zeichenkodierung	Eine UTF-8- und eine UTF-16-Datei können denselben Text enthalten, aber Byte für Byte abweichen	Kodierung normalisieren; die XML-Deklaration gibt sie an
Entity-Referenzen	& und ein literales & können beide für dasselbe Zeichen auftreten	Kanonisieren, was Entities konsistent auflöst
CDATA vs. maskierter Text	<![CDATA[a<b]]> und a&lt;b sind derselbe Textinhalt	Den geparsten Wert vergleichen, nicht die rohen Bytes
Signifikante Leerzeichen	Innerhalb von xml:space="preserve" zählen Leerzeichen und dürfen nicht entfernt werden	Nicht blind kürzen; xml:space respektieren
Selbstschließende Tags	<x/> und <x></x> sind identisch	Kanonisieren, damit beide gleich dargestellt werden

Textdiff vs. struktureller Diff

Alles oben Genannte ist ein Text-Diff: schnell, visuell und perfekt für einen Menschen, der eine Änderung liest. Ein struktureller Diff geht weiter und beschreibt die Änderung im Sinne des XML-Baums: dieses Attribut hat sich geändert, jenes Kindelement wurde an diesem Pfad eingefügt. Man möchte einen strukturellen Diff, wenn ein Programm die Änderung anwenden muss oder wenn die Elementreihenfolge wirklich keine Rolle spielt und man sie ignorieren möchte. Für den täglichen Review reicht ein Textdiff zweier formatierter Dokumente völlig aus.

Verwandte Tools

XML ist selten das einzige Format, mit dem man zu tun hat. Wenn man API-Payloads vergleicht, wendet JSON-Vergleich dieselbe Idee auf JSON an. Ausgezeichnete Seiten lassen sich leichter auf der HTML-Vergleichsseite lesen, und Umgebungseinstellungen passen gut auf das Config-Vergleichstool.