Visualiser du XML
La visionneuse XML affiche un document sous forme d’arborescence repliable dans votre navigateur. L’arborescence est virtualisée : une réponse SOAP volumineuse ou un sitemap s’ouvre aussi vite qu’un petit document, et les attributs sont affichés de façon distincte des éléments enfants — c’est cette distinction qui rend lisible un document XML inconnu.
Comment fonctionne Visualiser du XML ?
Personne n’ouvre une visionneuse XML pour un document de vingt lignes. On en ouvre une pour une réponse SOAP, un sitemap, un SVG, un POM Maven ou un fichier de configuration trop volumineux pour être lu comme du texte et trop imbriqué pour être suivi avec le pliage d’un éditeur de texte. La seule question qui compte est donc de savoir ce qui se passe à grande échelle.
L’arbre est virtualisé, la taille importe donc à peine
L’implémentation évidente affiche un composant par nœud, ce qui veut dire qu’un document de cinquante mille nœuds produit cinquante mille éléments DOM dont peut-être quarante sont visibles. Le défilement est saccadé et l’onglet consomme des centaines de mégaoctets. Ici, le document est d’abord aplati en un tableau de lignes — chacune portant sa profondeur, son type et l’endroit où se termine son sous-arbre — et seules les lignes situées dans le viewport sont rendues. Le DOM contient environ cinquante éléments, quelle que soit la taille du document.
Enregistrer où se termine chaque sous-arbre, c’est ce qui rend le repli peu coûteux : masquer une branche revient à une comparaison d’index plutôt qu’à un parcours de tout ce qu’elle contient. Replier la racine d’un document énorme est instantané.
Les attributs sont affichés séparément des éléments
Le XML a deux sortes de membres et la plupart des visionneuses les aplatissent en une seule, ce qui fait perdre la distinction entre <line sku="X"/> et <line><sku>X</sku></line>. Les attributs apparaissent sous un préfixe @ pour que les deux subsistent sans que l’un écrase l’autre — ce qui compte, car un élément portant à la fois un attribut et un élément enfant du même nom est fréquent dans les vrais vocabulaires.
La recherche couvre tout le document, pas seulement la partie ouverte
Une correspondance enfouie dans un sous-arbre replié est trouvée et affichée, avec tous les ancêtres sur le chemin qui y mène, car une valeur sans son chemin ne vous apprend rien sur son origine.
L’entrée mal formée est nommée, pas devinée
Des balises mal appariées et des éléments non fermés produisent une erreur qui identifie la balise et la ligne. Le XML tronqué est ce qu’on colle le plus souvent dans une visionneuse — c’est bien pour cela qu’on l’examine — donc une visionneuse qui affiche quelque chose de plausible à partir d’un document cassé nuit activement.
La vue formatée est séparée et sans perte : elle réindente sans toucher au contenu, en préservant les sections CDATA, les commentaires, les instructions de traitement et le texte exact à l’intérieur des éléments.
XML
<order id="1"><line sku="A" qty="2"/></order>
Arborescence
▾ order { 2 }
@id "1"
▾ line { 2 }
@sku "A"
@qty "2"Quelles options et quels cas limites Visualiser du XML prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| Virtualisation | viewport uniquement | — | À tout instant, environ cinquante lignes existent dans le DOM, quelle que soit la taille du document. C’est la différence entre ouvrir un journal SOAP de 10 MB et faire figer l’onglet. |
| Attributs | préfixe @ | affichés | Tenus distincts des éléments enfants : un élément avec un attribut sku et un enfant sku affiche les deux, au lieu qu’un seul gagne en silence. |
| Nœuds de texte | #text | affichés | Le texte d’un élément apparaît sur sa propre ligne au lieu d’être replié dans l’élément ; un élément avec texte et enfants montre donc les deux. |
| Commentaires | #comment | affichés | Conservés, car un commentaire dans un fichier de configuration est souvent la seule documentation expliquant pourquoi une valeur vaut ce qu’elle vaut. |
| CDATA | littéral | — | Affiché tel quel. Les entités dans une section CDATA ne sont pas des entités — c’est tout l’intérêt de cette construction. |
| Espaces de noms | conservés | préfixe gardé | soap:Body reste soap:Body et les déclarations xmlns apparaissent comme attributs. Les retirer est possible dans le convertisseur XML vers JSON, où c’est un choix de conversion, pas d’affichage. |
| Recherche | sous-chaîne | insensible à la casse | Correspond aux noms et aux valeurs dans tout le document, branches repliées comprises, et garde tous les ancêtres d’un résultat pour que le chemin reste visible. |
| Entrée malformée | erreur | nommée | Les balises sans correspondance ou non fermées sont signalées avec le nom de la balise et la ligne. L’arbre continue d’afficher le dernier document valide au lieu de se vider pendant la frappe. |
| Taille d’entrée | octets | 8 MB | La tokenisation tourne sur le thread principal. Au-delà du plafond, l’outil refuse plutôt que de geler ; l’arbre lui-même gère bien plus de nœuds que ce plafond ne le permet. |
Questions fréquentes
Peut-elle ouvrir une réponse SOAP volumineuse ou un sitemap ?
Jusqu’au plafond de 8 MB, et l’arbre n’est pas le goulot d’étranglement — il ne rend que ce qui est à l’écran, donc le nombre de nœuds n’a presque aucun effet sur lui. La limite, c’est le tokenizer, qui s’exécute sur le thread principal et refuse au-delà de 8 MB plutôt que d’essayer, car essayer verrouillerait l’onglet pendant des secondes.
Pourquoi certaines lignes commencent-elles par @ ?
Ce sont les attributs. Le XML a des attributs et des éléments enfants ; les arbres façon JSON n’ont qu’un seul type de membre, donc les attributs reçoivent un préfixe pour rester distincts. Sans le préfixe, un élément portant à la fois un attribut sku et un élément enfant sku n’en afficherait qu’un des deux, et vous n’auriez aucun moyen de savoir lequel.
Puis-je modifier le XML ici ?
Vous pouvez modifier le volet de texte et l’arbre suit, mais l’arbre lui-même est en lecture seule. Le garder en lecture seule, c’est ce qui lui permet de rester rapide sur des documents où un arbre éditable peinerait — un arbre éditable doit réconcilier deux sources de vérité à chaque frappe. Pour réindenter, utilisez la vue formatée ou le formatter XML.
Mon document est invalide. Pourquoi l’arbre affiche-t-il encore quelque chose ?
Parce qu’il affiche la dernière version qui a pu être analysée, pour qu’une frappe isolée en pleine édition ne vide pas toute la vue. La bannière d’erreur nomme la balise mal appariée ou non fermée et sa ligne. Dès que le document redevient analysable, l’arbre se met à jour.
La vue formatée modifie-t-elle mon document ?
Elle modifie les espaces entre les éléments et rien d’autre. Le contenu textuel, les sections CDATA, les commentaires, les instructions de traitement et les valeurs d’attributs sont préservés octet par octet. Sachez que les espaces entre les éléments sont significatifs pour un parseur XML strict, donc le document réindenté n’est pas toujours interchangeable avec l’original pour une machine — seulement pour un humain.
Mon XML est-il envoyé ?
Non. La tokenisation et le rendu se produisent tous les deux dans l’onglet que vous avez déjà ouvert — ouvrez DevTools, regardez le panneau Réseau et collez. Cela compte pour le XML plus que pour la plupart des formats : ce que les gens doivent réellement lire, ce sont des échanges SOAP, des assertions SAML et des messages financiers, c’est-à-dire du contenu parmi les plus sensibles qu’un développeur manipule.
Quels outils liés devriez-vous utiliser ensuite ?
- Comparer du texteCompare par ligne, mot ou caractère et exporte un patch unifié
- Formater du XMLRéindente le XML sans casser CDATA, commentaires ni DOCTYPE
- Convertir XML en JSONConvertit en gardant attributs et listes à un seul élément
- Convertir JSON en XMLConvertit avec attributs et noms que le XML accepte