Validatore XML
Buona formazione e convalida con schema. Nulla viene caricato.
Tutto viene eseguito in questa scheda. Nulla di ciò che incolli viene caricato, registrato o inviato da qualche parte. Apri il pannello di rete e verifica.
Incolla un documento qui sopra e viene controllato mentre scrivi. Ogni problema è segnalato con la riga, la colonna e che cosa scrivere al suo posto, e tutti insieme invece di fermarsi al primo. Nulla viene caricato: il parser, il motore degli schemi e l’editor girano dentro questa scheda, e puoi verificarlo aprendo il pannello di rete del browser e guardandolo restare vuoto mentre lavori.
Quest’ultimo punto non è una frase pubblicitaria. Diversi strumenti ben posizionati su questa ricerca mandano il tuo documento a un server per controllarlo. Uno di essi ti chiede di spuntare una casella per confermare di aver capito che i tuoi dati vengono conservati sui loro server. Se stai facendo il debug di una envelope SOAP con dentro un token, o di un file di configurazione con una stringa di connessione, è un problema concreto ed è il motivo per cui esiste questo sito.
Il validatore esegue entrambi i controlli che XML definisce e li tiene distinti, perché rispondono a domande diverse e quasi tutti gli strumenti gratuiti li confondono.
Ben formato e valido non sono lo stesso controllo
Un documento è ben formato quando la sintassi è corretta: i tag sono chiusi e annidati correttamente, c’è esattamente un elemento radice, i caratteri speciali sono con escape e i valori degli attributi sono tra virgolette. Per questo non serve altro che il documento stesso, quindi il controllo parte automaticamente mentre scrivi.
Un documento è valido quando è ben formato e in più corrisponde a uno schema: gli elementi che devono esserci ci sono, nell’ordine giusto e con i tipi giusti. Qui serve un secondo file, un XSD o una DTD, quindi è un’azione separata che avvii di proposito.
La distinzione conta perché "XML valido" è quello che si dice intendendo l’una o l’altra cosa. Se un sistema ha rifiutato il tuo documento dicendo che non era valido, con ogni probabilità ha eseguito un controllo di schema, e la spunta verde di un controllo di buona formazione non ti dirà perché è fallito. Qui il pannello dei risultati dice sempre quale controllo ha eseguito.
- Ben formato ma non valido: <note><to>Alice</to></note> rispetto a uno schema che richiede anche <from>. La sintassi è perfetta; il contenuto è sbagliato.
- Valido ma non ben formato: impossibile. La validità include la buona formazione, ed è per questo che il controllo dello schema si rifiuta di partire finché la sintassi non è pulita.
Che cosa ti dicono davvero gli errori
Quello che manca in questa categoria non sono le funzioni, sono i messaggi di errore. I parser dei browser si fermano al primo problema e lo formulano per chi ha scritto il parser. Firefox segnala una e commerciale senza escape come "EntityRef: expecting ';'". libxml2 chiama la stessa cosa "xmlParseEntityRef: no name". Nessuno dei due nomina la e commerciale, l’escape, o la query string di una URL che quasi certamente l’ha causata.
Ogni diagnostica qui nomina il problema con le parole che useresti tu, indica la posizione esatta e propone la correzione. Cliccando sul segnaposto riga:colonna il cursore ci salta sopra. Quando un errore è abbastanza comune da meritarlo, c’è un collegamento a una pagina che ne spiega la causa, con il messaggio equivalente di altri sei parser, così da riconoscerlo la prossima volta che la tua build lo riporta con altre parole.
Documenti grandi, e documenti ostili
L’analisi gira in un Web Worker, quindi l’interfaccia resta reattiva mentre un documento grande viene esaminato. Un file da 100 KB è controllato in circa 20 millisecondi, 1 MB in circa 110, e 10 MB in poco più di un secondo. Oltre i 20 MB lo strumento rifiuta: tutto vive nella memoria di questa scheda, e un documento così grande rende il browser inutilizzabile, non semplicemente lento.
XML ha forme di denial of service che JSON non ha, e qui sono limitate anziché date per improbabili. Un documento che dichiara entità annidate a espansione esponenziale, lo schema "billion laughs", viene rifiutato in circa due millisecondi, perché il costo dell’espansione è calcolato dalle dichiarazioni prima che un solo carattere venga espanso. La variante quadratica, una grossa entità richiamata migliaia di volte, ricade nello stesso budget. L’annidamento ha un tetto, i cicli fra entità vengono rilevati anziché percorsi, e le entità esterne sono segnalate ma mai scaricate.
I documenti che la gente incolla davvero qui
Un validatore è uno strumento generico, ma i documenti che gli arrivano non sono distribuiti in modo uniforme. Una manciata di forme concentra la gran parte del traffico, e ognuna fallisce a modo suo.
Nella maggior parte di questi casi validare e formattare sono la stessa operazione. Il file è illeggibile perché è arrivato minificato, o indentato da tre strumenti diversi uno dopo l'altro, e l'errore resta invisibile finché non viene impaginato come si deve. Il pulsante Formatta qui sopra lo riformatta sul posto, senza passare da un altro sito; il formattatore XML è la versione completa, con il controllo sulla larghezza dell'indentazione e su come trattare i commenti.
- Sitemap XML. Il validatore di sitemap controlla il protocollo sitemaps.org e non solo la sintassi: i tetti di 50.000 URL e 50 MB, il formato W3C Datetime che lastmod richiede davvero, e la regola per cui ogni URL deve stare sullo stesso host della sitemap. Una sitemap per Google può essere perfettamente ben formata e venire comunque rifiutata, e quasi sempre è una di quelle tre cose.
- SEPA e gli altri messaggi di pagamento ISO 20022. Una disposizione di addebito diretto pain.008 o un estratto conto camt.053 hanno senso solo se confrontati con il loro XSD pubblicato, quindi quelli vanno nel validatore XSD con lo schema incollato accanto. È la categoria in cui la garanzia di non caricare nulla smette di essere un'astrazione: un file di prova porta comunque IBAN e identificativi del creditore reali.
- Configurazione dei server di gioco. DayZ, Arma e i server costruiti sullo stesso motore leggono types.xml, cfgspawnabletypes.xml ed events.xml all'avvio, e un solo elemento <type> non chiuso ferma il server con un messaggio che non nomina né il file né la riga. Incollare il file qui te li dà entrambi, insieme alla profondità di annidamento nel punto in cui si è rotto.
- Envelope SOAP e le risposte che ne tornano. Sono i documenti con più probabilità di contenere un token bearer o una stringa di connessione, ed è il motivo per cui il formattatore SOAP esiste come pagina a sé.
- Feed RSS e Atom, dove l'errore tipico è una e commerciale grezza dentro una URL contenuta in un titolo, e il lettore di feed si limita a dire che il feed è rotto.
Se sei abituato a validare in Notepad++
Notepad++ non ha alcun supporto XML proprio. Il plugin XML Tools lo aggiunge, e quel plugin è un binding a libxml2, cioè lo stesso motore che questo sito compila in WebAssembly. I controlli di fondo quindi concordano. Ciò che cambia è tutto quello che ci sta intorno.
Il plugin segnala un errore in una finestra di dialogo invece che sul documento, quindi leggi un numero di riga e poi vai a cercarla. È solo per Windows, perché lo è Notepad++, e la build del plugin deve corrispondere all'architettura del tuo editor: è il motivo abituale per cui un'installazione appena fatta ha il menu in grigio. La validazione con schema c'è, ma si aspetta che l'XSD sia raggiungibile dalla dichiarazione del documento stesso, cosa che un frammento estratto da un file più grande quasi mai ha.
Nessuno dei due strumenti sostituisce l'altro, e la divisione onesta riguarda dove si trova già il documento. Se è un file su disco, sei comunque nell'editor e non hai rete, il plugin è la strada più breve. Se è arrivato in un ticket di assistenza, negli appunti o in una scheda del browser, se vuoi tutti gli errori in una passata invece di uno per dialogo, o se non sei su Windows, caricare una pagina è più veloce che installare un plugin. Lo stesso vale per lo schema: incollare un XSD nel secondo riquadro qui non richiede nessuna dichiarazione dentro il documento.
Farlo da codice
Lo stesso controllo nei linguaggi che consumano più XML. Ognuno è nella forma sicura: le impostazioni predefinite di parecchie di queste librerie risolvono volentieri le entità esterne, che è la vulnerabilità XXE, quindi i flag qui sotto sono il punto e non un contorno.
// 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.Ognuno di questi esempi disattiva qualcosa. Non è un dettaglio: il comportamento non sicuro è quello predefinito in Java, in PHP prima della 8.0 e nella libreria standard di Python, ed è su quei valori predefiniti che gira la maggior parte del parsing XML in produzione.
Domande frequenti
Il mio XML viene caricato da qualche parte?
No. Il parser, il formattatore e il motore degli schemi sono JavaScript e WebAssembly che girano in questa scheda. Non esiste alcun componente lato server a cui mandare qualcosa.
Non devi crederci sulla parola. Apri gli strumenti per sviluppatori del browser, passa alla scheda Rete, incolla un documento e convalidalo. Vedrai le risorse della pagina caricarsi una volta e poi più nulla. Il sito non ha analytics con accesso all’editor, né script di terze parti, né un servizio di segnalazione errori.
Qual è la differenza fra ben formato e valido?
Ben formato significa che la sintassi è corretta: tag chiusi, annidamento corretto, un solo elemento radice, caratteri speciali con escape, valori degli attributi tra virgolette. Valido significa ben formato e anche conforme a uno schema, cioè un file separato che descrive quali elementi sono ammessi e dove.
Un documento può essere ben formato senza essere valido. Non può essere valido senza essere ben formato. Quando un sistema dice che il tuo XML è "non valido", di solito ha eseguito un controllo di schema, quindi un controllo di sola sintassi non spiegherà il fallimento.
Può convalidare con un XSD?
Sì, ed è insolito farlo senza un server. I browser non hanno un validatore di schemi integrato, quindi gli strumenti gratuiti o saltano la convalida con schema o caricano i tuoi file. Questo sito esegue libxml2 compilato in WebAssembly, il che dà convalida XSD 1.0 e DTD interamente nel browser.
Il motore pesa circa 480 KB compresso, quindi viene scaricato solo quando chiedi davvero un controllo di schema, non al caricamento della pagina. Da notare che libxml2 implementa solo XSD 1.0: gli schemi che usano funzioni di XSD 1.1 come xs:assert non si compilano, e lo strumento lo dice invece di restituire un oscuro errore di struttura.
Perché segnala più errori quando altri validatori ne segnalano uno?
Perché un errore è raramente tutta la storia, e perché un parser che si ferma al primo problema ti fa correggere un documento grande un viaggio alla volta.
Lo scanner si riprende dopo un errore e prosegue, così un solo passaggio trova l’attributo senza virgolette alla riga 4, la e commerciale nuda alla riga 12 e il tag non chiuso in fondo. Una cautela è d’obbligo: un errore iniziale come un tag non chiuso può far sembrare sbagliato tutto ciò che segue. Correggi i primi e ricontrolla, invece di risalire la lista dal fondo.
Quanto può essere grande il file?
Fino a 20 MB. Un documento da 10 MB viene analizzato in poco più di un secondo, e l’analisi gira in un Web Worker, quindi la pagina non si blocca mentre lavora.
Il limite è deciso, non scoperto a forza di crash. Tutto resta nella memoria di questa scheda, e oltre i 20 MB circa l’albero di parsing può occupare diverse centinaia di megabyte. Per file davvero grandi lo strumento giusto è un parser in streaming sulla tua macchina: xmllint, iterparse di Python o un parser SAX, nessuno dei quali costruisce l’albero intero.
Gestisce correttamente i namespace?
Sì. I prefissi sono risolti rispetto alle dichiarazioni nello scope, e usare un prefisso non associato viene segnalato come errore, con la dichiarazione da aggiungere. È un problema frequente quando si copia un frammento da un documento più grande e la dichiarazione xmlns resta sull’elemento radice originale.
L’editor smorza anche il prefisso rispetto al nome locale, così soap:Body si legge come Body con un’impalcatura attorno. È un dettaglio, ma rende una envelope SOAP molto annidata decisamente più facile da scorrere.
È sicuro incollare un documento che contiene credenziali?
Più sicuro qui che in qualsiasi strumento che lo carichi, perché non viene trasmesso nulla. Il documento non esce dalla scheda, non viene registrato e non finisce in nessuna segnalazione di errore.
Una precisazione va fatta: quello che scrivi viene salvato nel localStorage di questo browser, così un ricaricamento non ti fa perdere il lavoro. Resta sulla tua macchina e non viene mai trasmesso, ma significa che il documento persiste finché non lo cancelli. Il pulsante Svuota lo rimuove subito, e i documenti oltre i 300 KB non vengono salvati affatto.
Posso validare una sitemap XML con questo strumento?
Sì, e per una sitemap la pagina dedicata del validatore di sitemap è quella giusta. Questa controlla che il documento sia XML ben formato, il che è necessario ma non sufficiente: una sitemap che Google rifiuta di solito è ben formata e sta violando una regola del protocollo.
Quella pagina controlla le regole vere e proprie. I limiti di 50.000 URL e 50 MB non compressi, lo spazio dei nomi di sitemaps.org, lastmod in formato W3C Datetime invece di quello che ha prodotto il tuo framework, e il requisito che ogni URL stia sullo stesso host del file sitemap. Segnala anche gli elementi che Google ha dichiarato pubblicamente di ignorare, così smetti di regolare valori che non fanno nulla.
Gestisce SEPA e file ISO 20022 come pain.008 o camt.053?
Sì. Un messaggio ISO 20022 è normale XML con dietro uno schema grande, quindi incolla il messaggio nel validatore XSD e il corrispondente schema pain.008 o camt.053 nel secondo riquadro. La validazione gira contro quello schema nel tuo browser, senza account da creare e senza altri tetti oltre al limite generale di 20 MB.
È il caso in cui conta di più dove finisce il documento. Un file di pagamenti anche solo di prova porta comunque IBAN, identificativi del creditore e riferimenti di mandato reali, e diversi validatori gratuiti che accettano file ISO 20022 li caricano prima su un server. Qui non viene trasmesso nulla, e puoi confermarlo nella scheda Rete mentre lavori. Un limite da sapere: il motore implementa XSD 1.0, che è la versione in cui sono scritti gli schemi ISO 20022 pubblicati.
Posso usarlo per i file server di DayZ come types.xml?
Sì, e si adatta bene. I file di economia di DayZ (types.xml, cfgspawnabletypes.xml, events.xml e cfgeventspawns.xml) sono XML normale, e il server si rifiuta di avviarsi quando uno di questi è malformato. Il messaggio che stampa di solito non nomina né il file né la posizione, ed è ciò che trasforma una parentesi angolare mancante in una serata intera.
Incolla il file qui e ogni errore di sintassi viene segnalato in un colpo solo con riga e colonna, così un file modificato a mano nel corso di più sessioni si sistema in una passata invece che un riavvio alla volta. Due avvertenze da dire: non esiste un XSD pubblicato per questi file, quindi qui si controlla che l'XML sia ben formato e non che un valore di attributo sia fra quelli che il gioco accetta; e un valore di nominal o lifetime che è XML legale ma sbagliato per la tua economia del loot passerà qui e continuerà a comportarsi male in gioco.
Come si confronta con il validatore XML di Notepad++?
Usano lo stesso motore. Notepad++ da solo non offre alcun supporto XML; lo fornisce il plugin XML Tools, costruito su libxml2, cioè quello che questo sito esegue come WebAssembly. Quindi i due concordano sul fatto che un documento sia ben formato.
Le differenze sono pratiche. Il plugin è solo per Windows e la sua build deve corrispondere all'architettura del tuo editor, ed è per questo che un'installazione appena fatta ha spesso il menu in grigio. Segnala gli errori in una finestra di dialogo invece che sul documento, e la sua validazione con schema si aspetta che l'XSD sia dichiarato dentro il file, cosa che un frammento copiato quasi mai ha. Questa pagina accetta un XSD incollato in un secondo riquadro senza bisogno di dichiarazioni, segnala tutti gli errori di sintassi in una passata e funziona ovunque ci sia un browser. Se il file è già aperto in Notepad++ e sei offline, usa il plugin: è il caso in cui vince lui.
Questo validatore XML è gratuito? Serve registrarsi?
È gratuito e non c'è nessun account, nessuna richiesta di email, nessuna quota giornaliera e nessun piano a pagamento che trattenga la validazione con schema. Niente sul sito è bloccato.
È più facile da offrire di quanto sembri, perché l'economia è diversa. Un validatore che gira su un server paga CPU per ogni documento che controlli, ed è il motivo per cui quegli strumenti misurano l'uso, limitano la dimensione dei file o ti chiedono di registrarti. Qui l'analisi avviene sulla tua macchina, quindi un file da 10 MB non costa nulla al sito e non c'è ragione di contare quanti ne validi.
Posso validare XML online senza installare nulla?
Questa pagina è esattamente questo. Funziona in qualsiasi browser attuale su Windows, macOS, Linux, Android o iOS, senza nulla da installare, senza estensioni e senza account.
Vale la pena fare una distinzione, perché la parola «online» lì fa due lavori. La maggior parte dei validatori online lo è in entrambi i sensi: la pagina sta sul web e il tuo documento viene mandato al loro server per essere controllato. Questo lo è solo nel primo senso. La pagina viene consegnata dalla rete una volta, e da lì in poi il parser, il motore di schemi e l'editor girano localmente nella scheda. Caricala una volta e continua a funzionare con la rete spenta.
Questo è un validatore e formattatore XML, o servono due strumenti?
Ci sono entrambi. Il pulsante Formatta nella riga qui sopra riformatta sul posto quello che c'è nell'editor, così la sequenza abituale di incollare qualcosa di illeggibile, impaginarlo e poi trovare l'errore avviene senza spostarsi fra siti.
Il formattatore XML è la versione completa per quando formattare è il lavoro e non un passaggio verso altro: indentare con due spazi, quattro spazi o tabulazioni, decidere che fine fanno i commenti, e minificare nella direzione opposta. Anche lì gira la validazione, perché un documento deve essere ben formato prima di poter essere riformattato.
Può abbellire l'XML oltre che validarlo?
Sì. Abbellire, stampare in bella forma e formattare sono la stessa operazione: il documento viene re-indentato perché l'annidamento diventi visibile, ed è di solito ciò che rende individuabile un errore.
Un dettaglio vale la pena conoscerlo, perché la maggior parte degli abbellitori lo sbaglia. Lo spazio bianco fra due elementi è insignificante e si può cambiare senza rischi, ma lo spazio bianco dentro un elemento che contiene anche testo è un dato, e re-indentarlo cambia ciò che il documento significa. Un abbellitore che spezza <p>Ciao <b>tu</b></p> su tre righe indentate ha alterato il contenuto, non solo la sua presentazione. Questo lascia il contenuto misto esattamente come lo ha trovato, ed è il motivo per cui parti di un documento abbellito restano su una riga sola.
Qual è il miglior validatore XML?
Dipende da dove si trova già il documento e da che cosa va controllato, e una risposta onesta comprende i casi in cui non è questo.
Per un documento che puoi incollare, uno strumento nel browser è la strada più breve, e le tre cose da confrontare sono se fa validazione con schema, se per farlo carica il tuo file, e se puoi agire sugli errori che segnala. Per un file già aperto in un progetto, il tuo editor è più a portata di mano: VS Code con l'estensione XML di Red Hat, o IntelliJ, validano contro uno schema mentre scrivi. Per file troppo grandi da tenere in memoria, o per un passaggio di build, xmllint è lo strumento giusto ed è già installato sulla maggior parte delle macchine. Per una pipeline di CI, il validatore che ci sta è quello del linguaggio in cui è scritta.
Questo è fatto per il caso intermedio: validazione con schema senza server, tutti gli errori di sintassi in una passata invece del solo primo, e messaggi scritti per chi li legge e non per chi ha scritto il parser.