Aller au contenu principal
ToolsByUs

XML vers CSV

Ce convertit aplati XML en CSV RFC 4180 dans votre navigateur. Les enfants répétés de l’élément racine deviennent des lignes, leurs attributs deviennent des colonnes préfixées par @, et le texte des éléments atterrit dans des colonnes nommées avec des fins de ligne CRLF et des guillemets uniquement là que la grammaire l’exige. Rien n’est envoyé.

100 % local

XML vers CSV en clair

La plupart des XML réels qui se comportent comme un tableau partagent une seule forme : un élément contenant de nombreux enfants de même nom, chaque enfant représentant un enregistrement — un catalogue de livres, un journal d’entrées, une liste de commandes. Ce convertisseur recherche exactement cette forme. Trouvez l’enfant répété de la racine et le reste est mécanique : chaque enfant devient une ligne, ses attributs et éléments internes deviennent des colonnes, et l’union de chaque colonne à travers chaque ligne devient l’en-tête, dans l’ordre où elles ont été vues pour la première fois.

Les conventions sont celles que chaque pont XML utilise, et elles sont rendues explicites ici : un attribut conserve son nom mais gagne un préfixe @, donc id="bk101" devient la colonne @id ; le texte d’un élément devient sa valeur #text ; et un élément enfant qui se répète à l’intérieur d’un enregistrement explose en colonnes indexées plutôt que d’être fusionné silencieusement. Le côté CSV est strictement RFC 4180 — fins de ligne CRLF, échappement de guillemets doubles uniquement si un champ contient une virgule, un guillemet ou un saut de ligne — et les valeurs traversent telles quelles, sans aucune coercition numérique pour reformater un code postal.

Tout s’exécute dans cet onglet de navigateur. Le XML est parsé par un moteur en page et le CSV est construit à partir de l’arbre parsé ; aucun ne touche au réseau — ouvrez DevTools, observez le panneau Network rester silencieux, et la promesse se vérifie d’elle-même.

Construire le XML à partir d’une exportation de tableur ? Le convertisseur CSV vers XML applique ces mêmes conventions dans l’autre sens.

Ce que le côté CSV garantit — guillemets, CRLF, guillemets doublés — est correctement documenté dans le guide RFC 4180 de ce site.

Comment la conversion fonctionne réellement

Le document est tokenisé une fois en un arbre, puis la lecture tabulaire est une étape séparée et honnête : l’arbre a soit la forme des enfants répétés, soit il ne l’a pas, et prétendre le contraire produirait un CSV qui semble correct mais signifie autre chose. Quand la forme est trouvée, chaque enregistrement est aplati en chemins de feuilles, et la ligne d’en-tête est l’union ordonnée de ces chemins à travers tous les enregistrements — premier vu en premier, donc l’ordre des colonnes est stable et prévisible plutôt qu’aléatoire alphabétiquement.

  • Analyse : un analyseur à passage unique construit l’arbre d’éléments ; les commentaires, DOCTYPE et instructions de traitement sont ignorés, et un deuxième élément racine est rejeté avec un numéro de ligne.
  • Sélection : le premier élément enfant répété de la racine fournit les lignes — <catalog> plein d’enfants <book> est le cas classique.
  • Aplatissement : les attributs deviennent des colonnes @, le texte des éléments devient #text, et un imbriquage plus profond devient des chemins avec des points comme author.#text.
  • Émission : une ligne terminée par CRLF par enregistrement, champs entre guillemets uniquement quand une virgule, un guillemet ou un saut de ligne l’impose.

Comment les fonctionnalités XML mappent aux colonnes

XML a trois façons de porter une valeur — attributs, contenu textuel et éléments enfants — et une grille plate en a une : une colonne nommée. Le mappage ci-dessous est le standard, choisi pour que deux fonctionnalités de la source ne puissent entrer en collision en sortie et pour que l’en-tête lui-même vous dise quel type de valeur chaque colonne vient de.

Construction XMLColonneExemple de cellule
attribut id="bk101"@idbk101
texte d’élément <price>5.95</price>price.#text5.95
élément avec attributs et texte@sku plus #textA-1, Widget
petits-enfants répétésbook[0].#text, book[1].#textun, deux

Les valeurs traversent telles quelles

Il n’y a pas d’étape d’inférence de type entre l’arbre XML et le CSV, délibérément. Le texte XML est du texte, donc 44.95 arrive comme les caractères 44.95, un code postal conserve son zéro initial, et une valeur comme 1e5 n’est pas étendue en 100000. Les entités traversent de la même manière : l’analyseur n’est pas un validateur et ne réécrit pas les références d’entité, donc ce qui atterrit dans une cellule est exactement ce que le texte source contenait. Si la destination a besoin de valeurs typées, associez cet outil au convertisseur CSV vers SQL, qui infère les types des cellules à ce moment-là, là où le choix est visible et réversible.

  • Les nombres conservent leurs caractères exacts — aucune précision n’est inventée ou perdue.
  • Les espaces blancs dans un nœud texte sont préservés ; les espaces blancs entre les éléments ne deviennent jamais des données.
  • Les éléments vides (<debug/>) produisent une colonne avec une cellule vide plutôt que de disparaître.

Où ce convertisseur refuse de deviner

Deux structures forceraient le convertisseur à inventer de l’information, et les deux sont refusées avec un message spécifique à la place. La première est un document sans élément enfant répété — une racine unique ne contenant rien de tabulable ne peut devenir des lignes sans inventer une forme de ligne. La seconde est un document avec plus d’un élément racine, qui n’est pas du tout un document ; l’erreur nomme l’élément fautif et sa ligne, et rien n’est écrit. Un fragment qui presque correspond est encore un fragment, et la correction la plus rapide est de supprimer ou de renommer l’élément d’enrobage avant de coller.

  • Pas d’enfants répétés : erreur nommant la forme attendue <root><item>…</item></root>.
  • Racines multiples : rejeté, avec le deuxième élément et sa ligne signalés.
  • Balises de fermeture non appariées : rejeté au point où l’arbre cesse d’être bien formé.

Questions fréquentes

La conversion XML vers CSV envoie-elle mon fichier quelque part ?

Non. L’analyse XML et la construction CSV se font toutes deux à l’intérieur de cet onglet de navigateur avec du JavaScript chargé une seule fois quand la page s’est ouverte. Il n’y a pas de route API pour envoyer des données, et la Content-Security-Policy de la page définit connect-src 'self', donc le navigateur lui-même bloquerait toute requête sortante. Les deux affirmations sont vérifiables dans DevTools : observez le panneau Network pendant que vous convertissez — aucune requête n’apparaît.

Quels éléments XML deviennent les lignes CSV ?

Le convertisseur examine les enfants de l’élément racine et prend celui qui est répété — l’élément de même nom apparaissant plusieurs fois, comme <book> à l’intérieur de <catalog>. Chaque occurrence devient une ligne. Si aucun enfant ne se répète, chaque enfant ayant une forme d’objet est traité comme son propre enregistrement à la place, et une racine sans rien de tabulable à l’intérieur est refusée avec une erreur nommée plutôt que d’être aplatie en un fichier trompeur d’une seule ligne.

Pourquoi certains noms de colonne commencent-ils par @ ou contiennent-ils #text ?

Les préfixes enregistrent où chaque valeur se trouvait dans le XML. Un préfixe @ marque un attribut — id="bk101" devient la colonne @id — et #text marque le propre texte d’un élément, qui a besoin de son propre nom quand l’élément a aussi des attributs ou des enfants. Les préfixes empêchent les collisions : un élément nommé id et un attribut nommé id se disputeraient sinon une colonne, et l’en-tête ne vous dirait pas lequel était lequel.

Les nombres sont-ils convertis, ou les valeurs restent-elles telles qu’écrites ?

Les valeurs restent exactement telles qu’écrites. L’arbre conserve le texte comme des chaînes et l’écriture du CSV ne fait aucune inférence de type, donc 44.95 traverse comme 44.95, un code postal comme 02134 conserve son zéro initial, et rien n’est reformatté dans votre dos. C’est la même politique que suit le convertisseur XML vers YAML du site, donc un fichier converti dans un sens ou l’autre montre les mêmes caractère pour caractère.

Les champs entre guillemets et les sauts de ligne sont-ils gérés dans la sortie ?

Conformément à RFC 4180 : un champ contenant une virgule, un guillemet double ou un saut de ligne est entouré de guillemets doubles, et un guillemet à l’intérieur d’un tel champ est doublé. Les lignes se terminent par CRLF, le terminateur que la spécification définit et que les logiciels de tableur attendent. Les champs sont entre guillemets uniquement lorsque la grammale l’exige — sans guillemets décoratifs — ce qui garde le fichier plus petit et plus facile à différencier qu’une exportation où tout est entre guillemets.

Que devient les commentaires XML et la ligne DOCTYPE ?

Ils sont ignorés. Les commentaires, la déclaration DOCTYPE et les instructions de transportent aucune donnée tabulaire, donc l’arbre ne les inclut simplement jamais ; l’analyse continue à partir de la structure d’éléments. La seule chose que le convertisseur exige est un seul élément racine — un document avec un deuxième élément de plus haut niveau est rejeté avec le nom et le numéro de ligne de l’élément, car deux racines sont deux documents, pas un ensemble de lignes.

Équipe ToolsByUs · Comment nous vérifions nos outils