Convertisseur JSON / CSV / YAML / SQL / XML

Non. Les données sont analysées et converties dans votre navigateur en JavaScript, et l’outil ne les envoie pas à LeedyBox et ne les enregistre pas. À son ouverture, la page charge deux bibliothèques open source depuis leedybox.com même, js-yaml pour le YAML et PapaParse pour le CSV ; elles s’exécutent dans la page, et vos données ne sont envoyées nulle part.

Une entrée qui commence par { ou [ est lue comme du JSON, une entrée qui commence par < comme du XML, et une entrée qui commence par un mot-clé SQL comme INSERT, CREATE, SET, START, UPDATE ou WITH suivi d’une espace, ou par un commentaire -- ou /*, comme du SQL. Toute autre entrée est essayée comme du CSV si sa première ligne contient une virgule, une tabulation ou un point-virgule, puis comme du YAML. Choisissez vous-même le format dans le menu « Entrée » dans les cas suivants : lorsqu’un CSV ou un YAML commence par un mot qui est aussi un mot-clé SQL, par exemple une ligne d’en-tête CSV qui commence par Start date ou Update time, car l’entrée est alors lue comme du SQL et échoue ; lorsque chaque ligne d’une entrée YAML contient le même nombre de virgules, comme title: Hello, world suivi de tags: news, tech, car elle peut alors être lue comme du CSV ; pour un CSV délimité par des barres verticales ou à une seule colonne, que la détection automatique ne reconnaît pas ; et lorsqu’une entrée YAML ou CSV échoue, car la détection automatique indique alors seulement que le format n’a pas été reconnu, alors qu’un format choisi affiche l’erreur de l’analyseur lui-même et, dans la plupart des cas, l’endroit où elle s’est produite.

Lorsque le menu « Entrée » est réglé sur JSON, seul du JSON valide est accepté : utilisez donc ce réglage avec « Valider la syntaxe » pour vérifier que le texte est du JSON valide. Avec « Détection automatique », une entrée qui commence par { ou [ mais qui n’est pas du JSON valide est lue, si possible, comme de la syntaxe YAML en flux, et une remarque le signale : les virgules finales, les guillemets simples et les clés sans guillemets fonctionnent alors, mais les deux-points d’une clé sans guillemets doivent être suivis d’une espace, car {a:1} est lu comme une clé nommée a:1 avec la valeur null. Les commentaires // et /* */ ne sont pas des commentaires en YAML ; ils peuvent se retrouver dans des clés ou des valeurs, ou empêcher la lecture de l’entrée : supprimez-les d’abord. JSON Lines (NDJSON) est proposé comme format de sortie, mais n’est pas lu en entrée lorsqu’il comporte plus d’une ligne ; placez les lignes entre [ et ], avec une virgule après chaque ligne sauf la dernière.

Les valeurs YAML sans guillemets qui ressemblent à des nombres sont lues comme des nombres : une version comme 1.10 devient 1.1, un code postal comme 01234 devient 1234, et 0x1F devient 31 ; mettez ces valeurs entre guillemets dans le YAML pour les conserver sous forme de texte. Le convertisseur lit le YAML avec le schéma core de js-yaml, qui suit YAML 1.2 pour les booléens et les dates : yes, no, on, off et les dates comme 2026-10-02 restent donc du texte, et seules les formes de true et false, comme True ou FALSE, deviennent des booléens. Lors de la conversion de JSON en YAML, les chaînes qui pourraient être mal interprétées, comme "01234", "1.10" ou "yes", sont écrites entre guillemets.

Les éléments enfants qui se répètent sous un même parent deviennent un tableau, mais un élément unique devient une simple valeur ou un objet : <items> avec un seul <item> donne donc une structure différente de <items> avec deux. Toutes les valeurs XML sont lues comme du texte : <id>1</id> devient "1" et 007 garde ses zéros, tandis que les commentaires et les instructions de traitement sont supprimés. Pour une sortie CSV ou SQL, les lignes sont tirées d’un tableau situé dans des enveloppes à clé unique comme <items> : avec un seul <item>, l’élément entier se retrouve donc sous forme de texte JSON dans une seule colonne ; pour le CSV, « Aplatir (colonnes a.b.c) » le répartit en colonnes.

Oui, à condition que les lignes figurent dans des instructions INSERT INTO ... VALUES. CREATE TABLE, SET, LOCK et les instructions de préparation similaires sont ignorées, les autres instructions, comme DROP TABLE, sont écartées avec une remarque, et les lignes de plusieurs tables sont fusionnées en une seule liste : collez une table à la fois si leurs colonnes diffèrent. Par défaut, mysqldump omet les noms de colonnes : les colonnes sont alors nommées column1, column2, etc., sauf si vous faites le dump avec --complete-insert. Par défaut, pg_dump écrit les lignes sous forme de blocs COPY, que l’outil ne lit pas : faites plutôt le dump avec --column-inserts. Si le dump contient aussi des fonctions ou des procédures stockées, collez uniquement les instructions INSERT : l’outil découpe l’entrée aux points-virgules, si bien qu’un INSERT placé dans le corps d’une fonction peut être lu comme des données ou interrompre la conversion.

Chaque valeur CSV est traitée comme du texte, ce qui conserve les zéros initiaux comme dans 01234, mais transforme 42 en "42" en JSON et en '42' en SQL ; une cellule vide devient une chaîne vide plutôt que null ou NULL. Le type de chaque colonne est choisi d’après les valeurs de cette colonne : une table créée à partir d’un CSV reçoit donc des colonnes de texte, VARCHAR(255), ou TEXT lorsqu’une valeur dépasse 255 caractères (NVARCHAR(255) ou NVARCHAR(MAX) pour SQL Server, TEXT pour SQLite). Lorsque l’entrée est du JSON ou du YAML et que toutes les valeurs d’une colonne sont des nombres sans guillemets, ou qu’elles valent toutes true ou false, la colonne reçoit à la place un type numérique ou booléen : un type entier (INT, INTEGER ou BIGINT, selon la base de données et la taille des nombres), un type à virgule flottante pour les nombres décimaux, ou BOOLEAN (BIT pour SQL Server, INTEGER pour SQLite). L’instruction ne comporte ni clé primaire, ni index, ni contraintes NOT NULL : ajoutez-les avant de l’exécuter si votre table en a besoin.