CSV vers YAML
Ce convertisseur transforme un fichier CSV RFC 4180 en une séquence de mappages YAML, entièrement dans votre navigateur. Les en-têtes de colonnes sont mappés sur des clés, et les en-têtes avec des points ou des crochets s’imbriquent dans un YAML structuré. La première ligne fournit les noms de clés, la mise en guillemets suit les règles de chaque format, et rien n’est envoyé.
CSV vers YAML en clair
Un fichier CSV est une grille ; un fichier YAML est un arbre. Le pont entre les deux est la ligne d’en-tête : chaque nom de colonne est lu comme un chemin dans l’enregistrement qu’il décrit. Un en-tête simple comme role devient une clé simple, address.city crée un mappage address avec une clé city à l’intérieur, et tags[0] crée une liste — la même convention de chemin de colonne que le convertisseur YAML vers CSV du site, utilisée en sens inverse. Comme le mappage est explicite et réversible, un fichier qui passe de CSV à YAML et revient arrive inchangé.
Le côté CSV est analysé selon la RFC 4180 : délimiteurs par virgule, échappement des guillemets doubles lorsqu’un champ contient une virgule, un guillemet ou un saut de ligne, et des champs entre guillemets qui peuvent s’étendre sur plusieurs lignes. Les délimiteurs sont détectés à partir de la ligne d’en-tête — virgule, point-virgule, tabulation ou pipe — et comptés uniquement en dehors des régions entre guillemets, ainsi un point-virgule dans une description ne peut pas fausser la détection. L’inférence de type est volontairement limitée : seules les valeurs correspondant à la grammaire de nombre JSON deviennent des nombres, c’est ainsi qu’un code postal comme 02134 conserve son zéro initial.
Tout s’exécute dans cet onglet de navigateur. Le texte CSV que vous collez est analysé par un moteur intégré à la page, le YAML est généré à partir des enregistrements analysés, et aucun des deux ne touche au réseau — ouvrez DevTools, observez le panneau Network rester silencieux, et la promesse se vérifie elle-même.
Le double parcours est également la vérification de correction la plus rapide, et le Convertisseur YAML vers CSV reconstruit la grille à partir du YAML en utilisant les mêmes chemins de colonnes.
Si une exportation récalcitrante ne s’analyse pas comme vous l’attendez, le Guide des champs RFC 4180 explique la mise en guillemets, CRLF et les déviations que contiennent les fichiers de tableur réels.
Comment la conversion fonctionne réellement
Le moteur lit la grille une seule fois et ne regarde plus le texte brut par la suite — chaque décision ultérieure est prise par rapport aux enregistrements analysés. Cet ordre est ce qui garde les règles composables : les chemins d’en-tête sont développés avant l’inférence de type, et les types sont inférés avant que l’émetteur YAML décide ce qui a besoin d’être mis en guillemets.
- Analyse : une petite machine à états divise le texte en champs, en respectant les guillemets doubles et les sauts de ligne à l’intérieur des champs entre guillemets, et supprime un marqueur d’ordre des octets (BOM) s’il est présent.
- Nom : la première ligne devient les noms de colonnes ; une cellule d’en-tête vide devient column1, column2, etc.
- Développement : chaque en-tête est décodé comme un chemin — les points séparent les clés de mappage, les crochets marquent les indices de tableau — et chaque ligne est reconstruite comme un enregistrement imbriqué.
- Émission : les enregistrements sont sérialisés comme une séquence YAML, avec une indentation de deux espaces, les valeurs étant mises en guillemets uniquement lorsque la forme brute serait mal interprétée.
Que signifient les noms d’en-tête
Les en-têtes sont le seul endroit où une grille peut exprimer une structure, donc ils sont lus comme des chemins plutôt que comme des étiquettes opaques. Le point et le crochet font des choses différentes, et cette différence est ce qui rend le mappage réversible : un point signifie toujours une clé de mappage, un crochet signifie toujours un indice de tableau, donc tags[0] crée une liste alors que tags.0 crée un mappage dont la clé est la chaîne « 0 ». Un convertisseur qui traiterait les deux comme interchangeables serait devinant, et la devinette serait fausse la moitié du temps.
| Ligne d’en-tête | YAML produit |
|---|---|
| address.city | un mappage address avec une clé city à l’intérieur |
| tags[0], tags[1] | une liste tags avec ces deux éléments |
| tags.0 | un mappage tags avec la clé de chaîne « 0 » — pas une liste |
| role | une clé role simple sur chaque enregistrement |
Cellules, types et champs vides
L’inférence de type existe pour rendre le YAML utile, et elle est maintenue sous contrôle strict. Une cellule devient un nombre uniquement si elle correspond à la grammaire de nombre JSON — qui interdit les zéros initiaux — et elle devient true, false ou null uniquement sur ces orthographes exactes en minuscules. Tout le reste reste une chaîne, y compris FALSE, +1, 0x10 et tout entier dépassant la plage sûre, où la virgule flottante supprimerait silencieusement des chiffres. Une cellule vide est traitée comme un champ absent plutôt qu’une valeur vide, car CSV ne peut pas distinguer les deux et la lecture correspond à ce qu’une ligne presque toujours signifie dans un cas de données éparses.
- 02134 reste la chaîne « 02134 » ; 90210 devient le nombre 90210.
- true et false deviennent des booléens ; FALSE en majuscules reste une chaîne.
- Une cellule avec des sauts de ligne intégrés devient un bloc littéral YAML, afin que la structure des lignes survive.
- Les valeurs qui seraient relues comme des nombres sont émises avec des guillemets, ce qui permet un aller-retour sans perte.
Où ce convertisseur refuse de deviner
Les erreurs sont signalées avec un numéro de ligne et une raison plutôt que d’être masquées, car la transformation silencieuse est la seule erreur dont un outil de données ne peut pas se remettre. Trois situations reçoivent exactement ce traitement :
- Un champ entre guillemets non terminé — un guillemet double ouvert et jamais refermé — interrompt l’analyse à cette ligne.
- Une ligne dont le nombre de champs diffère de l’en-tête est toujours convertie, mais un avertissement nomme les lignes affectées et indique que les champs manquants sont traités comme absents et les excédents sont ignorés.
- Les noms de colonne dupliqués sont convertis avec la valeur la plus à droite qui l’emporte, et l’avertissement le précise — correspondant au comportement d’une importation de tableur.
Questions fréquentes
La conversion de CSV en YAML envoie-elle mon fichier quelque part ?
Non. L’analyse et la génération YAML s’exécutent toutes deux dans cet onglet de navigateur avec du JavaScript chargé une seule fois lorsque 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 refuserait toute demande sortante. Vous pouvez vérifier les deux affirmations dans DevTools : le panneau Network ne montre aucune demande lorsque vous convertissez.
Les en-têtes CSV deviennent-ils des clés YAML imbriquées ?
Chaque en-tête est décodé comme un chemin : les points séparent les clés de mappage et les crochets marquent les indices de tableau, donc address.city s’imbrique sous une clé address tandis que tags[0] crée une liste. La forme avec crochet n’est pas une décoration — tags.0 crée plutôt un mappage avec la clé de chaîne « 0 », car un point nu ne peut pas dire si le niveau inférieur est une liste ou un objet. Garder les deux orthographes distinctes est ce qui rend la convention réversible.
Que devient-il des nombres et des codes postaux dans les cellules ?
Une cellule devient un nombre uniquement lorsqu’elle correspond à la grammaire de nombre JSON, qui interdit les zéros initiaux — donc 02134 reste une chaîne tandis que 90210 devient un nombre. Les entiers au-delà de la plage sûre restent également des chaînes plutôt que de perdre des chiffres. Les booléens nécessitent les orthographes exactes en minuscules true et false, et null de même ; FALSE en majuscules reste visiblement la chaîne.
Pourquoi les cellules vides disparaissent-elles de la sortie YAML ?
Une cellule vide est émise comme une clé absente, pas une valeur vide. CSV n’a aucun moyen de distinguer un champ qui est vraiment vide d’un champ qu’une ligne n’a simplement pas, et la lecture correspondante correspond au cas épars qui se produit réellement — un enregistrement plus court que la ligne la plus large. Si un consommateur en aval a besoin que la clé soit présente, une cellule vide explicite entre guillemets est la façon de le demander.
Quel style d’indentation la sortie YAML utilise-t-elle ?
Deux espaces par niveau, la convention utilisée dans Kubernetes, CI et les fichiers Docker, avec les tirets de séquence alignés sur leur clé parente plutôt qu’indentés sous elle. Les cellules multi-lignes deviennent des blocs littéraux afin que les sauts de ligne intégrés survivent tels quels, et le document est émis sans un marqueur --- initial car un fichier mono-document n’en a pas besoin.
Quelle est la taille maximale de fichier CSV que cela peut gérer ?
La limite pratique est la mémoire de cet onglet, pas un plafond d’envoi — la zone de collage est l’entrée. Comme chaque outil à thread principal sur ce site, il y a un plafond documenté de 8 MB ; au-delà, le traitement est refusé avec un message clair plutôt que de geler la page. Pour des exports tabulaires typiques, cette marge de manœuvre permet des dizaines de milliers de lignes.
Quels outils liés devriez-vous utiliser ensuite ?
- YAML vers CSVConvertisseur qui fonctionne dans votre navigateurOuvrir
- Règles CSV RFC 4180Guide en langage clairOuvrir
- Les bases de YAMLGuide en langage clairOuvrir
- Convertir CSV en JSONLit un export de feuille de calcul, guillemets comprisOuvrir
- Convertir JSON en YAMLConvertit avec des guillemets qui résistent à l’aller-retourOuvrir
- Valider du JSONVérifie la syntaxe avec ligne et colonne exactes, puis répareOuvrir