Cole, formate e compare dois documentos XML lado a lado. Pretty-print, validação e destaque consciente de namespaces já vêm prontos.
Uma ferramenta gratuita no navegador para comparar dois documentos XML. Cole um pom.xml antigo à esquerda, o novo à direita, e as mudanças se acendem elemento por elemento. Nada sai da sua máquina.
O diff em si é em nível de caractere, e a validação passa pelo DOMParser nativo do navegador. O botão Format de cada painel reformata seu XML com indentação consistente. A validação ao vivo aponta marcação malformada, tags não fechadas e referências de entidade quebradas enquanto você digita.
Se você já abriu um application context Spring de 4.000 linhas em uma revisão de código tentando achar o único bean cujo atributo class mudou, esta é a ferramenta que te leva até lá em segundos. Para prosa simples, nossa ferramenta de diff de texto é a escolha certa. Para dados estruturados com pares chave/valor, o JSON diff lida com reordenação de objetos de forma mais limpa do que o XML.
O diff roda em nível de caractere e, em seguida, uma passagem semântica de pós-processamento desloca os destaques para que caiam em nomes de tag, atributos e conteúdo de texto, em vez de pontuação aleatória. Inserções aparecem em verde no painel da direita, remoções em vermelho no painel da esquerda.
XML tem algumas peculiaridades que a especificação aponta, e todas atrapalham quando você compara dois arquivos como texto. A especificação XML 1.0 diz que a ordem dos atributos em um elemento não é significativa, então <img src="a.png" alt="x"/> e <img alt="x" src="a.png"/> são iguais para um parser. Um diff de texto ainda vai marcar a troca. Não há solução sem uma comparação estrutural; a alternativa prática é formatar os dois lados com a mesma ferramenta para manter a ordem dos atributos estável.
Namespaces adicionam mais uma camada. Dois documentos que vinculam o mesmo URI a prefixos diferentes são equivalentes pelo Namespaces in XML 1.0, mas um diff de texto vai pintar cada troca de ns1: para ns2: como uma alteração. Formate os dois lados, ajuste o prefixo em um deles e refaça o diff. Para um pipeline que normalize namespaces e ordem de atributos antes do diff, dê uma olhada em XSLT 3.0 ou em uma etapa de canonicalização conforme o Canonical XML.
Dois painéis de texto, um diff. Sem cadastro, sem upload, sem ida e volta a um servidor.
Cole o XML antigo à esquerda e o novo à direita. Ou clique em Carregar em qualquer lado para abrir um arquivo .xml, .pom, .config ou .svg direto. O botão Exemplo preenche os dois painéis com um pequeno pom.xml caso você queira ver a ferramenta em ação primeiro.
Clique em Format em cada painel para imprimir com indentação e quebras de linha consistentes. Isso normaliza o whitespace para que o diff destaque mudanças reais de conteúdo, e não ruído de formatação vindo de um arquivo Windows CRLF contra um Unix LF. O selo de validação fica verde quando o DOMParser aceita seu documento como bem-formado.
Remoções aparecem com destaque vermelho à esquerda, inserções com destaque verde à direita. Role qualquer um dos lados, o outro acompanha. Os contadores de mudanças em cada cabeçalho dizem quantas edições distintas o diff encontrou em nomes de elementos, valores de atributos e conteúdo de texto.
Um PR do Dependabot sobe quinze coordenadas Maven de uma vez. Cole o pom.xml antigo contra o novo para confirmar os upgrades reais: spring-boot-starter-web foi de 3.1.5 para 3.2.1, jackson-databind de 2.15.3 para 2.16.0, e uma nova dependência micrometer-registry-prometheus foi adicionada. O diff deixa as mudanças de versão óbvias para você cruzar com o changelog antes de aprovar.
Quando um serviço começa a falhar depois de uma refatoração, a causa costuma ser um único bean cujo atributo class ou argumento de construtor mudou em applicationContext.xml. Cole a revisão que funcionava contra o HEAD; o diff faz vir à tona na hora a troca de class="com.acme.OldDataSource" para class="com.acme.HikariDataSource", e as tags <property> ao redor mostram que configuração se moveu junto.
Uma integração SOAP que funcionava ontem retorna um Fault hoje. Capture os dois envelopes do seu logger de pacotes ou de gravações do WireMock, jogue no diff e o elemento problemático salta aos olhos: um <currencyCode> que saiu de USD para um elemento ausente, ou uma declaração de namespace no soap:Envelope que o serviço upstream mudou em silêncio. Sem visão lado a lado, achar isso em 800 linhas de XML é tarefa perdida.
Antes de subir uma release, faça diff do AndroidManifest.xml contra a tag anterior para pegar avanço silencioso de permissões. Um <uses-permission android:name="android.permission.READ_CONTACTS"/> novo que entrou junto com a atualização de um SDK de terceiros é exatamente o tipo de coisa que a Play Store vai sinalizar na revisão. O diff também mostra mudanças em elementos <intent-filter> e em flags android:exported, focos comuns em revisões de segurança.
Um leitor de feeds quebra porque a fonte trocou de RSS 2.0 para Atom 1.0, ou um publisher adicionou um novo namespace <media:thumbnail>. Salve um snapshot do feed que funcionava, faça diff contra o atual e a mudança estrutural aparece em segundos. Mesmo fluxo para imports OPML e feeds de podcast em que metadados em nível de channel se moveram entre elementos.
Um .docx é só um zip com XML dentro. Descompacte as duas versões de um contrato, rode um diff em word/document.xml e você vê as edições reais do texto sem a marcação de controle de alterações do Word atrapalhando. Útil quando um paralegal devolve uma cópia "limpa" supostamente igual a um redline; o XML mostra quais elementos de parágrafo mudaram de lugar e qual formatação em nível de run mudou.
Uma cola curta dos casos de borda de parsing que esta ferramenta mais expõe. Tudo embasado nas especificações XML do W3C.
| Topic | What this tool does |
|---|---|
| Ordem dos atributos | Não é significativa pela spec XML 1.0. <a x="1" y="2"/> equivale a <a y="2" x="1"/> para um parser. Um diff de texto vai marcar a troca; formate os dois lados para manter a ordem estável. |
| Namespaces | Vinculados por URI, com alias por prefixo. Dois documentos vinculando o mesmo URI a prefixos diferentes são equivalentes. Veja Namespaces in XML 1.0. |
| Seções CDATA | Texto literal envolvido por <![CDATA[ ... ]]>. O parser não interpreta tags nem entidades dentro. A sequência ]]> não pode aparecer dentro de um bloco CDATA. |
| Conteúdo misto | Elementos podem conter texto, elementos filhos e whitespace em qualquer ordem. <p>Olá <b>mundo</b>!</p> é conteúdo misto e o whitespace ali é significativo. |
| Comentários | <!-- comentário -->. Não podem conter -- internamente. A maioria dos processadores remove, mas neste diff são preservados como texto. |
| Encoding e BOM | Declarado via <?xml version="1.0" encoding="UTF-8"?>. O BOM UTF-8 é um primeiro caractere oculto; causa comum de diffs fantasmas de um caractere na linha 1. |
| XML 1.0 vs 1.1 | Quase todo mundo usa XML 1.0. A versão 1.1 adiciona suporte a caracteres de controle Unicode adicionais no conteúdo de elementos; raro de ver na prática. |
| Referências de entidade | Cinco embutidas: & < > ' ". Referências numéricas como é para letras com acento também são válidas. <br/> autofechado e <br></br> explícito são equivalentes. |
Sim, ambos aparecerão. Um diff de texto compara caracteres linha a linha, então reformatação, reordenação de atributos ou whitespace dentro dos elementos aparecem como diferenças mesmo quando o documento é logicamente idêntico. Clique em Format nos dois painéis primeiro e o diff foca em mudanças reais de conteúdo. Para árvores de elementos com filhos profundamente aninhados, uma comparação estrutural via XSLT ou Canonical XML é o passo seguinte; esta ferramenta dá conta de 95% das revisões práticas de XML sem essa complexidade.
Não, não para um parser XML. A spec XML 1.0 diz que a ordem dos atributos não é significativa, então <img src="a.png" alt="x"/> e <img alt="x" src="a.png"/> representam o mesmo elemento. Um diff de caracteres ainda vai marcar a reordenação porque vê o texto cru. A solução é formatar os dois lados com a mesma ferramenta para que a ordem dos atributos seja consistente antes do diff, ou aplicar normalização Canonical XML se você controla o pipeline.
Namespaces são baseados em URI, mas você os vincula a prefixos curtos no documento. Dois arquivos que vinculam http://maven.apache.org/POM/4.0.0 a prefixos diferentes são equivalentes pela spec Namespaces in XML, mas o diff de texto vai marcar cada troca de prefixo como uma mudança. A solução prática é formatar os dois arquivos e usar prefixos iguais nos dois lados. Para pipelines automatizados, uma passagem por Canonical XML normaliza isso.
Sim. Seções CDATA são apenas conteúdo de texto com a instrução de não interpretar para o parser, então <![CDATA[<b>raw</b>]]> é comparado pelos caracteres literais lá dentro. Blocos CDATA longos (script tags, HTML embutido, SQL) fazem diff sem problema. A única pegadinha é que você não pode ter ]]> dentro de uma seção CDATA; se seus dados contiverem essa sequência, a fonte precisa dividi-la em dois blocos CDATA, o que o diff vai mostrar exatamente como está escrito.
Use XSLT quando quiser transformar XML ou normalizá-lo antes de comparar (ordenar filhos, remover comentários, canonicalizar namespaces). Use este diff quando quiser ver o que mudou entre dois arquivos específicos. Os dois são complementares: uma passagem prévia por XSLT mais este diff é um fluxo forte para XML ruidoso gerado por máquina. Para a maioria dos cenários de revisão de código (pom.xml, AndroidManifest, application context), o diff sozinho já basta.
Um pouco. A declaração <?xml version="1.0" encoding="UTF-8"?> faz parte do texto do documento, então trocar UTF-8 por UTF-16 aparece como um diff de uma linha. Um byte order mark (BOM) UTF-8 logo no início é um caractere oculto que alguns editores removem e outros mantêm, fonte clássica de diffs fantasmas. Se dois arquivos parecem idênticos mas o diff mostra uma mudança na linha 1 caractere 0, suspeite do BOM e salve de novo com uma configuração de encoding conhecida.
Seu XML nunca sai do seu navegador. O parser, o formatador e o diff rodam todos na sua máquina, localmente. Sem analytics da sua entrada, sem logs, sem ida e volta "prestativa" à nuvem. Parsing e validação usam o DOMParser nativo do navegador, e a spec que seguimos é o W3C XML 1.0. Para leitura de fundo sobre o formato, veja a Wikipédia.