Formatador XML
Formatado no seu navegador e nunca transmitido. Conteudo misto fica na mesma linha em vez de ser reindentado, porque adicionar quebras de linha em volta do texto muda o que o documento diz. A ordem e as aspas dos atributos sao preservadas, e nenhuma declaracao XML e inventada.
Nada do que você digita aqui é armazenado, registrado ou compartilhado.
Cole XML para inden-lo de forma legivel ou reduzi-lo a uma linha, e para verificar se esta bem formado. Os erros apontam a linha e a coluna exatas. Tudo roda no seu navegador, entao nada e enviado.
Como usar
- Cole seu XML no campo de entrada.
- Escolha Formatar ou Minificar e ajuste o recuo se quiser.
- Copie o resultado, ou leia o erro com sua linha e coluna.
Bem formado não é o mesmo que válido
O XML tem duas noções distintas de correção, e elas são confundidas o tempo todo. Bem formado significa que o documento obedece à sintaxe: um único elemento raiz, toda tag fechada pela tag correspondente, atributos entre aspas, comentários e CDATA encerrados e nenhum texto solto fora da raiz. Isso pode ser verificado só com o documento, e é o que esta ferramenta informa.
Válido significa que o documento também está de acordo com um schema - uma DTD, um XSD ou uma gramática RelaxNG - que define quais elementos podem aparecer, em que ordem, quantas vezes e com que formato de atributos. Essa verificação é impossível sem o schema, e um documento pode estar perfeitamente bem formado e, ainda assim, não fazer sentido nenhum diante da gramática que diz seguir.
Os namespaces ficam um pouco à parte das duas coisas. Um prefixo usado sem a declaração xmlns correspondente é um erro de namespace, não de boa formação, então o documento pode passar na verificação de sintaxe e mesmo assim ser rejeitado por um parser que entende namespaces. Se um documento SOAP ou do Office é recusado mesmo formatando sem erro, vale verificar logo se há um prefixo não declarado.
Às vezes o espaço em branco é dado
Esta é a regra que orienta tudo o que o formatador faz. O espaço entre elementos quase sempre é só layout, e trocá-lo por outro layout não muda nada. Já o espaço dentro de conteúdo misto - texto e elementos lado a lado, como um parágrafo com uma palavra em negrito - faz parte do texto, e redistribuí-lo altera o documento.
Por isso, elementos com conteúdo misto ficam exatamente como foram escritos, mesmo que isso deixe uma linha longa no meio de um documento indentado. A alternativa é o que a maioria dos formatadores faz: indentar tudo, inserir uma quebra de linha entre Hello e <b>there</b> e gerar um documento que aparece com um espaço que antes não existia. Fica mais arrumado e está errado.
A especificação oferece xml:space="preserve" para declarar isso explicitamente, e vale usar em qualquer elemento cujo texto seja significativo. Lembre que ele é herdado pelos descendentes até ser sobrescrito, o que costuma surpreender quem o define uma única vez na raiz.
O que realmente quebra documentos XML
O e comercial sem escape é, de longe, o mais comum. Em XML, & inicia uma referência de entidade, então um & solto numa query string de URL ou no nome de uma empresa deixa o documento mal formado. Ele precisa ser escrito &, e o sinal de menor em texto precisa ser <. Existem só cinco entidades predefinidas - amp, lt, gt, quot e apos - e qualquer outra precisa ser declarada ou escrita como referência numérica de caractere.
Em seguida vêm as divergências de codificação. A declaração no topo do arquivo diz em que codificação estão os bytes; se o arquivo depois foi salvo em outra, o parser lê caracteres multibyte como lixo ou simplesmente falha. Um BOM antes da declaração causa falhas próprias em alguns parsers. E mais: alguns caracteres de controle não são permitidos no XML 1.0 de jeito nenhum, nem com escape, então dados binários que vazaram para um campo de texto não se salvam com codificação - precisam ser removidos ou convertidos para Base64.
Por fim, os hábitos do HTML. Valores de atributo sem aspas, tags não fechadas como <br> e atributos duplicados são aceitos no HTML e fatais no XML. Se o documento veio de uma fonte HTML, comece procurando por eles.
Entidades, e um alerta sobre XML não confiável
O XML permite que um documento declare suas próprias entidades numa DTD, inclusive externas, que apontam para um caminho de arquivo ou uma URL. Essa é a base de duas classes de ataque bem conhecidas, e vale conhecê-las mesmo que você só consuma XML e nunca escreva.
A injeção de entidade externa (XXE) usa uma entidade declarada apontando para um arquivo local para fazer o servidor ler esse arquivo e devolver o conteúdo na resposta - historicamente, uma forma confiável de extrair configurações e credenciais de qualquer sistema que processasse XML enviado com as configurações padrão. O ataque billion laughs aninha entidades de modo que cada uma se expande em várias da seguinte, e poucos kilobytes de entrada viram gigabytes na memória.
Nos dois casos, a defesa é desativar o processamento de DTD e a resolução de entidades externas no parser. A maioria das bibliotecas modernas já vem segura por padrão, mas muito código antigo não. Esta página não resolve nada externo: lê o documento como texto e nunca busca nada que ele referencie.
Namespaces: o prefixo não é o nome
Um namespace vincula um prefixo a uma URI, e é a URI que identifica o elemento - o prefixo é apenas um apelido local que pode ser renomeado à vontade. Dois documentos que usam soap: e s: para a mesma URI são equivalentes; dois documentos que usam ns1: para URIs diferentes não são. Código que compara pelo prefixo em vez da URI funciona até alguém reformatar o documento.
Um namespace padrão declarado com xmlns vale para elementos, mas não para atributos, e essa é a regra que quase todo mundo entende errado. Um atributo sem prefixo não pertence a namespace nenhum, independentemente do que o elemento que o contém declara - por isso xsi:type e xml:lang são sempre escritos com prefixo.
Quando um parser rejeita um documento que parece bem formado, a causa costuma ser um prefixo não declarado. A formatação vai funcionar, porque a vinculação de prefixo é uma regra de namespace e não de sintaxe, e a falha só aparece depois, em quem consome o documento.
O que a validação por esquema realmente entrega
Boa formação é sintaxe; validade é conformidade com uma gramática. O DTD é o mecanismo original, limitado e ainda usado para declarar entidades. O XSD é o dominante - escrito no próprio XML, expressivo quanto a tipos de dados e verboso a ponto de ler um ser uma habilidade em si. O RelaxNG é bem mais agradável de escrever e tem suporte menos amplo, que é a troca de sempre.
O que um esquema compra é um contrato verificável mecanicamente na fronteira, antes de o seu código ver os dados: elementos obrigatórios presentes, números onde números devem estar, valores enumerados dentro do conjunto permitido. Em integrações com parceiros, o esquema é muitas vezes a única especificação com que os dois lados concordam.
Validar dentro de um pipeline é questão de um comando - xmllint --schema schema.xsd file.xml --noout - e as mensagens de erro apontam a linha e o elemento. O motivo de fazer isso na borda, e não no código da aplicação, é que uma falha de esquema é uma recusa limpa e com justificativa, enquanto o mesmo problema descoberto três camadas adentro vira um stack trace.
Extraindo dados com XPath
XPath é a linguagem de consulta do XML e vale a hora que qualquer pessoa investir nela. //book/title seleciona todo elemento title sob um book em qualquer ponto do documento; //book[@id='b1'] seleciona por atributo; //book[price>30]/title filtra pelo valor de um filho. É a linguagem de endereçamento que está por baixo do XSLT, das ferramentas XML do Java, do lxml em Python e da maior parte da automação de navegador.
É nos namespaces que o XPath fica desconfortável. A expressão precisa vincular os prefixos que usa, e num documento com namespace padrão os elementos estão nesse namespace mesmo aparecendo sem prefixo - por isso //book não casa com nada e o primeiro XPath de todo mundo contra uma resposta SOAP volta vazio. As ferramentas variam na forma de registrar esse vínculo, e a função local-name() é a saída de emergência grosseira.
O XSLT é a linguagem de transformação construída em cima disso e continua sendo a maneira mais prática de converter um vocabulário XML em outro - ou em HTML - sem escrever código procedural. Sua fama de difícil tem mais a ver com o estilo funcional do que com a sintaxe.
XML continua em toda parte
Documentos de escritório são XML: um .docx ou um .xlsx é um arquivo zip contendo um diretório de partes XML, e é por isso que um documento corrompido às vezes pode ser recuperado descompactando-o e consertando um único arquivo. SVG é XML, então um ícone pode ser editado em um editor de texto e gerado por um template. Feeds RSS e Atom são XML, e o sitemap que este site publica também.
Na integração corporativa e governamental, o SOAP está longe de morto: bancos, seguros, saúde via HL7 e os sistemas aduaneiros e tributários da maioria dos países rodam sobre XML com esquemas e, com frequência, com payloads assinados. XML Signature e XML Encryption permitem assinar um único elemento dentro de um documento maior, algo para o qual o JSON não tem equivalente padronizado.
Layouts de Android, builds do Maven, configuração do .NET e incontáveis descrições de CI também são XML. O formato está fora de moda, não obsoleto, e conseguir ler um deles com naturalidade é uma habilidade durável.
Fazendo parsing de XML que não foi você que escreveu
Os padrões de muitas bibliotecas XML são inseguros para entrada não confiável, e o motivo é o mecanismo de entidades. Entidades externas permitem que um documento referencie um arquivo local ou uma URL, de modo que um servidor que faz parsing de XML enviado por upload com as configurações padrão pode ser induzido a ler /etc/passwd e devolver o conteúdo - o ataque XXE, ainda encontrado em sistemas em produção anos depois de ter sido catalogado.
A expansão é o outro lado. O ataque billion laughs aninha entidades de modo que alguns kilobytes de entrada se expandem para gigabytes em memória, derrubando o processo. Nenhum dos dois ataques precisa de algo incomum: ambos são XML comum usando recursos que a própria especificação define.
A defesa é uma linha na maioria das bibliotecas - desabilitar o processamento de DTD e a resolução de entidades externas - e vale confirmar em vez de supor, já que os padrões mudam conforme a linguagem e a versão. Esta página não resolve absolutamente nada externo: ela lê o documento como texto e nunca busca aquilo a que ele faz referência.
Perguntas frequentes
- Por que parte do meu XML continua em uma linha so?
- Porque tem conteudo misto - texto junto de elementos, como em "Hello <b>there</b>." Indentar isso inseriria quebras de linha e espacos dentro do proprio texto, e um renderizador mostraria "Hello there ." com um espaco sobrando. Esses elementos ficam exatamente como foram escritos. A maioria dos formatadores de XML reflui mesmo assim e altera o documento em silencio.
- Formatar pode mudar o que meu documento diz?
- Nao, e essa e a razao da regra acima. Espaco entre elementos e layout e e substituido; espaco dentro de conteudo misto e dado e e preservado. A ordem e o estilo de aspas dos atributos ficam como foram escritos, comentarios e CDATA sao copiados intactos, e nenhuma declaracao XML e adicionada se o documento nao tinha uma.
- O que "bem formado" verifica de fato?
- Que todo elemento e fechado por uma tag correspondente, que os valores de atributo estao entre aspas, que comentarios e blocos CDATA foram encerrados, e que existe exatamente um elemento raiz sem texto solto fora dele. Nao valida contra DTD ou schema - isso exigiria o schema, que e outra ferramenta.
- Por que meu atributo foi recusado?
- XML exige aspas em torno de todo valor de atributo. HTML deixa voce escrever disabled=true ou width=100 e os navegadores lidam com isso, mas XML nao, e todo parser adiante vai recusar. Se o documento veio de uma fonte HTML, normalmente e a primeira coisa a corrigir.
- Qual a diferenca entre minificar e formatar?
- Sao opostos sobre o mesmo documento. Formatar insere quebras de linha e recuo entre elementos para que possa ser lido; minificar remove tudo isso para que o documento fique o menor possivel para transporte. Nenhum dos dois toca no conteudo misto, entao aplicar um depois do outro devolve voce ao ponto de partida.
- Meu XML e enviado para algum lugar?
- Nao. A analise e a formatacao acontecem no seu navegador, entao arquivos de configuracao, payloads SOAP e dumps de exportacao - que frequentemente contem nomes de host internos, identificadores e dados pessoais - nunca saem da sua maquina.
Última atualização:
Inclua os passos, o resultado esperado e o resultado real. Remova segredos e dados pessoais.