Mise en forme du code / MULTIVERTO
Compactez les espaces entre éléments XML.
Appliquez chaque outil de texte au résultat précédent.
01 / Guide
Supprime certains espaces de présentation; contrôlez les zones où l’espace a une signification.
Pour une syntaxe complexe ou des ressources de production, vérifiez la sortie dans l’application cible avec un analyseur ou outil spécialisé.
02 / Exemple
<racine>
<message>Bonjour</message>
<nombre>2</nombre>
</racine><racine><message>Bonjour</message><nombre>2</nombre></racine>03 / Guide
Compactez les espaces entre éléments XML. Supprime certains espaces de présentation; contrôlez les zones où l’espace a une signification. Ce sens retire les nœuds constitués seulement d’indentation entre éléments XML. Il ne compacte pas un texte contenant lettres ou chiffres. Si ces espaces ont un sens pour le destinataire, testez même cette réduction prudente.
XML exige une racine unique, des fermetures concordantes, des attributs entre guillemets et des caractères spéciaux échappés. Contrairement à HTML, un XML mal formé doit être rejeté. Cet outil local prend en charge une arborescence simple; déclarations, définitions de type, commentaires et CDATA sortent du sous-ensemble accepté. Il préserve les valeurs textuelles non vides et met en forme ou compacte les espaces entre enfants constitués d’éléments. Ces espaces peuvent compter pour un consommateur XML configuré pour les conserver: testez donc la sortie compacte. Les noms préfixés sont retenus sans résolution sémantique. Pour validation ou canonicalisation, utilisez un analyseur tenant compte des espaces de noms.
Le compactage convient lorsque le résultat est consommé par une machine et que l’indentation destinée aux humains est inutile. Vérifiez d’abord que la source initiale fonctionne, puis observez ce que l’opération retire. Cet outil ne promet pas le gain d’un minificateur de production: celui-ci peut analyser toute la grammaire, renommer des identifiants, simplifier des constantes ou appliquer une compression après sérialisation. Ici, la règle est prudente: une construction incertaine reste intacte ou produit une erreur. Comparez la longueur seulement après le comportement ou le contenu analysé. Si le système cible dépend de commentaires, licences, cartes de source ou espaces significatifs, tenez-en compte avant de remplacer le fichier initial.
Conservez la source près de la sortie et essayez d’abord un petit exemple connu avant de traiter un grand document. Comparez le contenu utile, pas seulement la taille du fichier ou le nombre de lignes. Vérifiez noms, chaînes entre guillemets, caractères non ASCII, fins de ligne et champs répétés après transformation. Une sortie lisible ne valide aucun schéma, ne prouve pas que le code s’exécute et ne garantit pas que les données sont publiables. Ce site traite le texte dans le navigateur et montre la sortie comme du texte, mais l’application où vous la collerez appliquera ses propres règles. Si la saisie est refusée, repérez la construction non prise en charge et recourez au besoin à un analyseur spécialisé.