Validador XML
Boa formação e validação por esquema. Nada é enviado.
Tudo roda nesta aba. Nada do que você colar é enviado, registrado ou transmitido para lugar nenhum. Abra o painel de rede e confira.
Cole um documento acima e ele é verificado enquanto você digita. Cada problema é informado com a linha, a coluna e o que escrever no lugar, e todos de uma vez em vez de parar no primeiro. Nada é enviado: o analisador, o motor de esquemas e o editor rodam dentro desta aba, o que você pode confirmar abrindo o painel de rede do navegador e vendo que ele continua vazio enquanto você trabalha.
Esse último ponto não é frase de marketing. Várias das ferramentas bem posicionadas nesta busca mandam o seu documento para um servidor para verificá-lo. Uma delas pede que você marque uma caixa confirmando que entendeu que seus dados ficam armazenados nos servidores deles e podem ser retidos. Se você está depurando um envelope SOAP com um token, ou um arquivo de configuração com uma string de conexão, isso é um problema real e é a razão de este site existir.
O validador faz as duas verificações que o XML define e as mantém separadas, porque respondem a perguntas diferentes e quase toda ferramenta gratuita as confunde.
Bem formado e válido não são a mesma verificação
Um documento é bem formado quando a sintaxe está correta: as tags são fechadas e aninhadas corretamente, existe exatamente um elemento raiz, os caracteres especiais estão escapados e os valores de atributo estão entre aspas. Isso não exige nada além do próprio documento, então roda automaticamente enquanto você digita.
Um documento é válido quando é bem formado e também corresponde a um esquema: os elementos que devem estar lá estão, na ordem certa e com os tipos certos. Isso exige um segundo arquivo, um XSD ou uma DTD, então é uma ação separada que você dispara de propósito.
A distinção importa porque "XML válido" é o que as pessoas dizem querendo dizer qualquer uma das duas coisas. Se um sistema rejeitou seu documento dizendo que era inválido, provavelmente rodou uma verificação de esquema, e um sinal verde de um verificador de boa formação não vai dizer por que falhou. O painel de resultado aqui sempre diz qual verificação foi feita.
- Bem formado mas não válido: <note><to>Alice</to></note> diante de um esquema que também exige <from>. A sintaxe está perfeita; o conteúdo está errado.
- Válido mas não bem formado: impossível. A validade inclui a boa formação, e por isso a verificação de esquema se recusa a rodar enquanto a sintaxe não estiver limpa.
O que os erros realmente dizem
A lacuna desta categoria não está nos recursos, está nas mensagens de erro. Os analisadores dos navegadores param no primeiro problema e o descrevem para quem escreveu o analisador. O Firefox reporta um "e comercial" não escapado como "EntityRef: expecting ';'". O libxml2 chama a mesma coisa de "xmlParseEntityRef: no name". Nenhum menciona o caractere &, o escape, nem a query string de URL que quase certamente causou tudo.
Cada diagnóstico aqui nomeia a falha com as palavras que você usaria, dá a posição exata e sugere a correção. Clicar no marcador linha:coluna leva o cursor até lá. Quando um erro é comum o bastante para merecer, há um link para uma página que explica o que o causa, com a mensagem equivalente de outros seis analisadores, para você reconhecê-lo da próxima vez que o seu build reportá-lo com outras palavras.
Documentos grandes e documentos hostis
A análise roda em um Web Worker, então a interface continua respondendo enquanto um documento grande é examinado. Um arquivo de 100 KB é verificado em cerca de 20 milissegundos, 1 MB em uns 110, e 10 MB em pouco mais de um segundo. Acima de 20 MB a ferramenta recusa: tudo vive na memória desta aba, e um documento desse tamanho deixa o navegador inutilizável, não apenas lento.
O XML tem formatos de negação de serviço que o JSON não tem, e aqui eles são limitados em vez de ignorados. Um documento que declara entidades aninhadas com expansão exponencial, o padrão "billion laughs", é rejeitado em cerca de dois milissegundos, porque o custo da expansão é calculado a partir das declarações antes de um único caractere ser expandido. A variante quadrática, uma entidade grande referenciada milhares de vezes, cai no mesmo orçamento. O aninhamento tem teto, ciclos de entidades são detectados em vez de percorridos, e entidades externas são reportadas mas nunca buscadas.
Os documentos que as pessoas realmente colam aqui
Um validador é uma ferramenta de uso geral, mas os documentos que chegam a ele não se distribuem de forma uniforme. Um punhado de formatos concentra a maior parte do tráfego, e cada um falha à sua maneira característica.
Na maioria desses casos, validar e formatar são a mesma tarefa. O ficheiro está ilegível porque chegou minificado, ou indentado por três ferramentas diferentes uma a seguir à outra, e o erro fica invisível até estar apresentado como deve ser. O botão Formatar acima reformata no sítio, sem passar por outro site; o formatador XML é a versão completa, com controlo sobre a largura da indentação e sobre o tratamento dos comentários.
- Sitemaps XML. O validador de sitemaps verifica o protocolo sitemaps.org e não apenas a sintaxe: os tetos de 50.000 URL e 50 MB, o formato W3C Datetime que lastmod realmente exige, e a regra de que cada URL tem de estar no mesmo host que o sitemap. Um sitemap para o Google pode estar perfeitamente bem formado e ainda assim ser rejeitado, e é quase sempre uma dessas três coisas.
- SEPA e outras mensagens de pagamento ISO 20022. Uma instrução de débito direto pain.008 ou um extrato camt.053 só fazem sentido confrontados com o XSD publicado, por isso esses vão para o validador XSD com o esquema colado ao lado. É a categoria em que a garantia de nada ser enviado deixa de ser uma abstração: um ficheiro de teste continua a levar IBAN e identificadores de credor reais.
- Configuração de servidores de jogo. DayZ, Arma e os servidores construídos sobre o mesmo motor leem types.xml, cfgspawnabletypes.xml e events.xml no arranque, e um único elemento <type> por fechar para o servidor com uma mensagem que não nomeia nem o ficheiro nem a linha. Colar o ficheiro aqui dá-te os dois, além da profundidade de aninhamento no ponto em que partiu.
- Envelopes SOAP e as respostas que voltam deles. São os documentos com maior probabilidade de transportar um token bearer ou uma string de ligação, e é a razão pela qual o formatador SOAP existe como página separada.
- Feeds RSS e Atom, onde a falha habitual é um E comercial solto dentro de um URL num título, e o leitor de feeds limita-se a dizer que o feed está partido.
Se estás habituado a validar no Notepad++
O Notepad++ não traz suporte XML próprio. O plugin XML Tools acrescenta-o, e esse plugin é uma ligação ao libxml2, que é o mesmo motor que este site compila para WebAssembly. As verificações de fundo, portanto, concordam. O que difere é tudo o que está à volta delas.
O plugin reporta uma falha numa caixa de diálogo em vez de sobre o documento, por isso lês um número de linha e depois vais procurá-la. É só para Windows, porque o Notepad++ também é, e a build do plugin tem de corresponder à arquitetura do teu editor, que é a razão habitual para uma instalação acabada de fazer ter o menu a cinzento. A validação com esquema existe, mas espera que o XSD seja alcançável a partir da declaração do próprio documento, coisa que um fragmento retirado de um ficheiro maior quase nunca tem.
Nenhuma das ferramentas substitui a outra, e a divisão honesta tem a ver com onde já está o documento. Se é um ficheiro em disco, já estás no editor e não tens rede, o plugin é o caminho mais curto. Se chegou num ticket de suporte, na área de transferência ou num separador do navegador, se queres todos os erros numa passagem em vez de um por diálogo, ou se não estás em Windows, carregar uma página é mais rápido do que instalar um plugin. O mesmo vale para o caso do esquema: colar um XSD no segundo painel aqui não precisa de qualquer declaração dentro do documento.
Fazendo isso em código
A mesma verificação nas linguagens que mais consomem XML. Cada exemplo está na forma segura: os padrões de várias dessas bibliotecas resolvem entidades externas de bom grado, que é a vulnerabilidade XXE, então as flags abaixo são o ponto principal e não enfeite.
// DOMParser does not throw on malformed input. It returns a document
// containing a <parsererror> element instead, which is why so much code
// silently accepts broken XML.
function parseXml(source) {
const doc = new DOMParser().parseFromString(source, 'application/xml');
const error = doc.querySelector('parsererror');
if (error) {
throw new Error(error.textContent.trim());
}
return doc;
}
// Browsers do not resolve external entities, so XXE is not reachable here.
// Internal entity expansion is, so cap the input size before parsing.# The standard library is not safe against entity-expansion attacks.
# defusedxml is the maintained answer and is a drop-in replacement.
from defusedxml.ElementTree import fromstring, ParseError
try:
root = fromstring(source)
except ParseError as e:
# e.position is a (line, column) tuple, 1-based line, 0-based column
line, column = e.position
raise SystemExit(f"XML error at line {line}, column {column + 1}: {e}")
# With lxml, disable resolution explicitly:
# parser = etree.XMLParser(resolve_entities=False, no_network=True,
# huge_tree=False, load_dtd=False)
# root = etree.fromstring(source.encode(), parser)import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
// FEATURE_SECURE_PROCESSING caps entity expansion. The three
// disallow-doctype settings close XXE. None of this is the default.
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
factory.setXIncludeAware(false);
factory.setExpandEntityReferences(false);
var builder = factory.newDocumentBuilder();
try {
var document = builder.parse(new java.io.ByteArrayInputStream(bytes));
} catch (org.xml.sax.SAXParseException e) {
System.err.printf("XML error at line %d, column %d: %s%n",
e.getLineNumber(), e.getColumnNumber(), e.getMessage());
}using System.Xml;
var settings = new XmlReaderSettings
{
// Null resolver means external DTDs and entities are never fetched.
DtdProcessing = DtdProcessing.Prohibit,
XmlResolver = null,
MaxCharactersFromEntities = 1024 * 1024,
MaxCharactersInDocument = 20L * 1024 * 1024,
};
try
{
using var reader = XmlReader.Create(new StringReader(source), settings);
var document = new XmlDocument { XmlResolver = null };
document.Load(reader);
}
catch (XmlException e)
{
Console.Error.WriteLine(
$"XML error at line {e.LineNumber}, column {e.LinePosition}: {e.Message}");
}<?php
// libxml_disable_entity_loader was deprecated in PHP 8.0 because external
// entity loading became off by default. On PHP 7 you still need it.
libxml_use_internal_errors(true);
$doc = new DOMDocument();
$loaded = $doc->loadXML($source, LIBXML_NONET | LIBXML_NOENT & ~LIBXML_NOENT);
if (!$loaded) {
foreach (libxml_get_errors() as $error) {
fprintf(
STDERR,
"XML error at line %d, column %d: %s\n",
$error->line,
$error->column,
trim($error->message)
);
}
libxml_clear_errors();
exit(1);
}# xmllint is part of libxml2 and is almost certainly already installed.
# --nonet stops it fetching a DTD referenced by the document.
xmllint --noout --nonet document.xml
# Validate against a schema:
xmllint --noout --nonet --schema schema.xsd document.xml
xmllint --noout --nonet --valid document.xml # against its own DTD
# Exit status is 0 when valid. Note that xmllint's exit code does not
# always reflect namespace errors, so check the output too.Cada um destes exemplos desliga alguma coisa. Isso não é acidente: o comportamento inseguro é o padrão em Java, no PHP anterior ao 8.0 e na biblioteca padrão do Python, e é sobre esses padrões que roda a maior parte da análise de XML em produção.
Perguntas frequentes
Meu XML é enviado para algum lugar?
Não. O analisador, o formatador e o motor de esquemas são JavaScript e WebAssembly rodando nesta aba. Não existe componente de servidor para o qual mandar qualquer coisa.
Você não precisa acreditar. Abra as ferramentas de desenvolvedor do navegador, vá até a aba Rede, cole um documento e valide. Você verá os recursos da própria página carregarem uma vez e depois mais nada. O site não tem analytics com acesso ao editor, nem scripts de terceiros, nem serviço de relatório de erros.
Qual a diferença entre bem formado e válido?
Bem formado significa que a sintaxe está correta: tags fechadas, aninhamento certo, um elemento raiz, caracteres especiais escapados, valores de atributo entre aspas. Válido significa bem formado e também em conformidade com um esquema, que é um arquivo separado descrevendo quais elementos são permitidos e onde.
Um documento pode ser bem formado sem ser válido. Não pode ser válido sem ser bem formado. Quando um sistema diz que seu XML é "inválido", normalmente rodou uma verificação de esquema, então um verificador de sintaxe sozinho não explica a falha.
Ele consegue validar contra um XSD?
Consegue, e é raro fazer isso sem servidor. Navegadores não têm validador de esquema nativo, então as ferramentas gratuitas ou pulam a validação de esquema ou enviam seus arquivos. Este site roda o libxml2 compilado para WebAssembly, o que dá validação XSD 1.0 e DTD inteiramente no navegador.
O motor tem cerca de 480 KB comprimido, então só é baixado quando você realmente pede uma verificação de esquema, não ao carregar a página. Vale notar que o libxml2 implementa apenas XSD 1.0: esquemas que usam recursos do XSD 1.1, como xs:assert, não compilam, e a ferramenta diz isso em vez de devolver um erro estrutural confuso.
Por que ele reporta vários erros quando outros validadores reportam um?
Porque um erro raramente é a história toda, e porque um analisador que para no primeiro problema faz você corrigir um documento grande uma ida e volta por vez.
O scanner se recupera depois de uma falha e continua, então uma única passagem encontra o atributo sem aspas na linha 4, o & solto na linha 12 e a tag não fechada no fim. Uma cautela é justa: um erro logo no começo, como uma tag não fechada, pode fazer tudo depois dele parecer errado. Corrija os primeiros e verifique de novo, em vez de trabalhar a lista de baixo para cima.
Qual o tamanho máximo de arquivo?
Até 20 MB. Um documento de 10 MB é analisado em pouco mais de um segundo, e a análise roda em um Web Worker, então a página não congela enquanto isso.
O limite é deliberado, não descoberto por travamentos. Tudo fica na memória desta aba, e além de uns 20 MB a árvore de análise pode consumir várias centenas de megabytes. Para arquivos realmente grandes, a ferramenta certa é um analisador em streaming na sua própria máquina: xmllint, o iterparse do Python ou um analisador SAX, nenhum dos quais monta a árvore inteira.
Ele trata namespaces corretamente?
Sim. Os prefixos são resolvidos contra as declarações em escopo, e usar um prefixo que não foi vinculado é reportado como erro, junto com a declaração que falta. É uma falha comum quando um trecho é copiado de um documento maior e a declaração xmlns fica para trás, no elemento raiz original.
O editor também deixa o prefixo mais apagado que o nome local, então soap:Body se lê como Body com um andaime em volta. É um detalhe pequeno, mas deixa um envelope SOAP bem aninhado bastante mais fácil de percorrer com os olhos.
É seguro colar um documento que contém credenciais?
Mais seguro aqui do que em qualquer ferramenta que o envie, porque nada é transmitido. O documento não sai da aba, não é registrado e não entra em nenhum relatório de erro.
Uma ressalva que vale dizer: sua entrada é salva no localStorage deste navegador para que um recarregamento não perca o trabalho. Isso é local à sua máquina e nunca é transmitido, mas significa que o documento persiste até você limpá-lo. O botão Limpar remove na hora, e documentos acima de 300 KB não são guardados de forma alguma.
Posso validar um sitemap XML com isto?
Sim, e para um sitemap a página dedicada do validador de sitemaps é a melhor. Esta verifica que o documento é XML bem formado, o que é necessário mas não suficiente: um sitemap que o Google rejeita costuma estar bem formado e a violar antes uma regra do protocolo.
Essa página verifica as regras em si. Os limites de 50.000 URL e 50 MB não comprimidos, o espaço de nomes do sitemaps.org, lastmod em formato W3C Datetime em vez do que a tua framework emitiu, e a exigência de que cada URL esteja no mesmo host que o ficheiro de sitemap. Assinala também os elementos que o Google disse publicamente que ignora, para deixares de afinar valores que não fazem nada.
Lida com SEPA e ficheiros ISO 20022 como pain.008 ou camt.053?
Sim. Uma mensagem ISO 20022 é XML vulgar com um esquema grande por trás, por isso cola a mensagem no validador XSD e o esquema pain.008 ou camt.053 correspondente no segundo painel. A validação corre contra esse esquema no teu navegador, sem conta para criar e sem outro teto além do limite geral de 20 MB.
É o caso em que mais importa para onde vai o documento. Um ficheiro de pagamentos que é só de teste continua a levar IBAN, identificadores de credor e referências de mandato reais, e vários validadores gratuitos que aceitam ficheiros ISO 20022 enviam-nos primeiro para um servidor. Aqui nada é transmitido, e podes confirmá-lo no separador Rede enquanto trabalhas. Um limite a saber: o motor implementa XSD 1.0, que é a versão em que os esquemas ISO 20022 publicados estão escritos.
Posso usá-lo para ficheiros de servidor do DayZ como types.xml?
Sim, e assenta-lhe bem. Os ficheiros de economia do DayZ (types.xml, cfgspawnabletypes.xml, events.xml e cfgeventspawns.xml) são XML simples, e o servidor recusa arrancar quando um deles está malformado. A mensagem que imprime normalmente não nomeia nem o ficheiro nem a posição, que é o que transforma um sinal de maior em falta numa noite inteira.
Cola o ficheiro aqui e cada erro de sintaxe é reportado de uma vez com linha e coluna, por isso um ficheiro editado à mão ao longo de várias sessões fica resolvido numa passagem em vez de um reinício de cada vez. Duas ressalvas que vale a pena dizer: não há XSD publicado para estes ficheiros, por isso isto verifica que o XML está bem formado e não que um valor de atributo é dos que o jogo aceita; e um valor de nominal ou lifetime que é XML legal mas errado para a tua economia de loot passa aqui e continua a comportar-se mal no jogo.
Como se compara isto com o validador XML do Notepad++?
Usam o mesmo motor. O Notepad++ não oferece suporte XML por si só; o plugin XML Tools fornece-o e está construído sobre libxml2, que é o que este site executa como WebAssembly. Portanto os dois concordam sobre se um documento está bem formado.
As diferenças são práticas. O plugin é só para Windows e a sua build tem de corresponder à arquitetura do teu editor, e é por isso que uma instalação acabada de fazer costuma ter o menu a cinzento. Reporta os erros numa caixa de diálogo em vez de sobre o documento, e a sua validação com esquema espera que o XSD esteja declarado dentro do ficheiro, coisa que um fragmento copiado quase nunca tem. Esta página aceita um XSD colado num segundo painel sem precisar de declaração, reporta todos os erros de sintaxe numa passagem, e funciona em qualquer sítio onde haja navegador. Se o ficheiro já está aberto no Notepad++ e estás offline, usa o plugin; esse é o caso que ele ganha.
Este validador XML é gratuito? É preciso registo?
É gratuito e não há conta, nem pedido de email, nem quota diária, nem um plano pago a reter a validação com esquema. Nada no site está bloqueado.
Isso é mais fácil de oferecer do que parece, porque a economia é diferente. Um validador que corre num servidor paga CPU por cada documento que verificas, e é por isso que essas ferramentas medem o uso, limitam o tamanho dos ficheiros ou te pedem registo. Aqui a análise acontece na tua máquina, por isso um ficheiro de 10 MB não custa nada ao site e não há razão para contar quantos validas.
Posso validar XML online sem instalar nada?
É exatamente isso que esta página é. Funciona em qualquer navegador atual em Windows, macOS, Linux, Android ou iOS, sem nada para instalar, sem extensão e sem conta.
Vale a pena fazer uma distinção, porque a palavra online faz ali dois trabalhos. A maioria dos validadores online é-o nos dois sentidos: a página está na web e o teu documento é enviado para o servidor deles para ser verificado. Este só o é no primeiro sentido. A página é entregue pela rede uma vez e, a partir daí, o analisador, o motor de esquemas e o editor correm localmente no separador. Carrega-a uma vez e continua a funcionar com a rede desligada.
Isto é um validador e formatador XML, ou preciso de duas ferramentas?
Estão os dois aqui. O botão Formatar na linha acima reformata no sítio o que estiver no editor, por isso a sequência habitual de colar algo ilegível, apresentá-lo bem e só então encontrar o erro acontece sem saltar entre sites.
O formatador XML é a versão completa para quando formatar é o trabalho e não um passo a caminho de outra coisa: indentar com dois espaços, quatro espaços ou tabulações, decidir o que acontece aos comentários, e minificar no sentido contrário. A validação também corre nessa página, porque um documento tem de estar bem formado antes sequer de poder ser reformatado.
Consegue embelezar o XML além de o validar?
Sim. Embelezar, imprimir com formatação e formatar são a mesma operação: o documento é reindentado para que o aninhamento fique visível, que é normalmente o que torna um erro localizável.
Há um detalhe que vale a pena saber, porque a maioria dos embelezadores erra nisto. O espaço em branco entre dois elementos é insignificante e pode ser alterado sem risco, mas o espaço em branco dentro de um elemento que também contém texto é dado, e reindentá-lo muda o que o documento significa. Um embelezador que parte <p>Olá <b>aí</b></p> em três linhas indentadas alterou o conteúdo, não apenas a sua apresentação. Este deixa o conteúdo misto exatamente como o encontrou, e é por isso que partes de um documento embelezado ficam numa única linha.
Qual é o melhor validador XML?
Depende de onde o documento já está e do que é preciso verificar, e uma resposta honesta inclui os casos em que não é este.
Para um documento que podes colar, uma ferramenta de navegador é o caminho mais curto, e as três coisas que vale a pena comparar são se faz validação com esquema, se envia o teu ficheiro para isso, e se consegues agir sobre os erros que reporta. Para um ficheiro já aberto num projeto, o teu editor está mais à mão: o VS Code com a extensão XML da Red Hat, ou o IntelliJ, validam contra um esquema enquanto escreves. Para ficheiros grandes demais para caberem em memória, ou para um passo de build, o xmllint é a ferramenta certa e já está instalado na maioria das máquinas. Para um pipeline de CI, o validador que ali pertence é o da linguagem em que o pipeline está escrito.
Este foi feito para o caso intermédio: validação com esquema sem servidor, todos os erros de sintaxe numa passagem em vez de apenas o primeiro, e mensagens escritas para quem as lê e não para quem escreveu o analisador.