Ik verloor een middag eenmaal aan een config bestand dat " changed" tussen twee implements Het diff in mijn terminal was een muur van rood, honderden lijnen, en ik bracht een uur door met zoeken naar de echte verandering voordat ik besefte dat de deploy pipeline het bestand opnieuw had geformatteerd: opnieuw geïndentificeerd, een paar attributen opnieuw geordend, een aantal lange regels opnieuw ingepakt Niet één byte waar een parser om zou geven was daadwerkelijk veranderd, behalve een enkele waarde die in de ruis verborgen was Een op lijnen gebaseerd diff kon me dat niet vertellen, omdat een op lijnen gebaseerd diff XML niet begrijpt Deze gids gaat over het vergelijken van XML op de manier die het verdient om vergeleken te worden, met behulp van de XML Diff Checker op Toolz.dev, en waarom een structurele vergelijking de enige verandering vindt die er toe doet in plaats van deze te verdrinken in de opmaak.
tl;dr: Een XML-diff vergelijkt twee documenten als knooppuntbomen, niet als tekstregels, dus het opnieuw inspringen, opnieuw ordenen van attributen of het opnieuw inpakken van regels registreert niet als een verandering. Het rapporteert welke elementen, attributen en tekstwaarden zijn toegevoegd, verwijderd of gewijzigd, elk vastgemaakt aan een knooppuntpad. De XML Diff Checker doet dit volledig in uw browser, zonder dat er iets is geüpload.
Wat is een XML diff checker?
Een XML diff checker vergelijkt twee XML documenten en rapporteert wat er veranderde als een set structurele verschillen: welke elementen verschenen of verdwenen, welke attributen veranderde waarde, en waar de tekstinhoud verschilt In plaats van de bestanden regel voor regel te vergelijken, parseert het beide in node bomen en vergelijkt ze als data Je plakt het origineel links, de nieuwe versie rechts, en krijgt een lijst met verschillen terug, elk gelabeld met het exacte pad in de boom waar het gebeurde.
Het punt van een structurele vergelijking is dat XML dezelfde betekenis heeft over veel verschillende byte-indelingen De W3C XML specificatie is expliciet dat sommige oppervlaktedetails geen invloed hebben op het geparseerde document: de volgorde van attributen op een element is niet significant, en witruimte tussen elementen is meestal alleen maar opmaak Twee bestanden kunnen structureel identiek zijn terwijl ze verschillen in inspringing, attribuutvolgorde, regeluitgangen of dat een leeg element is geschreven als <tag></tag> of <tag/>. Een platte tekst geeft dit allemaal weer; een structureel diff negeert het en laat alleen zien wat een parser eigenlijk anders zou lezen.
Op Toolz.dev is de workflow kort Plak beide documenten, kies of je witruimte, attributen of hoofdlettergebruik negeert en druk op Vergelijken De tool parseert beide bomen en somt elk verschil op per pad, gegroepeerd in toegevoegd, verwijderd en gewijzigd, met de oude en nieuwe waarden naast elkaar.
Hoe verschilt een XML-diff van een tekstdiff?
Een tekstdiff, het soort dat in Git en de meeste editors is ingebouwd, vergelijkt bestanden als reeksen regels en vindt de kortste reeks invoegingen en verwijderingen die de een in de ander veranderen Dat klopt precies voor broncode, waar regels betekenisvolle eenheden zijn Het is het verkeerde model voor XML, waarbij betekenis in de boom leeft en de regeleinden decoratie zijn.
De faalmodi zijn voorspelbaar Herindent het document en een tekst diff markeert bijna elke regel veranderd Herschik twee attributen op één element en het markeert die lijn, ook al is het element identiek aan een parser Voeg een enkel kind toe aan de bovenkant en elke regel eronder verschuift, dus het diff toont een cascade van bewegingen die niet echt veranderingen zijn Uiteindelijk scant u honderden gemarkeerde lijnen om degene te vinden die er toe doet, dat is de middag die ik hierboven heb beschreven.
Een structureel diff omzeilt dat allemaal door eerst te parseren Het bouwt een boom uit elk document, loopt vervolgens de twee bomen samen met elkaar knooppunten vergelijken Het formatteren van verschillen bestaat gewoon niet op boomniveau, dus ze kunnen niet in de uitvoer verschijnen Wat overblijft is de reeks veranderingen die zou veranderen hoe software die de XML verbruikt zich gedraagt, wat bijna altijd de set is waar u eigenlijk om geeft Als uw gegevens JSON zijn in plaats van XML, geldt hetzelfde principe en de JSON-differentiatie tool doet daar de gelijkwaardige structurele vergelijking.
Hoe bepaalt het wat er is veranderd?
De vergelijking gebeurt in drie lagen bij elk element, en het scheiden ervan maakt de uitvoer leesbaar.
Attributen worden vergeleken op naam, onafhankelijk van de volgorde waarin ze in de tag voorkomen, omdat de attribuutvolgorde niet significant is in XML. Voor elk element controleert het gereedschap welke attributen aan beide kanten bestaan, en rapporteert een attribuut zoals gewijzigd wanneer de waarde ervan verschilt, toegevoegd wanneer het alleen aan de rechterkant verschijnt, of verwijderd wanneer het alleen aan de linkerkant verschijnt. Opnieuw ordenen <a x="1" y="2"/> tegen <a y="2" x="1"/> levert helemaal geen verschil op.
Tekstinhoud wordt vergeleken als de directe tekst van elk element Met witruimteverwerking aan worden spaties en nieuwe regels ingeklapt en wordt de leidende en achterliggende witruimte bijgesneden, dus het mooi afdrukken van het document zorgt niet voor fantoomtekstwijzigingen. Er wordt alleen een echte verandering in de woorden tussen de tags gerapporteerd.
Kindelementen zijn het interessante deel Elementen die een tagnaam delen, worden gekoppeld aan hun volgorde van verschijnen: de eerste <item> links wordt vergeleken met de eerste <item> aan de rechterkant, de tweede tot de tweede, enzovoort. Wanneer de ene kant meer voorkomt dan de andere, worden de extra's gerapporteerd als toegevoegd of verwijderd in plaats van een verkeerde uitlijning af te dwingen. Deze ordeningsregel zorgt ervoor dat een kleine verandering in één herhaald element niet in een diff van elke broer of zus terechtkomt.
Hier is hoe de twee vergelijkingsmodellen zich opstapelen:
| Aspect | Tekstdiff | XML-diff (structureel) |
|---|---|---|
| Eenheid vergeleken | Regels van tekst | Knooppunten in een boom |
| Reindentatie | Toont als wijzigingen | Genegeerd |
| Attribuut herschikken | Toont als een verandering | Genegeerd |
| Rapporten veranderen locatie | Lijnnummer | Knooppuntpad, bijvoorbeeld /catalogus/boek[2]/@id |
| Onderscheidt element vs attribuut vs tekst | heel weinig | ja |
| het beste voor | Broncode, proza | XML-configuratie, API-payloads, SVG, sitemaps |
Een concreet voorbeeld maakt de gelaagdheid duidelijk Neem een kleine boekencatalogus waarbij, tussen twee versies, één boek' s categorie attribuutwijzigingen van fictie naar mysterie, datzelfde boek' s prijstekst verandert van 12,99 naar 14,99, en het tweede boek krijgt een nieuw isbn-element Een lijndiff zou alle drie markeren plus elke herindentatie eromheen, door elkaar gegooid Het structurele diff rapporteert precies drie verschillen: een gewijzigd attribuut op het categoriepad, een gewijzigd tekstknooppunt op het prijspad, en een toegevoegd element op het isbn-pad Elk is getagd met zijn soort, zodat je in één oogopslag kunt zien dat twee bewerkingen waren op bestaande gegevens en één de toevoeging is een echte lezing.
De tool groepeert de resultaten ook in toegevoegde, verwijderde en gewijzigde tabbladen met een lopende telling, zodat u eerst grove vragen kunt beantwoorden, zoals " heeft alles verwijderd, & quot; voordat u in de details boort. Op een groot document is deze volgorde belangrijk: verwijderingen zijn vaak de gevaarlijkste verandering, omdat een gevallen element in stilte een vereist veld kan strippen, en het kunnen isoleren ervan zonder door niet-gerelateerde bewerkingen te waden een echte tijdbesparing is.
Wat betekent het knooppuntpad in een verschil?
Elk verschil wordt gelabeld met een pad dat je precies vertelt waar in de boom het zit, zodat je er naartoe kunt springen in plaats van het bestand te scannen Het pad is opgebouwd uit elementnamen, verbonden door schuine strepen vanaf de wortel naar beneden Wanneer een element broers en zussen met dezelfde naam heeft, maakt een op één gebaseerde index tussen haakjes ondubbelzinnig welke, dus /catalog/book[2] is het tweede boek Een attribuut is geschreven met een @ voorvoegsel, zoals in /catalog/book[1]/@category, en een tekstwijziging is gemarkeerd met text(), zoals in /catalog/book[2]/price/text().
Deze notatie ligt bewust dicht bij XPath, de W3C-taal voor het adresseren van knooppunten in een XML-document, dus als u XPath al leest, zullen de paden vertrouwd aanvoelen en kunt u vaak een soortgelijke uitdrukking in uw eigen tooling plakken om hetzelfde knooppunt te selecteren Zelfs zonder XPath te kennen, lezen de paden natuurlijk: namen gaan door de boom, haakjes kiezen een broer of zus, @ is een attribuut, en text() is de inhoud.
Omdat het pad ook het soort verandering noemt, beantwoordt het rapport drie vragen tegelijk: wat veranderde, waar het leeft en of het een element, een attribuut of tekst was. Dat is meestal genoeg om het juiste bestand te openen en de juiste lijn te repareren zonder verder te jagen.
Wanneer zou ik dit eigenlijk gebruiken?
Configuratiedrift is het geval dat ik het meest raak Wanneer een service zich verschillend gedraagt tussen twee omgevingen en de enige verdachte een XML-configuratie is, vertelt het vergelijken van de twee bestanden je structureel in seconden of een waarde echt is veranderd of iemand het bestand zojuist opnieuw heeft geformatteerd Hetzelfde geldt voor het bouwen en implementeren van pijpleidingen die XML herschrijven, waarbij je moet bevestigen dat een transformatie alleen is gewijzigd wat het moest doen.
API en integratie werk is de volgende SOAP reacties, RSS en Atom feeds, en oudere REST API's spreken nog steeds XML, en wanneer een payload stopt met het correct parseren van een structureel diff tegen een bekende-goede sample lokaliseert het overtredende element snel SVG is XML ook, dus het vergelijken van twee geëxporteerde pictogrammen laat precies zien welk pad of attribuut een editor gewijzigd Sitemaps, Android layout bestanden, Maven POM's, en .docx internals zijn allemaal XML onder de motorkap, en hebben allemaal baat bij dezelfde behandeling Ik bouw over de stapel, en XML duikt op in meer hoeken dan mensen verwachten, daarom leeft dit naast de XML-formatter en XML naar JSON in mijn bladwijzers Ik schetste hoe deze passen in een bredere kit in de JSON naar XML-gids.
Er is ook een code-review hoek Wanneer een pull verzoek raakt een XML armatuur of een gegenereerd bestand, de raw diff in de review UI is vaak onleesbaar omdat een formatter herschreef het geheel Het uitvoeren van de voor en na door middel van een structurele vergelijking, vervolgens het plakken van het korte rapport in de review, vertelt uw recensent wat er daadwerkelijk veranderd in één oogopslag in plaats van te vragen hen om een muur van rood te vertrouwen De tool' s kopieerbare tekst rapport bestaat voor precies dat: een compacte samenvatting van elke toegevoegde, verwijderde, en veranderde node met zijn voor en na waarden, klaar om te vallen in een ticket, een commit bericht, of een chat thread.
De naburige vergelijkingstools dekken de gevallen XML diff niet Wanneer uw gegevens in tabelvorm zijn, de CSV-verschil vergelijkt rijen en cellen, en voor twee gewone lijsten de Lijst Vergelijk tool stelt wel verschillen in Ze delen dezelfde filosofie: parseer de data eerst in zijn natuurlijke vorm, vergelijk dan, dus het diff weerspiegelt betekenis in plaats van lay-out.
Wat zijn de limieten, en is mijn XML privé?
De tool vergelijkt structuur, wat betekent dat het opzettelijk niet het soort verschillen rapporteert dat structuur niet vastlegt. Het opnieuw ordenen van twee attributen, het veranderen van de inspringing of het verwisselen van de zelfsluitende syntaxis worden allemaal door het ontwerp als geen verandering behandeld. Als uw gebruiksscenario echt een byte-exacte vergelijking nodig heeft, is een tekstdiff het juiste hulpmiddel en dat is niet. Het structurele diff koppelt ook herhaalde elementen per positie, dus als dezelfde records in een andere volgorde worden geschud, ziet het gereedschap de verplaatste in plaats van verplaatst; het eerst sorteren van beide documenten met een stabiele sleutel, wanneer dat logisch is, geeft het schoonste resultaat.
Misvormde XML wordt gerapporteerd in plaats van geraden op Als een document een niet-overeenkomende of niet-gesloten tag heeft, of meer dan één rootelement, noemt de tool het probleem en vertelt u van welke kant het afkomstig is, zodat u nooit een misleidend diff krijgt van gebroken invoer. Het verwerkt de gebruikelijke constructies uit de echte wereld die een parser moet: attributen in enkele of dubbele aanhalingstekens, zelfsluitende tags, CDATA-secties, opmerkingen, verwerkingsinstructies en standaard entiteitsreferenties zoals < en &.
Op privacy draait alles in uw browser Beide documenten worden lokaal geparseerd en vergeleken, en niets wordt geüpload, gelogd of opgeslagen Dat is de eigenschap die het veilig maakt om een productieconfiguratie, een interne API-payload of een klantspecifiek bestand te verspreiden, die geen van allen op een vreemde & #39; s server thuishoren De Gegevensprivacy in online tools guide legt uit hoe u kunt verifiëren dat een tool echt aan de clientzijde staat, wat de moeite waard is voordat u iets gevoeligs in een webtool plakt.
Veelgestelde vragen
Hoe vergelijk ik twee XML-bestanden?
Plak de originele XML in het eerste veld en de gewijzigde XML in het tweede, druk vervolgens op Vergelijken De tool parseert zowel in knooppuntbomen als geeft een overzicht van elk toegevoegd, verwijderd en gewijzigd element, attribuut en tekstwaarde, elk vastgemaakt aan het knooppuntpad. Er wordt niets geüpload.
Hoe verschilt een XML-diff van een platte tekstdiff?
Een tekstdiff vergelijkt bestanden regel voor regel, dus door opnieuw in te richten, attributen opnieuw te ordenen of regels opnieuw in te wikkelen ziet bijna alles er veranderd uit. Een XML verspreidt beide documenten eerst in bomen en vergelijkt ze structureel, dus het rapporteert alleen verschillen die de manier waarop een parser het document leest, zouden veranderen.
Telt het herschikken van attributen als een verandering?
Nee Attributen worden op naam vergeleken ongeacht de volgorde waarin ze in de tag voorkomen, omdat de attribuutvolgorde niet significant is in XML Alleen een gewijzigde waarde, een toegevoegd attribuut of een verwijderd attribuut wordt gerapporteerd.
Hoe worden herhaalde elementen op elkaar afgestemd tussen de twee documenten?
Kindelementen die een tagnaam delen, worden gekoppeld aan hun volgorde van verschijnen, dus het eerste item wordt vergeleken met het eerste item, het tweede met het tweede, enzovoort. Als het ene document meer voorkomt dan het andere, worden de extra's gerapporteerd als toegevoegd of verwijderd.
Wat betekent het knooppuntpad in elk verschil?
Het pad laat zien waar in de boom de wijziging zit, met behulp van elementnamen, een index op basis van één tussen haakjes als er broers en zussen met dezelfde naam zijn, @naam voor een attribuut en tekst () voor tekstinhoud. /catalogus/boek [2]/@id verwijst bijvoorbeeld naar het id-attribuut van het tweede boek.
Heeft witruimte of opmaak invloed op de vergelijking?
Standaard wordt tekst die alleen witruimte bevat genegeerd en worden reeksen witruimte binnen tekst samengevouwen, zodat het opnieuw formatteren van het document geen valse verschillen creëert U kunt vertrouwen op de structurele vergelijking in plaats van de inspringing exact te matchen.
Wat gebeurt er als de XML verkeerd is opgemaakt?
De tool rapporteert een duidelijke fout bij het benoemen van het probleem, zoals een niet-overeenkomende of niet-gesloten tag, en vertelt u uit welk document het afkomstig is. Er wordt niet geraden op een reparatie, dus u krijgt nooit een misleidend verschil door kapotte invoer.
Worden mijn XML-documenten ergens geüpload?
Nee Alle parseren en vergelijken gebeurt als JavaScript in uw browser Niets wordt verzonden, gelogd, of opgeslagen U kunt dit bevestigen door het netwerk tabblad te bekijken of door het verbreken van het internet, de tool blijft offline werken.
Vergelijk uw eigen documenten met de gratis XML Diff Checker. Het rapporteert structurele verschillen per knooppuntpad, volledig in uw browser, zonder dat er iets is geüpload.
