Klistra in, formatera och jämför två XML-dokument sida vid sida. Pretty-print, validering och namespace-medveten markering inbyggda.
Ett gratis verktyg i webbläsaren för att jämföra två XML-dokument. Klistra in en gammal pom.xml till vänster, den nya till höger, så lyser ändringarna upp element för element. Inget lämnar din maskin.
Själva diff:en jobbar på teckennivå, och valideringen går genom webbläsarens inbyggda DOMParser. Format-knappen i varje panel återställer din XML med konsekvent indentering. Live-validering flaggar felformaterad markup, taggar som inte stänger och trasiga entitetsreferenser medan du skriver.
Har du någonsin öppnat en Spring application context på 4 000 rader i en code review och letat efter den enda bean vars class-attribut har ändrats, så är det här verktyget som tar dig dit på sekunder. För vanlig prosa är vårt text-diff-verktyg rätt val. För strukturerad data med nyckel/värde-par hanterar JSON diff omsortering av objekt renare än vad XML klarar.
Diff:en körs på teckennivå, och en semantisk efterbehandlingsfas flyttar sedan markeringarna så att de hamnar på taggnamn, attribut och textinnehåll i stället för slumpmässiga skiljetecken. Tillägg syns i grönt i högerpanelen, borttagningar i rött i vänsterpanelen.
XML har några egenheter som specifikationen pekar ut, och de bits alla när du jämför två filer som text. XML 1.0-specifikationen säger att attributordningen på ett element inte är signifikant, så <img src="a.png" alt="x"/> och <img alt="x" src="a.png"/> är samma sak för en parser. En text-diff flaggar ändå växlingen. Det finns ingen riktig lösning utan en strukturell jämförelse; den praktiska kringgåendet är att formatera båda sidor med samma verktyg så att attributordningen hålls stabil.
Namespaces lägger på ytterligare ett lager. Två dokument som binder samma URI till olika prefix är likvärdiga enligt Namespaces in XML 1.0, men en text-diff målar varje ns1:- mot ns2:-byte som en ändring. Formatera båda sidor, ställ in prefixet i en av dem, och kör diff:en igen. För en pipeline som normaliserar namespaces och attributordning före diff:en, titta på XSLT 3.0 eller ett kanoniseringssteg enligt Canonical XML.
Två textpaneler, en diff. Ingen registrering, ingen uppladdning, ingen serverrunda.
Klistra in den gamla XML:en till vänster, den nya till höger. Eller klicka på Ladda upp på endera sida för att läsa in en .xml-, .pom-, .config- eller .svg-fil direkt. Exempel-knappen fyller båda panelerna med ett litet pom.xml-exempel om du vill se verktyget i drift först.
Klicka Format i varje panel för att pretty-print:a med konsekvent indentering och radbrytningar. Det normaliserar whitespace så att diff:en lyfter fram riktiga innehållsändringar och inte format-bruset från en Windows-CRLF-fil mot en Unix-LF-fil. Validerings-märket blir grönt när DOMParser accepterar ditt dokument som well-formed.
Borttagningar visas med röd markering till vänster, tillägg med grön markering till höger. Skrolla i den ena sidan så följer den andra. Ändringsräknarna i varje rubrik säger hur många distinkta redigeringar diff:en hittade över elementnamn, attributvärden och textinnehåll.
En Dependabot-PR höjer femton Maven-koordinater på en gång. Klistra in den gamla pom.xml mot den nya för att bekräfta de faktiska uppgraderingarna: spring-boot-starter-web gick från 3.1.5 till 3.2.1, jackson-databind från 2.15.3 till 2.16.0, och ett nytt micrometer-registry-prometheus-beroende lades till. Diff:en gör versionssprången uppenbara så att du kan stämma av med changelogen innan du godkänner.
När en tjänst börjar fallera efter en refaktorering är orsaken ofta en enda bean vars class-attribut eller konstruktorargument ändrats i applicationContext.xml. Klistra in den fungerande revisionen mot HEAD; diff:en lyfter direkt fram bytet av class="com.acme.OldDataSource" mot class="com.acme.HikariDataSource", och <property>-taggarna runt om talar om vilken konfiguration som följde med.
En SOAP-integration som funkade igår returnerar en Fault idag. Fånga båda envelope:erna från din pakettloggare eller från WireMock-inspelningar, släpp dem i diff:en, och det skyldiga elementet sticker fram: en <currencyCode> som gick från USD till ett saknat element, eller en namespace-deklaration på soap:Envelope som upstream-tjänsten tyst ändrat. Utan side-by-side är det hopplöst att hitta detta i 800 rader XML.
Innan du släpper en release, diff:a AndroidManifest.xml mot föregående tagg för att fånga behörighets-glidning. En ny <uses-permission android:name="android.permission.READ_CONTACTS"/> som smugit sig in med en uppdatering av en tredjepartsfunktion är precis vad Play Store flaggar i granskningen. Diff:en lyfter också fram ändringar i <intent-filter>-element och android:exported-flaggor, vanliga fokusområden i säkerhetsgranskning.
En feed-läsare går sönder för att källan bytt från RSS 2.0 till Atom 1.0, eller en publicist har lagt till en ny <media:thumbnail>-namespace. Spara en snapshot av den fungerande feeden, diff:a den mot den live-feeden, och den strukturella ändringen syns på sekunder. Samma flöde för OPML-importer och podcast-feeds där metadata på channel-nivå flyttat sig mellan element.
En .docx är bara ett zip med XML inuti. Packa upp båda versionerna av ett kontrakt, kör diff på word/document.xml och du ser de verkliga textändringarna utan att Words ändringsspårnings-markup ligger i vägen. Användbart när en paralegal skickar tillbaka en "ren" kopia som påstås matcha en redline; XML:en talar om vilka stycke-element som flyttat sig och vilken formatering på run-nivå som ändrats.
Ett kort lathund över de parsing-gränsfall som det här verktyget oftast lyfter fram. Allt grundat i W3C:s XML-specifikationer.
| Topic | What this tool does |
|---|---|
| Attributordning | Inte signifikant enligt XML 1.0-specen. För en parser är <a x="1" y="2"/> lika med <a y="2" x="1"/>. En text-diff flaggar bytet; formatera båda sidor för att hålla ordningen stabil. |
| Namespaces | URI-bundna, prefix-aliaserade. Två dokument som binder samma URI till olika prefix är likvärdiga. Se Namespaces in XML 1.0. |
| CDATA-sektioner | Bokstavlig text inkapslad i <![CDATA[ ... ]]>. Parsern tolkar varken taggar eller entiteter inuti. Sekvensen ]]> kan inte förekomma inuti ett CDATA-block. |
| Mixed content | Element kan innehålla text, barnelement och whitespace i godtycklig ordning. <p>Hej <b>världen</b>!</p> är mixed content och whitespace där är signifikant. |
| Kommentarer | <!-- kommentar -->. Får inte innehålla -- internt. Tas bort av de flesta processorer men bevaras som text i den här diff:en. |
| Encoding och BOM | Deklareras via <?xml version="1.0" encoding="UTF-8"?>. UTF-8 BOM är ett dolt första tecken; vanlig orsak till spök-diff:ar på ett tecken på rad 1. |
| XML 1.0 vs 1.1 | Nästan alla använder XML 1.0. Version 1.1 lägger till stöd för ytterligare Unicode-styrtecken i element-innehåll; sällan i praktiken. |
| Entitetsreferenser | Fem inbyggda: & < > ' ". Numeriska teckenreferenser som é för bokstäver med accent är också giltiga. Självstängande <br/> och explicit <br></br> är likvärdiga. |
Ja, båda gör det. En text-diff jämför tecken rad för rad, så omformatering, omsortering av attribut eller whitespace inuti element dyker upp som skillnader även när dokumentet är logiskt identiskt. Klicka först på Format i båda panelerna så fokuserar diff:en på riktiga innehållsändringar. För element-träd med djupt nästlade barn är en strukturell jämförelse via XSLT eller Canonical XML nästa steg; det här verktyget täcker 95% av praktiska XML-granskningar utan den komplexiteten.
Nej, inte för en XML-parser. XML 1.0-specen säger att attributordningen inte är signifikant, så <img src="a.png" alt="x"/> och <img alt="x" src="a.png"/> representerar samma element. En tecken-diff flaggar ändå omsorteringen eftersom den ser den råa texten. Botemedlet är att formatera båda sidor med samma verktyg så att attributordningen blir konsekvent före diff:en, eller att tillämpa Canonical XML-normalisering om du styr pipelinen.
Namespaces är URI-baserade, men du binder dem till korta prefix i dokumentet. Två filer som binder http://maven.apache.org/POM/4.0.0 till olika prefix är likvärdiga enligt Namespaces in XML-specen, men text-diff:en flaggar varje prefix-byte som en ändring. Det praktiska botemedlet är att formatera båda filerna och använda matchande prefix på båda sidor. För automatiserade pipelines normaliserar en Canonical XML-passage bort detta.
Ja. CDATA-sektioner är bara textinnehåll med en instruktion till parsern att inte tolka det, så <![CDATA[<b>raw</b>]]> jämförs som de bokstavliga tecknen inuti. Långa CDATA-block (script-taggar, inbäddad HTML, SQL) diff:as snyggt. Den enda haken är att du inte kan ha ]]> inuti en CDATA-sektion; om dina data innehåller den sekvensen måste källan dela upp den i två CDATA-block, vilket diff:en visar precis som det är skrivet.
Använd XSLT när du vill transformera XML eller normalisera den före jämförelsen (sortera barn, släng kommentarer, kanonisera namespaces). Använd den här diff:en när du vill se vad som ändrats mellan två specifika filer. De två kompletterar varandra: en XSLT-förpassage plus den här diff:en är ett starkt flöde för stökig maskingenererad XML. För de flesta code review-fall (pom.xml, AndroidManifest, application context) räcker diff:en själv.
Lite. Deklarationen <?xml version="1.0" encoding="UTF-8"?> är en del av dokumenttexten, så att byta UTF-8 mot UTF-16 dyker upp som en enradig diff. Ett UTF-8 byte order mark (BOM) längst i början är ett enskilt dolt tecken som vissa editorer plockar bort och andra behåller, en vanlig orsak till spök-diff:ar. Om två filer ser identiska ut men diff:en visar en ändring på rad 1 tecken 0, misstänk BOM:en och spara om med en känd encoding-inställning.
Din XML lämnar aldrig din webbläsare. Parser, formatter och diff körs allesammans på din maskin, lokalt. Ingen analys av din indata, inga loggar, inget "hjälpsamt" molnvarv. Parsing och validering använder webbläsarens inbyggda DOMParser, och specen vi följer är W3C XML 1.0. Bakgrundsläsning om själva formatet finns på Wikipedia.