Formatador e visualizador de XML

O que este formatador de XML faz

XML é legível por projeto, mas quase nunca chega assim. Respostas de API, envelopes SOAP, sitemaps e arquivos de exportação vêm minificados — uma linha, milhares de caracteres, zero indentação. Esta ferramenta recoloca a estrutura: analisa o documento, reconstrói com indentação consistente e apresenta como árvore que você colapsa galho por galho até achar o que interessa.

Tudo roda localmente

A análise usa o DOMParser, o motor de XML que já vem no seu navegador — o mesmo que renderiza qualquer página que você abre. Não existe etapa de upload nem ida ao servidor. Isso importa mais do que conveniência: arquivos XML carregam rotineiramente notas fiscais, prontuários, folha de pagamento e tokens de API. Colar esse conteúdo numa ferramenta que o envia para terceiros é vazamento de dado, mesmo quando a ferramenta é bem-intencionada. Aqui o arquivo não sai da aba.

Formatar vs. minificar

Uma ressalva que vale conhecer: espaço em branco dentro de um nó de texto pode ser significativo. Em <nome> Ana </nome> aqueles espaços fazem parte do valor, e um consumidor rigoroso pode tratá-los assim. Este formatador preserva o conteúdo dos nós de texto intacto e só reformata o espaço entre elementos, que é onde a indentação é segura.

O que “válido” significa aqui

XML tem dois níveis distintos de correção, e confundi-los é a fonte mais comum de dúvida quando um arquivo é rejeitado adiante:

• Bem-formado — a sintaxe é legal. Exatamente um elemento raiz, toda tag fechada na ordem certa, valores de atributo entre aspas e os cinco caracteres reservados (< > & " ') escapados. É isso que verificamos, e a mensagem de erro aponta a linha exata.
• Válido — o documento também obedece a um esquema (XSD, DTD ou RELAX NG) que dita quais elementos podem aparecer, em que ordem e com que tipos. Isso exige o próprio arquivo de esquema e um processador dedicado; nenhum navegador faz isso nativamente.

Ou seja: um arquivo pode formatar sem erro aqui e ainda ser recusado pelo sistema que o consome — essa recusa é problema de esquema, não de sintaxe.

Erros comuns e o que costumam significar

• “Extra content at the end of the document” — dois elementos raiz. Costuma acontecer quando alguém concatena várias respostas num arquivo só. Envolva tudo em um elemento pai.
• “EntityRef: expecting ';'” — um & solto no texto ou num atributo, tipicamente dentro de uma URL com parâmetros. Precisa ser escrito como &.
• “Opening and ending tag mismatch” — tag fechada fora de ordem, ou fechada com capitalização diferente. XML diferencia maiúsculas: <Item> e <item> são elementos diferentes.
• Erros de caractere inválido — um caractere de controle perdido ou um byte-order mark no meio do arquivo, comum em arquivos que passaram por várias codificações.

Namespaces, e por que prefixo não é nome

Namespace é onde o XML deixa de ser intuitivo. Um prefixo como soap: ou xsi: não é a identidade do elemento — é um apelido local que aponta para uma URI declarada em algum lugar acima com xmlns:. Dois documentos podem usar prefixos completamente diferentes para o mesmo namespace e serem idênticos para qualquer processador de XML.

Isso tem uma consequência prática com que se esbarra o tempo todo: você não pode procurar <soap:Body> numa resposta SOAP de forma confiável, porque quem envia é livre para chamar de <env:Body>. O que identifica o elemento é o par (URI do namespace, nome local), não o texto do prefixo.

O namespace padrão é mais rígido do que parece. Declarar xmlns="http://exemplo.com/ns" num elemento coloca esse elemento e todo descendente sem prefixo naquele namespace — mas nunca vale para atributo. Atributo sem prefixo está sempre em namespace nenhum, seja qual for o padrão. Esse é o bug de namespace mais comum que existe, e ele produz expressões XPath que não casam com nada parecendo obviamente corretas.

A formatação aqui preserva as declarações exatamente onde estavam. Mover um xmlns para a raiz para organizar mudaria quais elementos ele cobre, então nunca fazemos isso.

CDATA, entidades e o espaço que importa de verdade

Uma seção CDATA diz ao parser para tratar tudo que está dentro como texto literal. Ela existe para você embutir marcação — um fragmento de HTML, um trecho de código, um payload JSON — sem escapar cada sinal de menor. Dentro de CDATA, nenhuma entidade é expandida e nenhuma tag é reconhecida.

Existe exatamente uma coisa que ela não pode conter: a sequência ]]>, que encerra a seção. Não há escape para isso. A única saída é dividir o conteúdo em duas seções CDATA adjacentes no ponto do problema, o que é genuinamente desconfortável e é a razão de conteúdo muito aninhado normalmente ser escapado em vez disso.

Espaço em branco é a outra armadilha. O XML não tem regra geral de que espaço entre tags é insignificante — isso é convenção do esquema, não do formato. Indentar um documento é seguro para conteúdo só de elementos, mas acrescentar quebra de linha dentro de um nó de texto muda o valor daquele nó. Este formatador só acrescenta indentação entre elementos e não toca nos nós de texto, e é por isso que o documento formatado e o original são equivalentes para todo consumidor que respeite a mesma convenção.

As cinco entidades predefinidas são <, >, &, " e '. Todo o resto —   em especial, que as pessoas trazem do HTML — é indefinido em XML a menos que o documento declare, e é erro duro de parse, não aviso.

XML comparado a JSON e YAML

XML é verboso, e essa é a troca honesta. O que ele compra é expressividade que o JSON não tem: comentário sobrevive, um elemento carrega atributo e filho ao mesmo tempo, o mesmo nome de elemento se repete sem virar array, e conteúdo misto — texto com marcação no meio, do jeito que um documento realmente se lê — não tem equivalente limpo em JSON.

É por isso que o XML não desapareceu onde o assunto é documento: feed RSS e Atom, SVG, arquivos do Office e do OpenDocument, layout do Android, build do Maven, serviço SOAP, asserção SAML e a maior parte dos formatos de intercâmbio de governo e de banco são todos XML, e vão continuar sendo por muito tempo.