Indsæt, formatér og sammenlign to XML-dokumenter side om side. Pretty-print, validering og namespace-bevidst fremhævelse er indbygget.
Et gratis værktøj i browseren til at sammenligne to XML-dokumenter. Indsæt en gammel pom.xml til venstre, den nye til højre, og ændringerne lyser op element for element. Intet forlader din maskine.
Selve diff'en arbejder på tegnniveau, og valideringen går gennem browserens indbyggede DOMParser. Format-knappen i hver rude omformaterer din XML med konsekvent indrykning. Live-validering markerer dårligt formet markup, ikke-matchede tags og brudte entitetsreferencer, mens du skriver.
Har du nogensinde åbnet en Spring application context på 4.000 linjer i et code review og forsøgt at finde den ene bean, hvis class-attribut ændrede sig, så er det her værktøjet, der bringer dig derhen på sekunder. Til ren prosa er vores tekst-diff-værktøj det rigtige valg. Til strukturerede data med nøgle/værdi-par håndterer JSON diff omsortering af objekter renere, end XML formår.
Diff'en kører på tegnniveau, og en semantisk efterbehandlingsfase forskyder derefter fremhævningerne, så de lander på tagnavne, attributter og tekstindhold i stedet for tilfældig tegnsætning. Indsættelser vises grønt i højre rude, sletninger rødt i venstre rude.
XML har et par sære træk, som specifikationen udtrykkeligt nævner, og de bider alle, når man sammenligner to filer som tekst. XML 1.0-specifikationen siger, at attributrækkefø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 ombytningen alligevel. Der er ingen reel kur uden en strukturel sammenligning; den praktiske omvej er at formatere begge sider med det samme værktøj, så attributrækkefølgen forbliver stabil.
Namespaces lægger endnu et lag på. To dokumenter, der binder den samme URI til forskellige præfikser, er ækvivalente i henhold til Namespaces in XML 1.0, men en tekst-diff maler hver ns1:-mod-ns2:-bytning som en ændring. Formatér begge sider, juster præfikset i den ene af dem, og kør diff igen. For en pipeline, der normaliserer namespaces og attributrækkefølge før diff'en, kig på XSLT 3.0 eller et kanoniseringstrin efter Canonical XML.
To tekstruder, én diff. Ingen registrering, ingen upload, ingen tur til serveren.
Indsæt den gamle XML til venstre, den nye til højre. Eller klik på Upload i en af siderne for at indlæse en .xml-, .pom-, .config- eller .svg-fil direkte. Eksempel-knappen fylder begge ruder med et lille pom.xml-eksempel, hvis du vil se værktøjet i drift først.
Klik på Format i hver rude for at pretty-print:e med konsekvent indrykning og linjebrud. Det normaliserer whitespace, så diff'en fremhæver ægte indholdsændringer og ikke format-støj fra en Windows CRLF-fil mod en Unix LF-fil. Validerings-mærket bliver grønt, når DOMParser accepterer dit dokument som well-formed.
Sletninger vises med rød fremhævning til venstre, indsættelser med grøn fremhævning til højre. Scroll i den ene side, så følger den anden med. Ændringstællerne i hver overskrift fortæller, hvor mange forskellige redigeringer diff'en fandt på tværs af elementnavne, attributværdier og tekstindhold.
En Dependabot-PR skubber femten Maven-koordinater op på én gang. Indsæt den gamle pom.xml mod den nye for at bekræfte de faktiske opgraderinger: spring-boot-starter-web gik fra 3.1.5 til 3.2.1, jackson-databind fra 2.15.3 til 2.16.0, og en ny micrometer-registry-prometheus-afhængighed blev tilføjet. Diff'en gør versionsspringene tydelige, så du kan krydstjekke changeloggen, før du godkender.
Når en service begynder at fejle efter en refaktorering, er årsagen ofte én enkelt bean, hvis class-attribut eller konstruktørargument ændrede sig i applicationContext.xml. Indsæt den fungerende revision mod HEAD; diff'en bringer ombytningen af class="com.acme.OldDataSource" til class="com.acme.HikariDataSource" straks frem, og de omkringliggende <property>-tags fortæller, hvilken konfiguration der fulgte med.
En SOAP-integration, der virkede i går, returnerer en Fault i dag. Hent begge envelopes fra din pakke-logger eller WireMock-optagelser, smid dem i diff'en, og det skyldige element springer frem: en <currencyCode>, der gik fra USD til et manglende element, eller en namespace-deklaration på soap:Envelope, som upstream-tjenesten stille har ændret. Uden side-by-side er det håbløst at finde det i 800 linjer XML.
Inden du sender en release ud, så diff'er AndroidManifest.xml mod det forrige tag for at fange tilladelses-svind. En ny <uses-permission android:name="android.permission.READ_CONTACTS"/>, der listede sig ind med en opdatering af et tredjeparts-SDK, er præcis den slags Play Store flagger ved review. Diff'en bringer også ændringer i <intent-filter>-elementer og android:exported-flag frem, almindelige fokusområder ved sikkerhedsgennemgang.
En feed-læser går i stykker, fordi kilden skiftede fra RSS 2.0 til Atom 1.0, eller en udgiver tilføjede et nyt <media:thumbnail>-namespace. Gem et snapshot af det fungerende feed, diff' det mod det live-feedet, og den strukturelle ændring viser sig på sekunder. Samme flow til OPML-imports og podcast-feeds, hvor metadata på channel-niveau er flyttet mellem elementer.
En .docx er bare et zip med XML inde i. Pak begge versioner af en kontrakt ud, kør en diff på word/document.xml, og du ser de faktiske tekstredigeringer, uden at Words ændringssporings-markup er i vejen. Brugbart, når en paralegal sender en "ren" kopi tilbage, der angiveligt matcher en redline; XML'en fortæller, hvilke afsnitselementer der har flyttet sig, og hvilken formatering på run-niveau der har ændret sig.
Et kort huskeark over de parsing-grænsetilfælde, dette værktøj oftest får frem. Alt forankret i W3C's XML-specifikationer.
| Topic | What this tool does |
|---|---|
| Attributrækkefølge | Ikke signifikant ifølge XML 1.0-specen. For en parser er <a x="1" y="2"/> lig <a y="2" x="1"/>. En tekst-diff markerer ombytningen; formatér begge sider for at holde rækkefølgen stabil. |
| Namespaces | URI-bundne, præfiks-aliaserede. To dokumenter, der binder den samme URI til forskellige præfikser, er ækvivalente. Se Namespaces in XML 1.0. |
| CDATA-sektioner | Bogstavelig tekst pakket ind i <![CDATA[ ... ]]>. Parseren fortolker hverken tags eller entiteter indeni. Sekvensen ]]> kan ikke optræde inde i en CDATA-blok. |
| Mixed content | Elementer kan indeholde tekst, børneelementer og whitespace i en hvilken som helst rækkefølge. <p>Hej <b>verden</b>!</p> er mixed content, og whitespace der er signifikant. |
| Kommentarer | <!-- kommentar -->. Må ikke indeholde -- internt. Fjernes af de fleste processorer, men bevares som tekst i denne diff. |
| Encoding og BOM | Deklareres via <?xml version="1.0" encoding="UTF-8"?>. UTF-8 BOM er et skjult første tegn; almindelig årsag til ét-tegns spøgelses-diffs på linje 1. |
| XML 1.0 vs 1.1 | Næsten alle bruger XML 1.0. Version 1.1 tilføjer understøttelse af yderligere Unicode-styretegn i element-indhold; sjældent set i praksis. |
| Entitetsreferencer | Fem indbyggede: & < > ' ". Numeriske tegnreferencer som é for bogstaver med accent er også gyldige. Selvlukkende <br/> og eksplicit <br></br> er ækvivalente. |
Ja, det gør de begge. En tekst-diff sammenligner tegn linje for linje, så omformatering, omsortering af attributter eller whitespace inde i elementer dukker op som forskelle, selv når dokumentet er logisk identisk. Klik først på Format i begge ruder, så fokuserer diff'en på reelle indholdsændringer. For element-træer med dybt nestede børn er en strukturel sammenligning via XSLT eller Canonical XML det næste trin; det her værktøj klarer 95% af de praktiske XML-gennemgange uden den kompleksitet.
Nej, ikke for en XML-parser. XML 1.0-specen siger, at attributrækkefølgen ikke er signifikant, så <img src="a.png" alt="x"/> og <img alt="x" src="a.png"/> repræsenterer det samme element. En tegn-diff markerer alligevel omsorteringen, fordi den ser den rå tekst. Botemidlet er at formatere begge sider med det samme værktøj, så attributrækkefølgen er konsekvent før diff'en, eller at anvende Canonical XML-normalisering, hvis du styrer pipelinen.
Namespaces er URI-baserede, men du binder dem til korte præfikser i dokumentet. To filer, der binder http://maven.apache.org/POM/4.0.0 til forskellige præfikser, er ækvivalente ifølge Namespaces in XML-specen, men tekst-diff'en markerer hver præfiks-ombytning som en ændring. Det praktiske botemiddel er at formatere begge filer og bruge matchende præfikser på begge sider. Til automatiserede pipelines normaliserer en Canonical XML-passage dette væk.
Ja. CDATA-sektioner er bare tekstindhold med en instruktion til parseren om ikke at fortolke det, så <![CDATA[<b>raw</b>]]> sammenlignes som de bogstavelige tegn indeni. Lange CDATA-blokke (script-tags, indlejret HTML, SQL) diff'es pænt. Den eneste fælde er, at du ikke kan have ]]> inde i en CDATA-sektion; hvis dine data indeholder den sekvens, skal kilden dele den i to CDATA-blokke, hvilket diff'en viser, som det er skrevet.
Brug XSLT, når du vil transformere XML eller normalisere det før sammenligning (sortere børn, smide kommentarer ud, kanonisere namespaces). Brug denne diff, når du vil se, hvad der ændrede sig mellem to specifikke filer. De to supplerer hinanden: en XSLT-forpassage plus denne diff er et stærkt flow til støjende maskingenereret XML. I de fleste code review-tilfælde (pom.xml, AndroidManifest, application context) er diff'en alene nok.
Lidt. Deklarationen <?xml version="1.0" encoding="UTF-8"?> er en del af dokumentteksten, så at bytte UTF-8 ud med UTF-16 dukker op som en enlinjet diff. Et UTF-8 byte order mark (BOM) helt i begyndelsen er et enkelt skjult tegn, som nogle editorer fjerner og andre beholder, en almindelig kilde til spøgelses-diffs. Hvis to filer ser identiske ud, men diff'en viser en ændring på linje 1 tegn 0, så mistænk BOM'en og gem på ny med en kendt encoding-indstilling.
Din XML forlader aldrig din browser. Parser, formatter og diff kører alle på din maskine, lokalt. Ingen analyser af din indtastning, ingen logs, ingen "hjælpsom" tur til skyen. Parsing og validering bruger browserens indbyggede DOMParser, og specen vi følger er W3C XML 1.0. Baggrundslæsning om selve formatet ligger på Wikipedia.