Aller au contenu principal
ToolsByUs

CSV vers XML

Ce convertisseur transforme les lignes CSV en éléments XML dans votre navigateur : un élément racine <records>, un élément <record> par ligne, et une balise enfant par en-tête. Les noms de balises sont nettoyés pour être des noms XML valides, le texte est échappé, et les en-têtes avec points sont imbriqués dans des éléments enfants. Aucun fichier n’est envoyé.

100 % local

CSV vers XML en clair

XML est plus strict que CSV concernant les noms, et cette rigidité constitue tout le problème technique ici. Une en-tête comme unit price ne peut pas devenir une balise car les noms d’éléments ne peuvent pas contenir d’espaces ; 2fa ne peut pas devenir une balise car les noms ne peuvent pas commencer par un chiffre. Ce convertisseur applique la solution standard — les caractères invalides deviennent des underscores, et un nom commençant par un chiffre reçoit un underscore initial — afin que chaque en-tête produise une balise qu’un analyseur XML accepte, et que le mapping de la colonne vers l’élément reste visible plutôt que magique.

Le CSV est analysé selon la RFC 4180 : une machine à états qui respecte les quotes doubles, les virgules et les sauts de ligne à l’intérieur des champs entre guillemets, une détection du délimiteur entre virgule, point-virgule, tabulation et pipe, et la même politique de type stricte que le site utilise partout — les valeurs ne deviennent des nombres que sous la grammaire des nombres JSON, donc 02134 conserve son zéro initial. Les en-têtes avec points conservent leur structure : address.city devient un élément address avec un enfant city, et non une balise plate avec un point dans son nom.

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

Vérifier l’aller-retour est un copier-coller, car le Convertisseur XML vers CSV lit ces mêmes conventions en sens inverse, remettant les lignes depuis les éléments.

Si le choix du format de sortie est encore ouvert, le Comparaison JSON vs XML présente où le balisage apporte sa valeur et où il constitue une surcharge.

Comment la conversion fonctionne réellement

Le pipeline est analyser, développer, nettoyer, échapper — dans cet ordre, et chaque étape ne voit que la sortie de la précédente. Cet ordre explique pourquoi une virgule dans une cellule entre guillemets ne perturbe jamais la structure des éléments : la grille est stabilisée avant que n’existe du XML, et le générateur XML ne prend jamais de décisions concernant la syntaxe CSV.

  • Analyser : règles RFC 4180 avec les tolérances du monde réel — une quote au milieu d’un champ nu est prise littéralement, et les lignes vides de fin sont ignorées.
  • Développer : les en-têtes sont décodés comme des chemins, donc address.city imbrique city dans address, et tags[0], tags[1] deviennent des éléments répétés.
  • Nettoyer : chaque nom d’élément est vérifié selon les règles des noms XML 1.0 — lettres, chiffres, underscores, traits d’union, points et deux-points — et corrigé si nécessaire.
  • Échapper : le contenu textuel reçoit &amp;, &lt; et &gt; là où la source contenait &, < ou >, et les valeurs d’attribut échappent en plus les guillemets doubles.

La politique des noms de balise, précisément

XML 1.0 autorise un nom à commencer par une lettre, un underscore ou deux-points, et à continuer avec des chiffres, des traits d’union et des points ; tout le reste est interdit. Le nettoyeur remplace chaque caractère hors de cet ensemble par un underscore et ajoute un underscore si le premier caractère survivant serait un chiffre — ainsi unit price devient unit_price, 2fa devient _2fa, et une colonne nommée discount% devient discount_. Les noms valides passent tels quels, incluant CamelCase et kebab-case, car réécrire un nom déjà valide casserait les systèmes qui l’attendent.

En-tête CSVÉlément généréPourquoi
name<name>déjà un nom XML valide — laissé tel quel
unit price<unit_price>l’espace remplacé par un underscore
2fa<_2fa>les noms ne peuvent pas commencer par un chiffre
address.city<address><city>les en-tères avec points sont imbriqués, pas aplatis

Que devient les valeurs

XML n’a pas de type nombre ou booléen séparé — chaque valeur est du texte — donc les cellules sont transmises telles quelles, sans aucune conversion qui pourrait perdre ou inventer de la précision. Une cellule vide est traitée comme un champ absent plutôt qu’une valeur vide, donc l’élément est omis au lieu d’émettre une balise auto-fermée vide que personne ne consomme. L’échappement est appliqué à la sortie : une cellule contenant A & B devient A &amp; B dans le document, et tout analyseur XML qui lit le résultat retrouve le texte original.

  • 02134 reste 02134 ; aucun zéro initial n’est jamais supprimé, car la valeur est du texte dès qu’elle quitte la grille.
  • Une cellule multi-lignes conserve ses sauts de ligne à l’intérieur de l’élément, et ces sauts sont des données, pas un formatage.
  • L’élément <record> est le même pour chaque ligne, régulière ou non — les colonnes qu’une ligne manque tout simplement ne produisent aucun élément.

Cas particuliers et leur rapport

Les refus du convertisseur font partie essentielle de son contrat. Un champ entre guillemets non terminé arrête l’analyse à cette ligne avec une erreur nommée, car deviner où le champ se serait terminé aurait déformé silencieusement toutes les lignes suivantes. Une ligne avec un nombre de champs différent de l’en-tête est quand même convertie, mais un avertissement précise que les champs manquants sont absents et les excédents ont été ignorés. Les en-têtes dupliqués sont convertis avec la valeur la plus à droite qui l’emporte, et l’avertissement le dit — le comportement de l’importation de tableur, rendu explicite.

  • Quote non terminée : analyse arrêtée, ligne signalée, aucune sortie écrite.
  • Lignes irrégulières : converties avec un avertissement nommant les lignes affectées.
  • En-têtes dupliqués : convertis avec un avertissement ; la dernière occurrence l’emporte.

Questions fréquentes

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

Non. L’analyse du CSV et la construction du XML s’exécutent toutes deux dans cet onglet de navigateur avec du code chargé une seule fois à l’ouverture de la page. Il n’y a pas de point d’envoi à appeler, et la page est servie avec un Content-Security-Policy dont le connect-src est 'self', donc le navigateur refuserait toute sortie même si une tentative était faite. Regardez le panneau Network dans DevTools pendant la conversion — il reste vide.

Pourquoi ma sortie est-elle enveloppée dans des balises <records> et <record> ?

XML a besoin d’un seul élément racine, et un fichier CSV n’a pas de nom naturel à lui donner, donc le convertisseur utilise une forme fixe : un élément racine <records> avec un élément <record> par ligne. Les en-têtes deviennent les balises enfants à l’intérieur de chaque enregistrement. Cet emballage est ce qui rend la sortie un document bien formé plutôt qu’un fragment, et chaque ligne est facile à atteindre avec un XPath comme /records/record.

Les noms de balise illégaux sont-ils gérés ?

Chaque en-tête est nettoyé selon les règles des noms XML 1.0 : les caractères en dehors des lettres, chiffres, underscore, trait d’union, point et deux-points deviennent des underscores, et un nom qui commencerait par un chiffre reçoit un underscore initial. Donc unit price devient unit_price et 2fa devient _2fa. Les noms déjà valides passent tels quels, ce qui compte quand un système en aval fait correspondance sur des noms de balise exacts.

Les caractères spéciaux dans les valeurs de cellule sont-ils échappés ?

Le contenu textuel échappe les trois caractères que XML exige : & devient &amp;, < devient &lt; et > devient &gt;. À l’intérieur des valeurs d’attribut, le guillemet double est échappé en &quot; également. L’échappement n’a lieu qu’à la sortie, donc une cellule contenant A & B fait un aller-retour vers exactement A & B quand un analyseur XML lit le document — rien n’est échappé deux fois et rien n’est pré-déchappé.

Mes nombres et codes postaux conserveront-ils leur formatage ?

Oui, car les valeurs deviennent du texte XML telles quelles — il n’y a pas d’étape de conversion numérique qui pourrait les reformater. 02134 conserve son zéro initial, 44.95 conserve sa forme décimale exacte, et une valeur comme 1e5 reste les caractères que vous avez tapés plutôt qu’être développée. L’information sur le type est une préoccupation du CSV ou du JSON ; les éléments XML portent du texte, et le convertisseur ne la réinterprète pas.

Que se passe-t-il si mon CSV a des lignes irrégulières ou des en-têtes dupliqués ?

Les deux sont convertis, chacun avec un avertissement explicite. Une ligne plus courte que l’en-tête est complétée avec des champs absents — aucun élément vide n’est inventé — et une ligne plus longue que l’en-tête a ses excédents ignorés, l’avertissement précisant combien de lignes ont été affectées. Les noms de colonne dupliqués sont résolus avec la règle du dernier gagne, de la même manière qu’un import de tableur, et l’avertissement liste les noms impliqués.

Équipe ToolsByUs · Comment nous vérifions nos outils