Convertir XML en Excel

Trouver les lignes dans une arborescence

Le XML ne connaît pas la notion de tableau : la première chose à faire est donc d'identifier quels éléments sont les enregistrements. Le signal fiable, c'est la répétition : un élément parent contenant de nombreux enfants du même nom correspond presque toujours à une liste d'enregistrements, et les éléments enfants et attributs de ces enfants deviennent les colonnes. Cela fonctionne sur l'immense majorité du XML de données — exports, flux, réponses d'API, dumps de configuration — parce qu'ils sont tous construits de la même façon.

Attributs et éléments enfants deviennent tous deux des colonnes, ce qui est nécessaire car le XML offre deux manières de dire la même chose, et chaque système choisit différemment. Un export écrit id="42" comme attribut ; un autre écrit <id>42</id> comme élément ; un troisième fait les deux dans le même document. Une grille ne fait pas la différence, et vous non plus ne devriez pas avoir à la faire : les deux arrivent donc en colonnes, les attributs étant marqués pour qu'un nom présent sous les deux formes ne crée pas de collision.

Une imbrication de plus d'un niveau est aplatie en joignant les noms d'éléments, comme pour du JSON imbriqué. Quand un enregistrement contient un enfant répété — trois lignes de commande dans une commande —, une grille ne peut pas le représenter en lignes sans dupliquer tout ce qui l'entoure : les valeurs répétées restent donc dans leur cellule. Les espaces de noms sont retirés des noms de colonnes, car une colonne appelée ns2:customerName n'aide personne dans un tableur, tandis que les valeurs elles-mêmes restent intactes.

Le XML rédigé n'a aucun tableau à trouver et se convertit mal. Une page XHTML, un article DocBook, un chapitre ePub ou un dessin SVG est un document plutôt qu'un jeu de données : sa structure est imbriquée et irrégulière par nature, et il n'y a aucun enregistrement répété à partir duquel construire des lignes. La conversion produira quelque chose, et ce quelque chose ne sera pas utile. Cette page est faite pour le XML de données, et bien faire la différence fait gagner plus de temps que n'importe quel réglage.

Si vous cherchez autre chose

Quand vous connaissez la structure, extrayez-la délibérément plutôt que de la déduire. xmlstarlet sel -t -m "//order" -v "@id" -o "," -v "customer" -n data.xml extrait exactement les champs voulus avec une expression XPath, et xq fait de même avec une syntaxe à la jq. C'est toute la différence entre une conversion qui fonctionne par chance et une conversion que l'on peut intégrer à un pipeline.

Pour les très gros fichiers, tout ce qui est fait ici a la mauvaise forme : le document est chargé entièrement en mémoire, et un XML analysé sous forme d'arbre occupe généralement plusieurs fois la taille du fichier. Les analyseurs en flux — iterparse en Python, ou SAX dans n'importe quel langage — parcourent un document de plusieurs gigaoctets avec une mémoire constante, et sont la seule approche réaliste au-delà de quelques centaines de mégaoctets.