Incolla, formatta e confronta due documenti XML affiancati. Pretty-print, validazione e evidenziazione consapevole dei namespace integrati.
Uno strumento gratuito nel browser per confrontare due documenti XML. Incolla un vecchio pom.xml a sinistra, il nuovo a destra, e le modifiche si illuminano elemento per elemento. Niente esce dalla tua macchina.
Il diff in sé è a livello di carattere, e la validazione passa per il DOMParser nativo del browser. Il pulsante Format di ogni pannello rimette in fila l'XML con un'indentazione coerente. La validazione live segnala markup malformato, tag non chiusi e riferimenti a entità rotti mentre digiti.
Se ti è capitato di aprire un application context Spring di 4.000 righe in code review cercando l'unico bean il cui attributo class è cambiato, questo è lo strumento che ti porta lì in pochi secondi. Per la prosa pura, il nostro strumento di diff testuale è la scelta giusta. Per dati strutturati con coppie chiave/valore, JSON diff gestisce il riordino degli oggetti in modo più pulito di quanto possa fare l'XML.
Il diff lavora a livello di carattere, poi una passata semantica di post-processing sposta le evidenziazioni perché cadano su nomi di tag, attributi e contenuto testuale invece che su punteggiatura casuale. Le inserzioni appaiono in verde nel pannello di destra, le rimozioni in rosso in quello di sinistra.
XML ha qualche stranezza che la specifica chiama in causa, e mordono tutte quando confronti due file come testo. La specifica XML 1.0 dice che l'ordine degli attributi su un elemento non è significativo, quindi <img src="a.png" alt="x"/> e <img alt="x" src="a.png"/> sono lo stesso per un parser. Un diff testuale segnerà comunque lo scambio. Senza un confronto strutturale non c'è cura; la soluzione pratica è formattare entrambi i lati con lo stesso strumento per mantenere stabile l'ordine degli attributi.
I namespace aggiungono un altro livello. Due documenti che legano lo stesso URI a prefissi diversi sono equivalenti secondo Namespaces in XML 1.0, ma un diff testuale colora ogni scambio ns1: contro ns2: come una modifica. Formatta entrambi i lati, allinea il prefisso su uno dei due e rifai il diff. Per una pipeline che normalizza namespace e ordine degli attributi prima del diff, dai un'occhiata a XSLT 3.0 o a una fase di canonicalizzazione conforme a Canonical XML.
Due pannelli di testo, un diff. Niente registrazione, niente upload, nessun viaggio al server.
Incolla l'XML vecchio a sinistra, il nuovo a destra. Oppure clicca Carica su uno dei due lati per aprire direttamente un file .xml, .pom, .config o .svg. Il pulsante Esempio riempie entrambi i pannelli con un piccolo pom.xml se vuoi vedere prima lo strumento in azione.
Clicca Format su ciascun pannello per il pretty-print con indentazione e a capo coerenti. Questo normalizza il whitespace, così il diff evidenzia le vere modifiche di contenuto e non il rumore di formato di un file Windows CRLF contro uno Unix LF. Il badge di validazione diventa verde quando DOMParser accetta il documento come ben formato.
Le rimozioni appaiono evidenziate in rosso a sinistra, le inserzioni in verde a destra. Scorri uno dei due lati e l'altro segue. I contatori di modifiche in ciascuna intestazione dicono quante edit distinte ha trovato il diff fra nomi di elementi, valori di attributi e contenuto testuale.
Un PR di Dependabot fa salire quindici coordinate Maven in un colpo solo. Incolla il vecchio pom.xml contro il nuovo per confermare gli upgrade veri: spring-boot-starter-web è passato da 3.1.5 a 3.2.1, jackson-databind da 2.15.3 a 2.16.0, ed è stata aggiunta una nuova dipendenza micrometer-registry-prometheus. Il diff rende ovvi i salti di versione, così puoi incrociare il changelog prima di approvare.
Quando un servizio comincia a fallire dopo un refactor, la causa è spesso un singolo bean il cui attributo class o argomento del costruttore è cambiato in applicationContext.xml. Incolla la revisione che funzionava contro HEAD; il diff fa emergere all'istante la sostituzione di class="com.acme.OldDataSource" con class="com.acme.HikariDataSource", e i tag <property> attorno ti dicono quale configurazione si è spostata insieme.
Un'integrazione SOAP che ieri girava oggi torna un Fault. Cattura entrambe le buste dal tuo logger di pacchetti o dalle registrazioni WireMock, falle finire nel diff e l'elemento incriminato salta fuori: un <currencyCode> passato da USD a un elemento mancante, o una dichiarazione di namespace sul soap:Envelope che il servizio a monte ha cambiato senza dirlo. Senza vista affiancata, trovarlo in 800 righe di XML è impresa persa.
Prima di pubblicare una release, fai diff di AndroidManifest.xml contro il tag precedente per intercettare la deriva dei permessi. Un nuovo <uses-permission android:name="android.permission.READ_CONTACTS"/> sgusciato dentro con l'aggiornamento di un SDK di terze parti è esattamente il tipo di cosa che il Play Store segnala in revisione. Il diff fa emergere anche modifiche agli elementi <intent-filter> e ai flag android:exported, punti caldi tipici delle revisioni di sicurezza.
Un lettore di feed si rompe perché la fonte è passata da RSS 2.0 ad Atom 1.0, o un publisher ha aggiunto un nuovo namespace <media:thumbnail>. Salva uno snapshot del feed che funzionava, fanne diff contro quello live, e il cambiamento strutturale appare in pochi secondi. Stesso flusso per import OPML e feed di podcast in cui i metadati a livello di channel si sono spostati tra elementi.
Un .docx è solo uno zip con XML dentro. Scompatta entrambe le versioni di un contratto, lancia un diff su word/document.xml e vedi le modifiche reali del testo senza che la marcatura del controllo modifiche di Word si metta in mezzo. Utile quando un paralegale ti rimanda una copia "pulita" che dovrebbe corrispondere a un redline; l'XML ti dice quali elementi di paragrafo si sono spostati e quale formattazione a livello di run è cambiata.
Un breve cheat sheet sui casi limite di parsing che questo strumento fa emergere più spesso. Tutto ancorato alle specifiche XML del W3C.
| Topic | What this tool does |
|---|---|
| Ordine degli attributi | Non significativo per la spec XML 1.0. Per un parser <a x="1" y="2"/> equivale a <a y="2" x="1"/>. Un diff testuale segnerà lo scambio; formatta entrambi i lati per tenere stabile l'ordine. |
| Namespace | Legati a URI, alias tramite prefisso. Due documenti che legano lo stesso URI a prefissi diversi sono equivalenti. Vedi Namespaces in XML 1.0. |
| Sezioni CDATA | Testo letterale racchiuso in <![CDATA[ ... ]]>. Il parser non interpreta tag né entità all'interno. La sequenza ]]> non può comparire dentro un blocco CDATA. |
| Contenuto misto | Gli elementi possono contenere testo, elementi figli e whitespace in qualsiasi ordine. <p>Ciao <b>mondo</b>!</p> è contenuto misto e gli spazi lì sono significativi. |
| Commenti | <!-- commento -->. Non possono contenere -- al loro interno. La maggior parte dei processori li rimuove, ma in questo diff sono conservati come testo. |
| Encoding e BOM | Dichiarato via <?xml version="1.0" encoding="UTF-8"?>. Il BOM UTF-8 è un primo carattere nascosto; causa comune di diff fantasma di un carattere in riga 1. |
| XML 1.0 vs 1.1 | Quasi tutti usano XML 1.0. La versione 1.1 aggiunge il supporto per ulteriori caratteri di controllo Unicode nel contenuto degli elementi; raro vederlo in pratica. |
| Riferimenti a entità | Cinque predefiniti: & < > ' ". Anche i riferimenti numerici come é per lettere accentate sono validi. <br/> auto-chiuso e <br></br> esplicito sono equivalenti. |
Sì, entrambi appariranno. Un diff testuale confronta i caratteri riga per riga, quindi riformattare, riordinare gli attributi o il whitespace dentro gli elementi appare come differenza anche se il documento è logicamente identico. Clicca prima Format su entrambi i pannelli e il diff si concentra sulle vere modifiche di contenuto. Per alberi di elementi con figli profondamente annidati, un confronto strutturale via XSLT o Canonical XML è il passo successivo; questo strumento copre il 95% delle revisioni XML pratiche senza quella complessità.
No, non per un parser XML. La spec XML 1.0 dice che l'ordine degli attributi non è significativo, quindi <img src="a.png" alt="x"/> e <img alt="x" src="a.png"/> rappresentano lo stesso elemento. Un diff di caratteri segna comunque il riordino perché vede il testo grezzo. Il rimedio è formattare entrambi i lati con lo stesso strumento perché l'ordine degli attributi sia coerente prima del diff, oppure applicare la normalizzazione di Canonical XML se controlli la pipeline.
I namespace sono URI-based, ma li leghi a prefissi corti nel documento. Due file che legano http://maven.apache.org/POM/4.0.0 a prefissi diversi sono equivalenti secondo la spec Namespaces in XML, ma il diff testuale segnerà come modifica ogni scambio di prefisso. La soluzione pratica è formattare i due file e usare prefissi coerenti su entrambi i lati. Per pipeline automatiche, una passata di Canonical XML normalizza il problema.
Sì. Le sezioni CDATA sono solo contenuto testuale con l'indicazione al parser di non interpretarlo, quindi <![CDATA[<b>raw</b>]]> viene confrontato come i caratteri letterali al suo interno. Blocchi CDATA lunghi (script tag, HTML embedded, SQL) si diffano puliti. L'unico tranello è che non puoi avere ]]> dentro una sezione CDATA; se i dati contengono quella sequenza, la sorgente deve spezzarla in due blocchi CDATA, cosa che il diff mostra com'è scritta.
Usa XSLT quando vuoi trasformare l'XML o normalizzarlo prima del confronto (ordinare i figli, eliminare i commenti, canonicalizzare i namespace). Usa questo diff quando vuoi vedere cosa è cambiato fra due file specifici. I due sono complementari: una passata XSLT seguita da questo diff è un buon flusso per XML rumoroso generato da macchina. Per la maggior parte dei casi di code review (pom.xml, AndroidManifest, application context), il diff da solo basta.
Un po'. La dichiarazione <?xml version="1.0" encoding="UTF-8"?> fa parte del testo del documento, quindi scambiare UTF-8 con UTF-16 appare come un diff su una riga. Un byte order mark (BOM) UTF-8 proprio all'inizio è un singolo carattere nascosto che alcuni editor tolgono e altri conservano, fonte tipica di diff fantasma. Se due file sembrano identici ma il diff mostra un cambio in riga 1 carattere 0, sospetta del BOM e risalva con un'impostazione di encoding nota.
Il tuo XML non lascia mai il browser. Parser, formattatore e diff girano tutti sulla tua macchina, in locale. Niente analytics sull'input, niente log, niente giro "servizievole" verso il cloud. Parsing e validazione usano il DOMParser nativo del browser, e la spec che seguiamo è W3C XML 1.0. Per approfondire il formato in sé, c'è Wikipedia.