Convertisseur HTML vers XML
Collez du HTML bricolé. Récupérez du XML bien formé.
Ce que fait cet outil
Si vous avez déjà dû injecter un bout de HTML collé à la va-vite dans un pipeline XSLT ou un parseur XML strict, vous connaissez la douleur. Les navigateurs sont réputés indulgents — le parseur HTML de la spec WHATWG ferme silencieusement vos balises <li>, accepte les attributs sans guillemets et hausse les épaules devant un </p> manquant. Un parseur XML, non. Donnez-lui le même markup et vous obtenez une erreur de parse à la ligne 3. Cet outil prend du HTML du vrai monde — celui que vous collez vraiment depuis un CMS ou un vieux template — et le convertit en XML qu'un parseur conforme à la norme acceptera du premier coup.
C'est plus que fermer des balises. Le convertisseur prend en charge tout ce qui rend HTML tolérant et XML strict : les éléments vides comme <br>, <img> et <hr> deviennent auto-fermants sous la forme <br/> ; les attributs booléens comme checked et disabled sont développés en checked="checked" ; les valeurs d'attribut non-quotées sont encadrées de guillemets doubles ; les noms de balise passent en minuscules par cohérence ; et la poignée d'entités HTML nommées que XML ne connaît pas ( , —, £, ×, etc.) est convertie en entités numériques comme   que tout parseur XML comprend.
Les commentaires passent intacts. Les sections CDATA à l'intérieur de <script> et <style> sont préservées. La sortie est joliment indentée pour être lisible, et elle passera la validation W3C comme document XML ou s'insérera directement dans un workflow XHTML 1.0. Si ce que vous voulez vraiment, c'est du XHTML Strict, vous avez fait 95 % du chemin — il ne reste qu'à ajouter le doctype et le namespace en tête vous-même.
Comment l'utiliser
Trois étapes. Ça marche pareil que vous colliez un seul paragraphe ou un template de page entier.
Collez votre HTML (ou essayez l'exemple)
Déposez votre HTML dans l'éditeur de gauche tel quel. Balises non fermées, attributs booléens nus, valeurs sans guillemets, éléments vides sans auto-fermeture — tout passe. Cliquez sur Charger l'exemple si vous voulez d'abord voir un cas réaliste et bordélique.
Pas besoin de réparer quoi que ce soit à la main. Tout l'intérêt de cet outil, c'est qu'il fait le ménage pour vous. Collez exactement ce qui sort de votre CMS, de votre doc Word ou de votre vieux template.
Cliquez sur Convertir
Cliquez sur le bouton vert Convertir. L'outil parse votre HTML avec un parseur tolérant, puis le re-sérialise via un writer XML pour que chaque balise soit fermée, chaque attribut entre guillemets et chaque entité valide en XML.
Copiez le XML
Le panneau de droite se remplit de XML bien formé et indenté. Copiez-le dans votre entrée XSLT, votre fixture de test DOM, votre build EPUB ou partout où il vous faut du markup qu'un parseur strict ne rejettera pas.
Quand ça sert vraiment
Injecter du HTML dans XSLT ou un pipeline XML
Vous avez une feuille XSLT qui transforme du contenu en PDF, en flux ou dans un autre format — mais votre entrée, c'est du HTML de CMS, pas du XML. Convertissez d'abord, transformez ensuite.
Validation XHTML strict
Un intranet vieillissant qui réclame encore du XHTML 1.0 Strict ? Collez le HTML bâclé de votre éditeur, récupérez le XML, ajoutez un doctype en tête, c'est plié.
Convertir du markup de blog pour EPUB / liseuses
EPUB, c'est du XHTML sous le capot, et il refuse catégoriquement un <code></p></code> manquant. Nettoyez un chapitre entier de HTML de blog en un seul collage avant de packager.
Nettoyage pour systèmes d'archivage
Alimenter un vieux HTML vers une archive basée sur XML (DSpace, Fedora Commons, tout ce qui sent le JATS) ? Les schémas stricts se moquent que le navigateur l'ait rendu correctement — convertissez-le d'abord.
Questions fréquentes
Qu'est-ce qui rend concrètement HTML "tolérant" et XML "strict" ?
Trois choses majeures. Un : HTML a des éléments vides (<br>, <img>, <input>, <hr>, <meta>, <link>) qui ne sont pas censés avoir de balise fermante — XML exige soit <br></br> soit <br/>. Deux : HTML permet d'omettre complètement les balises fermantes pour <li> ou <p> parce que l'algorithme de parsing les déduit. Trois : HTML accepte les attributs sans guillemets (class=foo) et sans valeur (disabled). XML rejette les trois.
Que deviennent les attributs booléens comme `checked` et `disabled` ?
Ils sont développés dans la forme XHTML. <input type=checkbox checked disabled> devient <input type="checkbox" checked="checked" disabled="disabled"/>. Chaque attribut finit avec un nom ET une valeur entre guillemets, ce qu'exige XML — l'attribut sans valeur n'existe pas en XML.
Comment sont traitées les entités HTML comme ` ` et `—` ?
XML ne connaît nativement que cinq entités nommées : &, <, >, ", '. Tout le reste — , —, £, © — est converti en forme numérique ( , —, £, ©), donc n'importe quel parseur XML les acceptera sans DTD.
Les commentaires survivent-ils à l'aller-retour ?
Oui. <!-- à relire --> entre, ressort identique. Les commentaires sont valides en HTML comme en XML avec la même syntaxe, donc ils passent tels quels — pratique si vous les utilisez pour des notes éditoriales ou des marqueurs de build.
Met-il en minuscules les noms de balise et d'attribut ?
Oui, par défaut. <DIV Class="Foo"> devient <div class="Foo">. Les noms de balise et d'attribut sont passés en minuscules pour coller à la convention XHTML 1.0. Les VALEURS d'attribut, on ne touche pas — ce qui est entre guillemets, ce sont vos données.
Quand ça ne suffit pas — quels cas l'outil NE gère PAS ?
Le contenu arbitraire dans <script> est préservé tel quel comme texte, mais l'outil n'essaie pas de réécrire du JavaScript pour le rendre compatible XML. Si votre JS contient des caractères < ou & nus, il faudra les entourer vous-même de <![CDATA[...]]> (on préserve le CDATA existant). Les fragments de document sont OK ; on ne synthétise pas de déclaration <?xml ?> ni de doctype — ajoutez-les vous-même si votre consommateur aval les attend.
Autres outils utiles
HTML vers XML, c'est une pièce du puzzle. Ces outils s'associent bien avec :