Aller au contenu principal
ToolsByUs

JSON vers SQL INSERT

Cet convertit écrit des instructions SQL INSERT à partir d’un tableau JSON d’enregistrements dans votre navigateur. Les noms de colonne sont mis entre guillemets doubles, les chaînes de caractères sont échappées en doublant les guillemets simples, null devient NULL, et les booléens deviennent TRUE ou FALSE. Les enregistrements doivent partager un ensemble de clés ; rien ne quitte l’onglet.

100 % local

JSON vers SQL INSERT en clair

Les données de référence vivent en JSON — fixtures d’API, rapports exportés, enregistrements de test — mais la base de données veut des instructions INSERT. La conversion est mécanique et mérite d’être précise : chaque enregistrement devient une ligne, chaque clé devient une colonne, et chaque valeur doit arriver comme une littérale SQL correctement typée. Un échappement incorrect et l’instruction échoue immédiatement ; un échappement subtilement incorrect et elle échoue trois semaines plus tard, sur le premier prénom contenant une apostrophe.

Ce convertit émet des instructions INSERT multi-lignes : une liste de colonnes entre guillemets doubles, puis un tuple VALUES par enregistrement. Les guillemets doubles sont la norme SQL pour les identifiants, et les chaînes de caractères entre guillemets simples ont toute apostrophe incorporée doublée — la forme O''Brien que chaque analyseur conforme lit comme une apostrophe littérale. Les nombres restent nus, true et false deviennent TRUE et FALSE, et le JSON null devient le mot-clé non mis entre guillemets NULL. Vous nommez la table cible dans le champ table de l’outil ; l’exemple ci-dessous utilise people.

Tout cela se produit dans cet onglet de navigateur. Vos enregistrements sont analysés avec le JSON.parse du navigateur, le texte SQL est assemblé en mémoire, et aucune requête ne quitte la page — le panneau Réseau de DevTools ne montre rien pendant une conversion, et la Content-Security-Policy du site interdit les connexions sorties de toute façon.

Si vos lignes proviennent d’un export de tableur plutôt que de JSON, le convertisseur CSV vers SQL applique les mêmes règles de mise entre guillemets par-dessus un analyseur RFC 4180 avec inférence de type par cellule.

Le convertit n’accepte qu’un tableau JSON strict, donc si la charge provient d’un script ou d’un fichier journal, vérifiez-la avec le validateur JSON d’abord ; l’erreur que vous voyez là est l’erreur que cet outil leverait.

Comment la conversion fonctionne réellement

Le moteur analyse votre JSON avec JSON.parse — l’analyseur RFC 8259 du navigateur lui-même — puis effectue trois vérifications avant d’émettre quoi que ce soit, car chaque mode d’échec produit du SQL soit invalide, soit incorrect silencieusement :

  • Forme : le niveau supérieur doit être un tableau dont chaque élément est un objet ; un objet seul ou un tableau imbriqué est refusé avec un message nommant l’index problématique.
  • Clés cohérentes : chaque enregistrement doit avoir le même ensemble de clés. Une instruction INSERT déclare une seule liste de colonnes, donc un enregistrement portant une clé que les autres n’ont nulle part où aller — le convertit signale la clé et la ligne au lieu d’inventer des NULL que vous n’avez pas demandés.
  • Valeurs plates : les objets et tableaux imbriqués dans un enregistrement n’ont pas d’équivalent littéral SQL simple, donc ils sont refusés avec le chemin nommé, plutôt que transformés en chaîne à votre insu.

Le mappage littéral

Chaque valeur est rendue selon son type JSON, en n’utilisant que des formes SQL standard :

  • Une note de typification mérite sa propre ligne : TRUE et FALSE sont des littéraux booléens standard SQL, lus nativement par PostgreSQL et SQLite et lus comme 1 et 0 par MySQL. Moteurs sans littéraux booléens — les colonnes BIT de SQL Server, par exemple — veulent 1 et 0 dans l’instruction, donc pour ces cibles remplacez les mots-clés ; les règles de mise entre guillemets et de NULL restent exactement les mêmes.
Valeur JSONLittéral SQL
"Ada Lovelace"'Ada Lovelace'
"O’Brien"'O''Brien' — l’apostrophe est doublée
nullNULL, non mis entre guillemets
true / falseTRUE / FALSE
9.59.5, un nombre nu
[1, 2]Refusé, avec le chemin nommé

À quoi ressemble la sortie

L’exemple ci-dessous est le couple exact que le bouton Charger l’exemple du convertit produit pour une table nommée people : deux enregistrements, quatre clés cohérentes, et un de chaque littéral intéressant. Le nom du deuxième enregistrement contient une apostrophe, et la sortie montre la défense standard — l’apostrophe est doublée, que chaque dialecte SQL lit comme une seule apostrophe littérale plutôt que la fin de la chaîne. Son score est null et atterrit comme le mot-clé NULL, pas une chaîne vide — la différence entre une mesure manquante et une de longueur nulle. Copiez le bloc tel quel ou téléchargez-le comme fichier .sql ; de toute façon, c’est un script complet et terminé.

Obtenir les instructions dans votre base de données

La sortie est un script complet et terminé : collez-le dans une console SQL, ou enregistrez-le comme fichier .sql pour un exécuteur de migrations. Pour un chargement propre, entourez-le d’une transaction — BEGIN ; avant, COMMIT ; après — afin qu’un échec en milieu de script annule toute la graine au lieu de laisser une demi-table derrière lui. Comme les instructions n’utilisent que des formes SQL standard, le même fichier s’exécute sans modification sur PostgreSQL, SQLite et MySQL avec ANSI_QUOTES activé ; seule la note sur les booléens ci-dessus a besoin d’être adaptée pour un moteur spécifique.

  • psql : collez dans le shell interactif, ou exécutez \i seed.sql depuis le prompt.
  • sqlite3 : exécutez .read seed.sql, ou pipez le fichier depuis votre shell.
  • Outils GUI : la plupart des fenêtres de requête acceptent le script entier comme un lot et rapportent le nombre de lignes.

Questions fréquentes

Le convertisseur JSON vers SQL envoie-t-il mes données ?

Non. L’analyse et la génération SQL s’exécutent dans cet onglet de navigateur avec JavaScript chargé une seule fois à l’ouverture de la page. La page n’a pas d’endpoint pour poster des données, et sa Content-Security-Policy bloque les requêtes sortantes. L’affirmation est vérifiable : ouvrez DevTools, passez au panneau Réseau, convertissez un gros fichier, et observez qu’aucune requête n’apparaît.

Pourquoi les noms de colonne sont-ils entourés de guillemets doubles ?

Les identifiants entre guillemets doubles sont la norme SQL, et ils protègent les noms de colonne qui entrent en collision avec des mots-clés ou mélangent les cas — une colonne nommée order ou UserName a besoin d’être mise entre guillemets pour survivre. PostgreSQL, SQLite et SQL Server les acceptent directement ; MySQL aussi en mode ANSI_QUOTES, sinon utilisez son équivalent avec les backticks.

Les guillemets simples à l’intérieur des chaînes sont-ils échappés comment ?

En les doublant, qui est la norme : le nom O’Brien est émis comme 'O''Brien', et chaque analyseur conforme lit le couple comme une seule apostrophe littérale. L’échappement avec antislash — comme dans O\'Brien — est une extension MySQL et produit une erreur de syntaxe ou un antislash errant partout ailleurs, c’est pourquoi ce convertit ne l’émet pas.

Que devient le JSON null dans le SQL ?

Le mot-clé non mis entre guillemets NULL — le propre marqueur de SQL pour une valeur absente, distinct de la chaîne vide ''. Un score null signifie qu’aucune mesure n’a été prise ; une chaîne vide signifie une mesure de longueur nulle. Le convertit préserve cette distinction, car réduire les deux est l’une des erreurs les plus difficiles à annuler dans une table peuplée.

Pourquoi chaque enregistrement doit-il avoir les mêmes clés ?

Parce qu’une instruction INSERT déclare sa liste de colonne une seule fois, et chaque tuple VALUES doit remplir exactement ces colonnes. Un enregistrement manquant une clé, ou en portant une en plus, n’a pas de défini dans cette liste. Le convertit signale la clé problématique et l’indice de ligne pour que vous puissiez normaliser les enregistrements d’abord — comblant délibérément les lacunes avec null si c’est ce que vous prévoyez.

Pourquoi un INSERT multi-lignes plutôt qu’une instruction par ligne ?

Moins d’instructions, une seule analyse, et typiquement un chargement beaucoup plus rapide — un seul INSERT multi-lignes est la forme que la plupart des guides de chargement en masse recommandent pour l’alimentation. La sortie se termine par un point-virgule pour être un script complet, et si vos outils préfèrent une instruction par ligne, chaque tuple VALUES est sur sa propre ligne, donc le découper est une petite modification mécanique.

Équipe ToolsByUs · Comment nous vérifions nos outils