Lim inn, formater og sammenlign to XML-dokumenter side ved side. Pretty-print, validering og namespace-bevisst utheving er innebygd.
Et gratis verktøy i nettleseren for å sammenligne to XML-dokumenter. Lim inn en gammel pom.xml til venstre, den nye til høyre, så lyser endringene opp element for element. Ingenting forlater maskinen din.
Selve diffen jobber på tegnnivå, og valideringen går gjennom nettleserens innebygde DOMParser. Format-knappen i hver rute formaterer XML-en på nytt med konsekvent innrykk. Live-validering markerer dårlig formet markup, ikke-matchende tagger og brutte entitetsreferanser mens du skriver.
Har du noen gang åpnet en Spring application context på 4000 linjer i en code review og prøvd å finne den ene bean-en hvis class-attributt endret seg, så er dette verktøyet som tar deg dit på sekunder. For ren prosa er tekst-diff-verktøyet vårt det riktige valget. For strukturerte data med nøkkel/verdi-par håndterer JSON diff omsortering av objekter renere enn det XML klarer.
Diffen kjører på tegnnivå, og en semantisk etterbehandlingsfase forskyver deretter uthevingene slik at de lander på taggnavn, attributter og tekstinnhold i stedet for tilfeldige tegn. Innsettinger vises i grønt i høyre rute, slettinger i rødt i venstre rute.
XML har et par særtrekk som spesifikasjonen uttrykkelig nevner, og de biter alle når du sammenligner to filer som tekst. XML 1.0-spesifikasjonen sier at attributtrekkefølgen på et element ikke er signifikant, så for en parser er <img src="a.png" alt="x"/> og <img alt="x" src="a.png"/> det samme. En tekst-diff markerer ombyttingen likevel. Det finnes ingen reell kur uten en strukturell sammenligning; den praktiske omveien er å formatere begge sider med samme verktøy slik at attributtrekkefølgen holder seg stabil.
Namespaces legger på enda et lag. To dokumenter som binder samme URI til ulike prefikser er likeverdige etter Namespaces in XML 1.0, men en tekst-diff maler hver ns1:-mot-ns2:-bytte som en endring. Formater begge sider, juster prefikset på den ene, og kjør diffen på nytt. For en pipeline som normaliserer namespaces og attributtrekkefølge før diffen, se på XSLT 3.0 eller et kanoniseringssteg etter Canonical XML.
To tekstruter, én diff. Ingen registrering, ingen opplasting, ingen tur til serveren.
Lim inn den gamle XML-en til venstre, den nye til høyre. Eller klikk Last opp på en av sidene for å laste en .xml-, .pom-, .config- eller .svg-fil direkte. Eksempel-knappen fyller begge ruter med et lite pom.xml-eksempel hvis du vil se verktøyet i drift først.
Klikk Format i hver rute for å pretty-print:e med konsekvent innrykk og linjeskift. Det normaliserer whitespace slik at diffen fremhever ekte innholdsendringer og ikke format-støy fra en Windows CRLF-fil mot en Unix LF-fil. Validerings-merket blir grønt når DOMParser godtar dokumentet ditt som well-formed.
Slettinger vises med rød utheving til venstre, innsettinger med grønn utheving til høyre. Scroll på den ene siden, så følger den andre med. Endringstellerne i hver overskrift forteller hvor mange forskjellige redigeringer diffen fant på tvers av elementnavn, attributtverdier og tekstinnhold.
En Dependabot-PR løfter femten Maven-koordinater på én gang. Lim inn den gamle pom.xml-en mot den nye for å bekrefte de faktiske oppgraderingene: spring-boot-starter-web gikk fra 3.1.5 til 3.2.1, jackson-databind fra 2.15.3 til 2.16.0, og en ny micrometer-registry-prometheus-avhengighet ble lagt til. Diffen gjør versjonsspranget tydelig, slik at du kan kryssjekke changeloggen før du godkjenner.
Når en tjeneste begynner å feile etter en refaktorering, er årsaken ofte én enkelt bean hvis class-attributt eller konstruktørargument er endret i applicationContext.xml. Lim inn den fungerende revisjonen mot HEAD; diffen får frem byttet av class="com.acme.OldDataSource" til class="com.acme.HikariDataSource" umiddelbart, og <property>-taggene rundt forteller hvilken konfigurasjon som fulgte med.
En SOAP-integrasjon som virket i går returnerer en Fault i dag. Hent begge envelopes fra pakke-loggeren din eller fra WireMock-opptak, slipp dem i diffen, og det skyldige elementet hopper frem: en <currencyCode> som gikk fra USD til et manglende element, eller en namespace-deklarasjon på soap:Envelope som upstream-tjenesten stille har endret. Uten side-by-side er det håpløst å finne dette i 800 linjer XML.
Før du sender en release, diff:e AndroidManifest.xml mot forrige tag for å fange tillatelses-skliing. En ny <uses-permission android:name="android.permission.READ_CONTACTS"/> som snek seg inn med en oppdatering av en tredjeparts-SDK er akkurat det Play Store flagger ved review. Diffen får også frem endringer i <intent-filter>-elementer og android:exported-flagg, vanlige fokuspunkter i sikkerhetsgjennomgang.
En feed-leser knekker fordi kilden byttet fra RSS 2.0 til Atom 1.0, eller en utgiver la til en ny <media:thumbnail>-namespace. Lagre et snapshot av den fungerende feeden, diff den mot live-feeden, og den strukturelle endringen kommer frem på sekunder. Samme flyt for OPML-import og podcast-feeder der metadata på channel-nivå har flyttet seg mellom elementer.
En .docx er bare en zip med XML inni. Pakk ut begge versjonene av en kontrakt, kjør en diff på word/document.xml, og du ser de faktiske tekstendringene uten at Words endringssporings-markup er i veien. Nyttig når en paralegal sender tilbake en "ren" kopi som angivelig stemmer med en redline; XML-en forteller hvilke avsnittselementer som har flyttet seg og hvilken formatering på run-nivå som er endret.
Et kort huskeark over parsing-grensetilfellene dette verktøyet oftest får frem. Alt forankret i W3Cs XML-spesifikasjoner.
| Topic | What this tool does |
|---|---|
| Attributtrekkefølge | Ikke signifikant ifølge XML 1.0-specen. For en parser er <a x="1" y="2"/> lik <a y="2" x="1"/>. En tekst-diff markerer byttet; formater begge sider for å holde rekkefølgen stabil. |
| Namespaces | URI-bundet, prefiks-aliasert. To dokumenter som binder samme URI til ulike prefikser er likeverdige. Se Namespaces in XML 1.0. |
| CDATA-seksjoner | Bokstavelig tekst pakket inn i <![CDATA[ ... ]]>. Parseren tolker verken tagger eller entiteter inni. Sekvensen ]]> kan ikke forekomme inne i en CDATA-blokk. |
| Mixed content | Elementer kan inneholde tekst, barneelementer og whitespace i hvilken som helst rekkefølge. <p>Hei <b>verden</b>!</p> er mixed content, og whitespace der er signifikant. |
| Kommentarer | <!-- kommentar -->. Kan ikke inneholde -- internt. Fjernes av de fleste prosessorer, men beholdes som tekst i denne diffen. |
| Encoding og BOM | Deklareres via <?xml version="1.0" encoding="UTF-8"?>. UTF-8 BOM er et skjult første tegn; vanlig årsak til ett-tegns fantom-diff:er på linje 1. |
| XML 1.0 vs 1.1 | Nesten alle bruker XML 1.0. Versjon 1.1 legger til støtte for flere Unicode-styretegn i element-innhold; sjelden i praksis. |
| Entitetsreferanser | Fem innebygde: & < > ' ". Numeriske tegnreferanser som é for bokstaver med aksent er også gyldige. Selvlukkende <br/> og eksplisitt <br></br> er likeverdige. |
Ja, begge gjør det. En tekst-diff sammenligner tegn linje for linje, så omformatering, omsortering av attributter eller whitespace inne i elementer dukker opp som forskjeller selv når dokumentet er logisk identisk. Klikk først Format i begge ruter, så fokuserer diffen på reelle innholdsendringer. For element-trær med dypt nestede barn er en strukturell sammenligning via XSLT eller Canonical XML neste skritt; dette verktøyet håndterer 95% av praktiske XML-gjennomganger uten den kompleksiteten.
Nei, ikke for en XML-parser. XML 1.0-specen sier at attributtrekkefølgen ikke er signifikant, så <img src="a.png" alt="x"/> og <img alt="x" src="a.png"/> representerer samme element. En tegn-diff markerer omsorteringen likevel fordi den ser den rå teksten. Boten er å formatere begge sider med samme verktøy så attributtrekkefølgen blir konsistent før diffen, eller å bruke Canonical XML-normalisering hvis du styrer pipelinen.
Namespaces er URI-baserte, men du binder dem til korte prefikser i dokumentet. To filer som binder http://maven.apache.org/POM/4.0.0 til ulike prefikser er likeverdige etter Namespaces in XML-specen, men tekst-diffen markerer hver prefiks-bytte som en endring. Den praktiske boten er å formatere begge filer og bruke matchende prefikser på begge sider. For automatiserte pipelines normaliserer en Canonical XML-passering dette bort.
Ja. CDATA-seksjoner er bare tekstinnhold med en instruks til parseren om ikke å tolke det, så <![CDATA[<b>raw</b>]]> sammenlignes som de bokstavelige tegnene inni. Lange CDATA-blokker (script-tagger, innebygd HTML, SQL) diff-es pent. Den eneste fellen er at du ikke kan ha ]]> inne i en CDATA-seksjon; hvis dataene dine inneholder den sekvensen, må kilden dele den i to CDATA-blokker, noe diffen viser slik det er skrevet.
Bruk XSLT når du vil transformere XML eller normalisere det før sammenligning (sortere barn, kaste kommentarer, kanonisere namespaces). Bruk denne diffen når du vil se hva som endret seg mellom to konkrete filer. De to utfyller hverandre: en XSLT-forkjøring pluss denne diffen er en sterk flyt for støyende maskingenerert XML. For de fleste code review-tilfeller (pom.xml, AndroidManifest, application context) holder diffen alene.
Litt. Deklarasjonen <?xml version="1.0" encoding="UTF-8"?> er en del av dokumentteksten, så å bytte UTF-8 mot UTF-16 dukker opp som en enlinjes diff. Et UTF-8 byte order mark (BOM) helt i starten er et enkelt skjult tegn som noen redigeringsprogrammer fjerner og andre beholder, en vanlig kilde til fantom-diff:er. Hvis to filer ser identiske ut, men diffen viser en endring på linje 1 tegn 0, mistenk BOM-en og lagre på nytt med en kjent encoding-innstilling.
XML-en din forlater aldri nettleseren. Parser, formatter og diff kjører alle på maskinen din, lokalt. Ingen analyse av input, ingen logger, ingen "hjelpsom" tur til skyen. Parsing og validering bruker nettleserens innebygde DOMParser, og specen vi følger er W3C XML 1.0. Bakgrunnsstoff om selve formatet finner du på Wikipedia.