Zwei XML-Dokumente einfügen, formatieren und nebeneinander vergleichen. Pretty-Print, Validierung und namespace-bewusstes Highlighting sind eingebaut.
Ein kostenloses Tool im Browser zum Vergleichen zweier XML-Dokumente. Füge eine alte pom.xml links ein, die neue rechts, und die Änderungen leuchten Element für Element auf. Nichts verlässt deinen Rechner.
Der Diff selbst arbeitet auf Zeichenebene, und die Validierung läuft über den nativen DOMParser des Browsers. Der Format-Button in jedem Bereich richtet dein XML mit konsistenter Einrückung neu aus. Die Live-Validierung markiert fehlerhaftes Markup, nicht passende Tags und kaputte Entity-Referenzen, während du tippst.
Wer schon einmal in einem Code-Review einen 4.000-Zeilen-Spring-Application-Context geöffnet hat, um den einen Bean zu finden, dessen class-Attribut sich geändert hat, weiß: Das ist das Tool, das einen in Sekunden hinbringt. Für reinen Fließtext ist unser Text-Diff-Tool die richtige Wahl. Für strukturierte Daten mit Schlüssel/Wert-Paaren handhabt JSON-Diff Umsortierungen sauberer als XML.
Der Diff läuft auf Zeichenebene, danach verschiebt eine semantische Nachbearbeitung die Hervorhebungen, sodass sie auf Tag-Namen, Attributen und Textinhalt landen statt auf zufälliger Interpunktion. Einfügungen erscheinen grün im rechten Bereich, Löschungen rot im linken.
XML hat ein paar Eigenheiten, die die Spezifikation ausdrücklich nennt, und sie alle beißen, wenn man zwei Dateien als Text vergleicht. Die XML-1.0-Spezifikation sagt, dass die Reihenfolge der Attribute an einem Element nicht signifikant ist. Für einen Parser sind <img src="a.png" alt="x"/> und <img alt="x" src="a.png"/> dasselbe. Ein Text-Diff markiert das Vertauschen trotzdem. Ohne strukturellen Vergleich gibt es keine echte Lösung; die praktische Umgehung ist, beide Seiten mit demselben Tool zu formatieren, damit die Attributreihenfolge stabil bleibt.
Namespaces legen noch eine Schicht obendrauf. Zwei Dokumente, die dieselbe URI an unterschiedliche Präfixe binden, sind nach Namespaces in XML 1.0 äquivalent, aber ein Text-Diff malt jeden Wechsel von ns1: zu ns2: als Änderung an. Beide Seiten formatieren, das Präfix auf einer Seite angleichen, dann erneut diffen. Für eine Pipeline, die Namespaces und Attributreihenfolge vor dem Diff normalisiert, lohnen XSLT 3.0 oder ein Kanonisierungsschritt nach Canonical XML.
Zwei Textbereiche, ein Diff. Keine Anmeldung, kein Upload, kein Roundtrip zum Server.
Altes XML links einfügen, neues rechts. Oder auf einer Seite Hochladen klicken, um eine .xml-, .pom-, .config- oder .svg-Datei direkt zu laden. Der Beispiel-Button füllt beide Bereiche mit einer kleinen pom.xml, falls du das Tool zuerst in Aktion sehen willst.
In jedem Bereich auf Format klicken, um mit konsistenter Einrückung und Zeilenumbrüchen pretty-zu-printen. Das normalisiert Whitespace, sodass der Diff echte Inhaltsänderungen hervorhebt und nicht das Format-Rauschen einer Windows-CRLF-Datei gegen eine Unix-LF-Datei. Die Validierungs-Plakette wird grün, sobald DOMParser dein Dokument als wohlgeformt akzeptiert.
Löschungen erscheinen mit roter Hervorhebung links, Einfügungen mit grüner Hervorhebung rechts. Scrollst du auf einer Seite, folgt die andere. Die Änderungszähler in jedem Header sagen dir, wie viele unterschiedliche Bearbeitungen der Diff über Element-Namen, Attributwerte und Textinhalt hinweg gefunden hat.
Ein Dependabot-PR hebt fünfzehn Maven-Koordinaten auf einen Schlag an. Klebe die alte pom.xml gegen die neue, um die tatsächlichen Upgrades zu bestätigen: spring-boot-starter-web ging von 3.1.5 auf 3.2.1, jackson-databind von 2.15.3 auf 2.16.0, und eine neue micrometer-registry-prometheus-Abhängigkeit wurde hinzugefügt. Der Diff macht die Versionssprünge sichtbar, sodass du das Changelog vor dem Approve gegenchecken kannst.
Wenn ein Service nach einem Refactor zu kippen beginnt, ist die Ursache oft ein einzelner Bean, dessen class-Attribut oder Konstruktor-Argument in applicationContext.xml sich geändert hat. Klebe die funktionierende Revision gegen HEAD; der Diff bringt den Tausch class="com.acme.OldDataSource" gegen class="com.acme.HikariDataSource" sofort an die Oberfläche, und die umliegenden <property>-Tags sagen dir, welche Konfiguration mitgegangen ist.
Eine SOAP-Integration, die gestern lief, gibt heute einen Fault zurück. Beide Envelopes aus deinem Paket-Logger oder WireMock-Aufzeichnungen ziehen, in den Diff werfen, und das übeltätige Element springt heraus: ein <currencyCode>, der von USD zu einem fehlenden Element wurde, oder eine Namespace-Deklaration am soap:Envelope, die der Upstream-Service still geändert hat. Ohne Side-by-Side-Sicht ist das in 800 Zeilen XML aussichtslos.
Vor einem Release AndroidManifest.xml gegen den vorigen Tag diffen, um Berechtigungs-Wildwuchs zu erwischen. Ein neues <uses-permission android:name="android.permission.READ_CONTACTS"/>, das mit einem Drittanbieter-SDK-Update reingerutscht ist, ist genau das, was der Play Store im Review markiert. Der Diff bringt auch Änderungen an <intent-filter>-Elementen und android:exported-Flags ans Licht, beliebte Brennpunkte bei Sicherheitsreviews.
Ein Feed-Reader bricht, weil die Quelle von RSS 2.0 auf Atom 1.0 gewechselt hat oder ein Publisher einen neuen <media:thumbnail>-Namespace hinzugefügt hat. Speichere einen Snapshot des funktionierenden Feeds, diffe ihn gegen den aktuellen, und die strukturelle Änderung erscheint in Sekunden. Gleicher Workflow für OPML-Importe und Podcast-Feeds, wenn Channel-Metadaten zwischen Elementen umgezogen sind.
Eine .docx ist nur ein Zip mit XML drin. Beide Vertragsversionen entpacken, einen Diff auf word/document.xml laufen lassen, und du siehst die echten Textbearbeitungen, ohne dass die Word-Änderungsverfolgungs-Markierungen dazwischenfunken. Praktisch, wenn ein Paralegal eine "saubere" Kopie zurückschickt, die angeblich einem Redline entspricht; das XML zeigt dir, welche Absatz-Elemente sich verschoben haben und welche Run-Formatierung sich geändert hat.
Ein kurzer Spickzettel zu den Parsing-Grenzfällen, die dieses Tool am häufigsten an die Oberfläche bringt. Alles ist in den W3C-XML-Spezifikationen verankert.
| Topic | What this tool does |
|---|---|
| Attributreihenfolge | Nach XML-1.0-Spezifikation nicht signifikant. <a x="1" y="2"/> ist für einen Parser gleich <a y="2" x="1"/>. Ein Text-Diff markiert die Umsortierung; beide Seiten formatieren, um die Reihenfolge stabil zu halten. |
| Namespaces | URI-gebunden, präfix-aliasiert. Zwei Dokumente, die dieselbe URI an unterschiedliche Präfixe binden, sind äquivalent. Siehe Namespaces in XML 1.0. |
| CDATA-Abschnitte | Wörtlicher Text in <![CDATA[ ... ]]> eingeschlossen. Der Parser interpretiert weder Tags noch Entitäten darin. Die Sequenz ]]> kann nicht innerhalb eines CDATA-Blocks vorkommen. |
| Mixed Content | Elemente können Text, Kindelemente und Whitespace in beliebiger Reihenfolge enthalten. <p>Hallo <b>Welt</b>!</p> ist Mixed Content, und der Whitespace dort ist signifikant. |
| Kommentare | <!-- Kommentar -->. Dürfen intern keine -- enthalten. Werden von den meisten Prozessoren entfernt, in diesem Diff aber als Text erhalten. |
| Encoding und BOM | Deklariert über <?xml version="1.0" encoding="UTF-8"?>. Das UTF-8-BOM ist ein verstecktes erstes Zeichen; häufige Ursache für Ein-Zeichen-Phantom-Diffs in Zeile 1. |
| XML 1.0 vs. 1.1 | Fast alle nutzen XML 1.0. Version 1.1 ergänzt Unterstützung für zusätzliche Unicode-Steuerzeichen im Element-Inhalt; in der Praxis selten. |
| Entity-Referenzen | Fünf eingebaute: & < > ' ". Numerische Zeichenreferenzen wie é für akzentuierte Buchstaben sind ebenfalls gültig. Selbst-schließendes <br/> und explizites <br></br> sind äquivalent. |
Ja, beides tut das. Ein Text-Diff vergleicht Zeichen Zeile für Zeile, also tauchen Reformatierung, Attribut-Umsortierung oder Whitespace innerhalb von Elementen als Unterschiede auf, auch wenn das Dokument logisch identisch ist. Klicke zuerst in beiden Bereichen auf Format, dann fokussiert sich der Diff auf echte Inhaltsänderungen. Für Element-Bäume mit tief verschachtelten Kindern ist ein struktureller Vergleich über XSLT oder Canonical XML der nächste Schritt; dieses Tool deckt 95 % der praktischen XML-Reviews ohne diese Komplexität ab.
Nein, für einen XML-Parser nicht. Die XML-1.0-Spezifikation sagt, dass die Attributreihenfolge nicht signifikant ist, also stehen <img src="a.png" alt="x"/> und <img alt="x" src="a.png"/> für dasselbe Element. Ein Zeichen-Diff markiert die Umsortierung trotzdem, weil er den rohen Text sieht. Die Lösung ist, beide Seiten vor dem Diff mit demselben Tool zu formatieren, damit die Attributreihenfolge konsistent ist, oder Canonical-XML-Normalisierung anzuwenden, sofern du die Pipeline kontrollierst.
Namespaces sind URI-basiert, im Dokument bindest du sie aber an kurze Präfixe. Zwei Dateien, die http://maven.apache.org/POM/4.0.0 an unterschiedliche Präfixe binden, sind nach der Namespaces-in-XML-Spezifikation äquivalent, aber der Text-Diff markiert jeden Präfixwechsel als Änderung. Die praktische Lösung ist, beide Dateien zu formatieren und auf beiden Seiten passende Präfixe zu verwenden. Für automatisierte Pipelines normalisiert ein Canonical-XML-Durchlauf das weg.
Ja. CDATA-Abschnitte sind nur Textinhalt mit der Anweisung an den Parser, ihn nicht zu interpretieren, also wird <![CDATA[<b>raw</b>]]> als die wörtlichen Zeichen darin verglichen. Lange CDATA-Blöcke (Script-Tags, eingebettetes HTML, SQL) diffen sauber. Der einzige Haken: Innerhalb eines CDATA-Abschnitts darf ]]> nicht vorkommen. Enthalten deine Daten diese Sequenz, muss die Quelle sie auf zwei CDATA-Blöcke aufteilen, was der Diff so anzeigt, wie es geschrieben steht.
XSLT verwendest du, wenn du XML transformieren oder vor dem Vergleich normalisieren willst (Kinder sortieren, Kommentare entfernen, Namespaces kanonisieren). Diesen Diff nimmst du, wenn du sehen willst, was sich zwischen zwei konkreten Dateien geändert hat. Die zwei ergänzen sich: Ein XSLT-Vorlauf plus dieser Diff ist ein starker Workflow für lautes, maschinell erzeugtes XML. Für die meisten Code-Review-Fälle (pom.xml, AndroidManifest, Application-Context) reicht der Diff allein.
Ein bisschen. Die <?xml version="1.0" encoding="UTF-8"?>-Deklaration ist Teil des Dokumenttexts, also erscheint ein Tausch von UTF-8 gegen UTF-16 als einzeiliger Diff. Ein UTF-8-Byte-Order-Mark (BOM) ganz am Anfang ist ein einzelnes verstecktes Zeichen, das manche Editoren entfernen und andere behalten, eine häufige Ursache für Phantom-Diffs. Wenn zwei Dateien identisch aussehen, der Diff aber eine Änderung in Zeile 1 Zeichen 0 zeigt, BOM verdächtigen und mit bekannter Encoding-Einstellung neu speichern.
Dein XML verlässt deinen Browser nie. Parser, Formatter und Diff laufen alle lokal auf deinem Gerät. Keine Analyse deiner Eingabe, keine Logs, kein "hilfreicher" Cloud-Roundtrip. Parsing und Validierung verwenden den nativen DOMParser des Browsers, und die Spezifikation, der wir folgen, ist W3C XML 1.0. Hintergrundlektüre zum Format selbst gibt es bei Wikipedia.