Validateur XML
Bonne formation et validation par schéma. Rien n’est envoyé.
Tout s'exécute dans cet onglet. Rien de ce que vous collez n'est envoyé, journalisé ni transmis où que ce soit. Ouvrez votre panneau réseau et vérifiez.
Collez un document ci-dessus et il est vérifié à la frappe. Chaque problème est signalé avec la ligne, la colonne et ce qu’il faut écrire à la place, et tous d’un coup plutôt qu’en s’arrêtant au premier. Rien n’est envoyé : l’analyseur, le moteur de schéma et l’éditeur tournent tous dans cet onglet, ce que vous pouvez vérifier en ouvrant le panneau réseau de votre navigateur et en le regardant rester vide pendant que vous travaillez.
Ce dernier point n’est pas un argument commercial. Plusieurs des outils bien placés sur cette recherche envoient votre document à un serveur pour le vérifier. L’un d’eux vous demande de cocher une case confirmant que vous comprenez que vos données sont stockées sur leurs serveurs et peuvent y être conservées. Si vous déboguez une enveloppe SOAP qui transporte un jeton, ou un fichier de configuration contenant une chaîne de connexion, c’est un vrai problème, et c’est la raison d’être de ce site.
Le validateur effectue les deux contrôles que définit XML, et les garde distincts, parce qu’ils répondent à des questions différentes et que presque tous les outils gratuits les confondent.
Bien formé et valide ne sont pas le même contrôle
Un document est bien formé quand sa syntaxe est correcte : les balises sont fermées et correctement imbriquées, il y a exactement un élément racine, les caractères spéciaux sont échappés et les valeurs d’attribut sont entre guillemets. Cela ne demande rien d’autre que le document lui-même, et s’exécute donc automatiquement à la frappe.
Un document est valide quand il est bien formé et qu’il correspond en plus à un schéma : les éléments attendus sont présents, dans le bon ordre, avec les bons types. Cela demande un second fichier, un XSD ou une DTD, c’est donc une action distincte que vous déclenchez délibérément.
La distinction compte parce que « XML valide » est ce que l’on dit pour désigner l’une ou l’autre. Si un système a rejeté votre document en le déclarant invalide, il a probablement lancé un contrôle de schéma, et une coche verte d’un vérificateur de bonne formation ne vous dira pas pourquoi il a échoué. Ici, le panneau de résultat indique toujours quel contrôle a été effectué.
- Bien formé mais non valide : <note><to>Alice</to></note> face à un schéma qui exige aussi <from>. La syntaxe est parfaite ; le contenu est faux.
- Valide mais non bien formé : impossible. La validité inclut la bonne formation, et c’est pourquoi le contrôle de schéma refuse de s’exécuter tant que la syntaxe n’est pas propre.
Ce que les erreurs vous disent réellement
Ce qui manque dans cette catégorie, ce ne sont pas les fonctionnalités, ce sont les messages d’erreur. Les analyseurs des navigateurs s’arrêtent au premier problème et le formulent pour celui qui a écrit l’analyseur. Firefox signale une esperluette non échappée par « EntityRef: expecting ';' ». libxml2 appelle la même chose « xmlParseEntityRef: no name ». Aucun ne parle d’esperluette, d’échappement, ni de la chaîne de requête d’URL qui en est presque toujours la cause.
Chaque diagnostic ici nomme la faute avec les mots que vous emploieriez, donne la position exacte et propose la correction. Cliquer sur le repère ligne:colonne y place le curseur. Quand une erreur est assez fréquente pour le mériter, un lien mène à une page qui explique ce qui la provoque, avec le message équivalent de six autres analyseurs, afin que vous la reconnaissiez la prochaine fois que votre build la signale autrement.
Les gros documents, et les documents hostiles
L’analyse tourne dans un Web Worker, donc l’interface reste réactive pendant l’examen d’un gros document. Un fichier de 100 Ko est vérifié en 20 millisecondes environ, 1 Mo en 110, et 10 Mo en un peu plus d’une seconde. Au-delà de 20 Mo l’outil décline : tout vit dans la mémoire de cet onglet, et un document de cette taille rend le navigateur inutilisable plutôt que lent.
XML a des formes de déni de service que JSON n’a pas, et elles sont ici bornées plutôt que supposées absentes. Un document déclarant des entités imbriquées qui s’étendent exponentiellement, le motif « billion laughs », est rejeté en deux millisecondes environ, parce que le coût de l’expansion est calculé à partir des déclarations avant qu’un seul caractère ne soit développé. La variante quadratique, une grosse entité référencée des milliers de fois, tombe sous le même budget. L’imbrication est plafonnée, les cycles d’entités sont détectés au lieu d’être parcourus, et les entités externes sont signalées mais jamais récupérées.
Les documents que les gens collent vraiment ici
Un validateur est un outil généraliste, mais les documents qui arrivent jusqu'à lui ne se répartissent pas uniformément. Une poignée de formes concentre l'essentiel du trafic, et chacune échoue à sa manière caractéristique.
Dans la plupart de ces cas, valider et formater sont la même tâche. Le fichier est illisible parce qu'il est arrivé minifié, ou indenté par trois outils différents l'un après l'autre, et l'erreur reste invisible tant qu'il n'est pas mis en forme. Le bouton Formater ci-dessus le reformate sur place, sans détour par un autre site ; le formateur XML est la version complète, avec le contrôle de la largeur d'indentation et du traitement des commentaires.
- Les sitemaps XML. Le validateur de sitemaps vérifie le protocole sitemaps.org et pas seulement la syntaxe : les plafonds de 50 000 URL et 50 Mo, le format W3C Datetime que lastmod exige réellement, et la règle voulant que chaque URL se trouve sur le même hôte que le sitemap. Un sitemap Google peut être parfaitement bien formé et malgré tout rejeté, et c'est presque toujours l'une de ces trois choses.
- SEPA et les autres messages de paiement ISO 20022. Un ordre de prélèvement pain.008 ou un relevé camt.053 n'a de sens que confronté au XSD publié, donc ceux-là vont dans le validateur XSD avec le schéma collé à côté. C'est la catégorie où la garantie de non-transmission cesse d'être une abstraction : un fichier de test porte quand même de vrais IBAN et de vrais identifiants de créancier.
- La configuration des serveurs de jeu. DayZ, Arma et les serveurs bâtis sur le même moteur lisent types.xml, cfgspawnabletypes.xml et events.xml au démarrage, et un seul élément <type> non fermé arrête le serveur avec un message qui ne nomme ni le fichier ni la ligne. Coller le fichier ici vous donne les deux, avec la profondeur d'imbrication au point de rupture.
- Les enveloppes SOAP et les réponses qui en reviennent. Ce sont les documents les plus susceptibles de transporter un jeton bearer ou une chaîne de connexion, et c'est la raison pour laquelle le formateur SOAP existe comme page distincte.
- Les flux RSS et Atom, où l'erreur habituelle est une esperluette brute dans une URL à l'intérieur d'un titre, le lecteur de flux se contentant d'annoncer que le flux est cassé.
Si vous avez l'habitude de valider dans Notepad++
Notepad++ n'a aucune prise en charge XML native. Le plugin XML Tools l'ajoute, et ce plugin est une liaison vers libxml2, c'est-à-dire le moteur même que ce site compile en WebAssembly. Les vérifications de fond concordent donc. Ce qui diffère, c'est tout ce qui les entoure.
Le plugin signale une erreur dans une boîte de dialogue plutôt que sur le document : vous lisez un numéro de ligne, puis vous allez la chercher. Il est réservé à Windows, comme Notepad++, et sa version compilée doit correspondre à l'architecture de votre éditeur, ce qui explique en général qu'une installation neuve affiche un menu grisé. La validation par schéma existe, mais elle attend que le XSD soit joignable depuis la déclaration du document lui-même, ce qu'un fragment extrait d'un fichier plus grand n'a presque jamais.
Aucun des deux outils ne remplace l'autre, et le partage honnête tient à l'endroit où se trouve déjà le document. Si c'est un fichier sur disque, que vous êtes de toute façon dans l'éditeur et que vous n'avez pas de réseau, le plugin est le chemin le plus court. S'il est arrivé dans un ticket de support, un presse-papiers ou un onglet de navigateur, si vous voulez toutes les erreurs en une passe plutôt qu'une par boîte de dialogue, ou si vous n'êtes pas sous Windows, charger une page va plus vite qu'installer un plugin. Il en va de même pour le schéma : coller un XSD dans le second volet ici n'exige aucune déclaration à l'intérieur du document.
Le faire en code
Le même contrôle dans les langages qui consomment le plus de XML. Chacun est donné dans sa forme sûre : les valeurs par défaut de plusieurs de ces bibliothèques résolvent volontiers les entités externes, ce qui est la faille XXE ; les drapeaux ci-dessous sont donc l’essentiel et non du remplissage.
// 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.Chacun de ces exemples désactive quelque chose. Ce n’est pas anodin : le comportement dangereux est celui par défaut en Java, en PHP avant 8.0 et dans la bibliothèque standard de Python, et c’est sur ces valeurs par défaut que tourne l’essentiel de l’analyse XML en production.
Questions fréquentes
Mon XML est-il envoyé quelque part ?
Non. L’analyseur, le formateur et le moteur de schéma sont du JavaScript et du WebAssembly qui tournent dans cet onglet. Il n’existe aucun composant serveur auquel envoyer quoi que ce soit.
Vous n’avez pas à me croire sur parole. Ouvrez les outils de développement de votre navigateur, allez dans l’onglet Réseau, collez un document et validez-le. Vous verrez les ressources de la page se charger une fois, puis plus rien. Le site n’a pas d’analytics ayant accès à l’éditeur, pas de scripts tiers, et pas de service de remontée d’erreurs.
Quelle est la différence entre bien formé et valide ?
Bien formé signifie que la syntaxe est correcte : balises fermées, imbrication correcte, un seul élément racine, caractères spéciaux échappés, valeurs d’attribut entre guillemets. Valide signifie bien formé et, en plus, conforme à un schéma, c’est-à-dire un fichier séparé décrivant quels éléments sont permis et où.
Un document peut être bien formé sans être valide. Il ne peut pas être valide sans être bien formé. Quand un système vous dit que votre XML est « invalide », il a généralement lancé un contrôle de schéma : un vérificateur de syntaxe seul n’expliquera donc pas l’échec.
Peut-il valider avec un XSD ?
Oui, et il est rare de le faire sans serveur. Les navigateurs n’ont pas de validateur de schéma natif, donc les outils gratuits soit sautent cette étape, soit envoient vos fichiers. Ce site exécute libxml2 compilé en WebAssembly, ce qui donne la validation XSD 1.0 et DTD entièrement dans le navigateur.
Le moteur pèse environ 480 Ko compressé, il n’est donc téléchargé que lorsque vous demandez réellement un contrôle de schéma, pas au chargement de la page. À noter : libxml2 n’implémente que XSD 1.0. Les schémas utilisant des fonctions XSD 1.1 comme xs:assert ne compileront pas, et l’outil le dit clairement au lieu de rendre une erreur de structure incompréhensible.
Pourquoi signale-t-il plusieurs erreurs quand d’autres validateurs n’en donnent qu’une ?
Parce qu’une erreur est rarement toute l’histoire, et parce qu’un analyseur qui s’arrête au premier problème vous fait corriger un gros document un aller-retour à la fois.
L’analyseur reprend après un échec et continue, si bien qu’une seule passe trouve l’attribut sans guillemets ligne 4, l’esperluette brute ligne 12 et la balise non fermée à la fin. Une précaution s’impose : une faute précoce comme une balise non fermée peut faire paraître fautif tout ce qui suit. Corrigez les premières et relancez, plutôt que de remonter la liste par le bas.
Quelle taille de fichier accepte-t-il ?
Jusqu’à 20 Mo. Un document de 10 Mo est analysé en un peu plus d’une seconde, et l’analyse tourne dans un Web Worker : la page ne gèle donc pas pendant ce temps.
La limite est délibérée, pas découverte à force de plantages. Tout est conservé dans la mémoire de cet onglet, et au-delà d’environ 20 Mo l’arbre d’analyse peut consommer plusieurs centaines de mégaoctets. Pour des fichiers réellement volumineux, le bon outil est un analyseur en flux sur votre machine : xmllint, iterparse en Python, ou un analyseur SAX, aucun ne construisant l’arbre entier.
Gère-t-il correctement les espaces de noms ?
Oui. Les préfixes sont résolus par rapport aux déclarations dans la portée, et utiliser un préfixe non lié est signalé comme une erreur, avec la déclaration à ajouter. C’est une panne fréquente quand un fragment est copié depuis un document plus grand et que la déclaration xmlns reste sur l’élément racine d’origine.
L’éditeur atténue aussi le préfixe par rapport au nom local, si bien que soap:Body se lit comme Body avec son échafaudage. C’est un détail, mais il rend une enveloppe SOAP profondément imbriquée nettement plus lisible.
Est-il prudent de coller un document contenant des identifiants ?
Plus prudent qu’avec tout outil qui l’envoie, puisque rien n’est transmis. Le document ne quitte pas l’onglet, n’est pas journalisé et n’entre dans aucun rapport d’erreur.
Une réserve mérite d’être dite : votre saisie est enregistrée dans le localStorage de ce navigateur pour qu’un rafraîchissement ne vous fasse pas perdre votre travail. C’est local à votre machine et jamais transmis, mais cela veut dire que le document persiste jusqu’à ce que vous l’effaciez. Le bouton Effacer le supprime immédiatement, et les documents de plus de 300 Ko ne sont pas stockés du tout.
Puis-je valider un sitemap XML avec cet outil ?
Oui, et pour un sitemap la page dédiée du validateur de sitemaps est la meilleure. Celle-ci vérifie que le document est du XML bien formé, ce qui est nécessaire mais pas suffisant : un sitemap que Google rejette est en général bien formé et enfreint plutôt une règle du protocole.
Cette page vérifie les règles elles-mêmes. Les limites de 50 000 URL et 50 Mo non compressés, l'espace de noms sitemaps.org, lastmod au format W3C Datetime plutôt que ce que votre framework a produit, et l'exigence que chaque URL soit sur le même hôte que le fichier sitemap. Elle signale aussi les éléments que Google a publiquement déclaré ignorer, pour que vous cessiez de régler des valeurs sans effet.
Gère-t-il SEPA et les fichiers ISO 20022 comme pain.008 ou camt.053 ?
Oui. Un message ISO 20022 est du XML ordinaire adossé à un gros schéma : collez le message dans le validateur XSD et le schéma pain.008 ou camt.053 correspondant dans le second volet. La validation s'exécute contre ce schéma dans votre navigateur, sans compte à créer et sans autre plafond que la limite générale de 20 Mo.
C'est le cas où la destination du document compte le plus. Un fichier de paiement qui n'est qu'un test porte quand même de vrais IBAN, identifiants de créancier et références de mandat, et plusieurs validateurs gratuits acceptant l'ISO 20022 les envoient d'abord à un serveur. Ici rien n'est transmis, ce que vous pouvez vérifier dans l'onglet Réseau pendant que vous travaillez. Une limite à connaître : le moteur implémente XSD 1.0, qui est la version dans laquelle les schémas ISO 20022 publiés sont écrits.
Puis-je l'utiliser pour les fichiers serveur DayZ comme types.xml ?
Oui, et il s'y prête bien. Les fichiers d'économie de DayZ (types.xml, cfgspawnabletypes.xml, events.xml et cfgeventspawns.xml) sont du XML ordinaire, et le serveur refuse de démarrer si l'un d'eux est malformé. Le message qu'il affiche ne nomme généralement ni le fichier ni la position, ce qui transforme un chevron manquant en soirée entière.
Collez le fichier ici et chaque erreur de syntaxe est signalée d'un coup avec sa ligne et sa colonne : un fichier édité à la main sur plusieurs sessions se corrige en une passe plutôt qu'un redémarrage à la fois. Deux réserves méritent d'être dites : il n'existe pas de XSD publié pour ces fichiers, donc l'outil vérifie que le XML est bien formé et non qu'une valeur d'attribut fait partie de celles que le jeu accepte ; et une valeur de nominal ou de lifetime qui est du XML légal mais fausse pour votre économie de loot passera ici et se comportera quand même mal en jeu.
Comment cela se compare-t-il au validateur XML de Notepad++ ?
Ils utilisent le même moteur. Notepad++ ne fournit aucune prise en charge XML par lui-même ; le plugin XML Tools l'apporte et repose sur libxml2, c'est-à-dire ce que ce site exécute en WebAssembly. Les deux s'accordent donc sur le fait qu'un document est bien formé ou non.
Les différences sont pratiques. Le plugin est réservé à Windows et sa compilation doit correspondre à l'architecture de votre éditeur, d'où le menu grisé d'une installation neuve. Il signale les erreurs dans une boîte de dialogue plutôt que sur le document, et sa validation par schéma attend que le XSD soit déclaré dans le fichier, ce qu'un fragment copié n'a presque jamais. Cette page accepte un XSD collé dans un second volet sans aucune déclaration, signale toutes les erreurs de syntaxe en une passe, et fonctionne partout où il y a un navigateur. Si le fichier est déjà ouvert dans Notepad++ et que vous êtes hors ligne, utilisez le plugin : c'est le cas qu'il gagne.
Ce validateur XML est-il gratuit, et faut-il s'inscrire ?
Il est gratuit, sans compte, sans demande d'adresse e-mail, sans quota quotidien et sans offre payante qui retiendrait la validation par schéma. Rien sur ce site n'est verrouillé.
C'est plus facile à offrir qu'il n'y paraît, parce que l'économie est différente. Un validateur qui tourne sur un serveur paie du CPU pour chaque document vérifié, d'où les outils qui comptent les usages, plafonnent la taille des fichiers ou demandent une inscription. Ici l'analyse se fait sur votre machine : un fichier de 10 Mo ne coûte rien au site, et il n'y a aucune raison de compter combien vous en validez.
Puis-je valider du XML en ligne sans rien installer ?
C'est exactement ce qu'est cette page. Elle fonctionne dans n'importe quel navigateur actuel sous Windows, macOS, Linux, Android ou iOS, sans rien à installer, sans extension et sans compte.
Une distinction mérite d'être faite, car le mot « en ligne » y remplit deux rôles. La plupart des validateurs en ligne le sont dans les deux sens : la page est sur le web, et votre document part vers leur serveur pour y être vérifié. Celui-ci ne l'est qu'au premier sens. La page est livrée une fois par le réseau, et ensuite l'analyseur, le moteur de schémas et l'éditeur s'exécutent localement dans l'onglet. Chargez-la une fois et elle continue de fonctionner réseau coupé.
Est-ce un validateur et un formateur XML, ou me faut-il deux outils ?
Les deux sont ici. Le bouton Formater de la rangée ci-dessus reformate sur place ce qui se trouve dans l'éditeur, de sorte que la séquence habituelle — coller quelque chose d'illisible, le mettre en forme, puis trouver l'erreur — se déroule sans changer de site.
Le formateur XML est la version complète, pour quand le formatage est le travail lui-même et non une étape vers autre chose : indenter avec deux espaces, quatre espaces ou des tabulations, décider du sort des commentaires, et minifier dans l'autre sens. La validation tourne aussi sur cette page, parce qu'un document doit être bien formé avant de pouvoir être reformaté du tout.
Peut-il embellir le XML en plus de le valider ?
Oui. Embellir, mettre en forme et formater désignent la même opération : le document est ré-indenté pour que l'imbrication devienne visible, ce qui est généralement ce qui rend une erreur repérable.
Un détail mérite d'être connu, car la plupart des embellisseurs le traitent mal. L'espace entre deux éléments est insignifiant et peut être modifié sans risque, mais l'espace à l'intérieur d'un élément qui contient aussi du texte est une donnée, et le ré-indenter change le sens du document. Un embellisseur qui répartit <p>Bonjour <b>vous</b></p> sur trois lignes indentées a modifié le contenu, pas seulement sa présentation. Celui-ci laisse le contenu mixte exactement tel qu'il l'a trouvé, et c'est pourquoi certaines parties d'un document embelli restent sur une seule ligne.
Quel est le meilleur validateur XML ?
Cela dépend de l'endroit où se trouve déjà le document et de ce qu'il faut vérifier, et une réponse honnête inclut les cas où ce n'est pas celui-ci.
Pour un document que vous pouvez coller, un outil de navigateur est le chemin le plus court, et les trois points à comparer sont : fait-il de la validation par schéma, envoie-t-il votre fichier pour cela, et pouvez-vous agir sur les erreurs qu'il signale. Pour un fichier déjà ouvert dans un projet, votre éditeur est plus proche : VS Code avec l'extension XML de Red Hat, ou IntelliJ, valide contre un schéma à la frappe. Pour des fichiers trop volumineux pour tenir en mémoire, ou pour une étape de build, xmllint est le bon outil et il est déjà installé sur la plupart des machines. Pour une chaîne d'intégration continue, le validateur qui y a sa place est celui du langage dans lequel elle est écrite.
Celui-ci est fait pour le cas intermédiaire : validation par schéma sans serveur, toutes les erreurs de syntaxe en une passe au lieu de la première seulement, et des messages rédigés pour la personne qui les lit plutôt que pour l'auteur de l'analyseur.