Que sont ces formats de données ?

Les programmes stockent et échangent des données structurées, comme des paramètres, des enregistrements et des listes, dans des formats texte qui les représentent chacun à leur manière. Un convertisseur est utile lorsqu’un programme fournit des données dans un format qu’un autre ne peut pas lire, ou lorsqu’un format est plus facile à lire ou à modifier pour la tâche à effectuer.

Format Représentation des données Utilisation
JSON Objets entre accolades, listes entre crochets, texte entre guillemets doubles API web et paramètres d’application
YAML Lignes key: value indentées, éléments de liste commençant par - Docker Compose, Kubernetes et fichiers de pipeline CI
XML Éléments entre balises, pouvant contenir des attributs Documents, flux RSS et services web SOAP
TOML Lignes key = value sous des en-têtes [table] Fichiers de configuration comme Cargo.toml et pyproject.toml
TOON Lignes indentées, avec les listes d’enregistrements sous forme de lignes sous leurs champs Données structurées envoyées à des modèles de langage IA
CSV Une ligne d’en-tête, puis une ligne par enregistrement, les valeurs étant séparées par des virgules Feuilles de calcul et exports de bases de données
TSV Comme CSV, avec des tabulations entre les valeurs Cellules copiées depuis une feuille de calcul
MessagePack Données binaires, affichées ici sous forme d’octets hexadécimaux Messages compacts échangés entre programmes
JSON5 JSON qui autorise également les commentaires, les guillemets simples et les clés sans guillemets Fichiers de configuration rédigés à la main
JSONL Une valeur JSON par ligne, également appelé JSON Lines ou NDJSON Journaux et jeux de données
INI Lignes key = value sous des en-têtes [section] Fichiers de paramètres de programmes, comme php.ini
Properties Lignes key = value avec des clés séparées par des points Applications Java, comme les fichiers application.properties de Spring Boot

Description de l’outil

Cet outil convertit les données entre ces 12 formats : JSON, YAML, XML, TOML, TOON, CSV, TSV, MessagePack, JSON5, JSONL, INI et propriétés Java. Tous les convertisseurs de formats de données fonctionnent ici de la même manière, du convertisseur général de formats de données à ceux qui ne gèrent qu’une seule paire, comme JSON vers YAML, CSV vers JSON ou XML vers JSON : ils s’ouvrent sur les formats indiqués dans leur nom, et les menus Source et Cible permettent de choisir n’importe quel autre format. Collez ou saisissez vos données, et le résultat s’affiche à mesure que vous tapez dans un éditeur de code avec coloration syntaxique, prêt à être copié. Le bouton d’inversion inverse la conversion et utilise le résultat comme nouvelle entrée.

Si les données d’entrée ne sont pas valides dans le format source, le message d’erreur indique le problème, généralement avec la ligne et la colonne concernées.

Vos données sont converties dans votre navigateur et ne sont jamais téléversées.

Exemple

Ce JSON :

{
  "users": [
    { "id": 1, "name": "Ann", "admin": true },
    { "id": 2, "name": "Bo", "admin": false }
  ]
}

devient ce YAML :

users:
  - id: 1
    name: Ann
    admin: true
  - id: 2
    name: Bo
    admin: false

ce CSV, avec une ligne par utilisateur :

id,name,admin
1,Ann,true
2,Bo,false

et ce TOON :

users[2]{id,name,admin}:
  1,Ann,true
  2,Bo,false

Correspondance entre les formats

Les formats ne peuvent pas tous contenir les mêmes types de données ; certaines conversions suivent donc les règles suivantes :

  • CSV et TSV contiennent un tableau. La première ligne indique les noms des colonnes, et chaque ligne suivante devient un objet. Les objets imbriqués deviennent des colonnes nommées selon leur chemin, et les listes deviennent du texte JSON dans leur cellule : ainsi, {"name": "Ann", "address": {"city": "Oslo"}, "tags": ["a", "b"]} devient les colonnes name, address.city et tags. Lors de la conversion inverse, ces colonnes redeviennent des objets et des listes imbriqués. Lorsque les données sont un objet contenant une seule liste, comme {"users": [...]}, les lignes correspondent aux éléments de cette liste, et une liste de listes devient des lignes sans en-tête.
  • Valeurs textuelles : CSV, TSV, XML, INI et properties ne contiennent que du texte. Les convertisseurs transforment donc true et false en valeurs booléennes, et les nombres écrits sous leur forme simple, comme 42 ou 3.5, en nombres. Les valeurs comme 007, 1.50 ou 1e3 restent du texte, afin que les codes postaux et les numéros de version conservent leur forme exacte.
  • Les attributs XML deviennent des clés commençant par @, et le texte d’un élément qui possède des attributs devient #text : <price currency="USD">44.95</price> devient {"@currency": "USD", "#text": 44.95}. Les éléments répétés deviennent une liste. Lors de la conversion vers XML, les clés commençant par @ redeviennent des attributs. Un objet comportant une seule clé dont la valeur n’est pas une liste devient l’élément racine. Les autres données sont placées dans un élément <root>, chaque élément d’une liste de premier niveau étant placé dans un élément <item>. Les caractères interdits dans les noms XML, comme les espaces, sont remplacés par _.
  • TOML, INI et properties ne peuvent contenir que des valeurs nommées au niveau supérieur. Les données constituées d’une liste sont donc écrites sous le nom items, et une valeur unique sous le nom value. TOML ne prend pas en charge les valeurs nulles : celles-ci sont donc omises.
  • INI représente les objets imbriqués sous forme de sections, comme [server.ssl], les listes de valeurs sous forme de lignes key[] = value, et les listes d’objets sous forme de sections nommées selon leur position, comme [users.0].
  • Les clés properties relient les noms imbriqués par des points et indiquent les éléments de liste entre crochets, comme app.hosts[0], à la manière de Spring Boot. Lorsqu’elles sont converties en YAML ou en JSON, ces clés deviennent des objets et des listes imbriqués ; un fichier application.properties adopte donc la structure d’un fichier application.yml. Les caractères hors de Latin-1 sont écrits sous forme de séquences d’échappement \u.
  • Les résultats YAML placent entre guillemets les textes que les lecteurs YAML 1.1 interpréteraient autrement, comme on, yes ou une date, afin que les lecteurs YAML 1.1 et YAML 1.2 obtiennent les mêmes données. Un fichier YAML contenant plusieurs documents séparés par --- devient une liste de ces documents, et les clés de fusion << sont développées.
  • MessagePack étant un format binaire, les outils le lisent et l’écrivent sous forme d’octets hexadécimaux : {"a": 1} devient 81 A1 61 01. L’entrée peut contenir des espaces, des virgules et le préfixe 0x devant chaque octet. Plusieurs messages à la suite deviennent une liste.
  • Dans les résultats JSONL, chaque élément de la liste figure sur sa propre ligne.
  • Les nombres entiers trop grands pour être représentés par les nombres JavaScript, comme les identifiants sur 64 bits, conservent tous leurs chiffres.
  • Les dates et heures TOML, ainsi que les horodatages MessagePack, deviennent du texte, par exemple 1979-05-27T07:32:00Z.

Conseils

  • Pour convertir des cellules d’une feuille de calcul, copiez-les et collez-les sous forme de TSV : les applications de tableur copient les cellules sous forme de texte séparé par des tabulations.
  • CSV et TSV conviennent aux données constituées d’une liste d’enregistrements similaires. Les données profondément imbriquées sont plus faciles à lire en YAML, TOML ou TOON.
  • Les commentaires des fichiers YAML, XML, TOML, JSON5, INI et properties ne sont pas conservés, car les convertisseurs ne reprennent que les données.