Aller au contenu principal

CSV vers SQL INSERT

Ce convertit lit un CSV RFC 4180 dans votre navigateur et écrit des instructions SQL INSERT. Chaque cellule est typée par inspection — les nombres non entre guillemets restent des nombres, true et false deviennent TRUE et FALSE, le reste est une chaîne de caractères avec des guillemets simples et échappée. Les noms d’en-tête deviennent des identifiants de colonne entre guillemets doubles ; rien n’est envoyé.

100 % local

CSV vers SQL INSERT en clair

Le CSV n’a pas de types. Tout dans un export de tableur est du texte, et la base de données est celle qui décide ce qu’une valeur signifie — ce qui rend la conversion CSV-vers-SQL celle où le typage est fait pour vous, que vous y ayez réfléchi ou non. Ce convertisseur le fait par cellule et expose clairement ses règles : une cellule qui se lit comme un nombre devient un nombre, true ou false devient TRUE ou FALSE, une cellule vide devient NULL, et le reste est une chaîne.

Du côté SQL, on utilise les défenses standards et rien d’exotique : les noms d’en-tête deviennent des identifiants de colonne entre guillemets doubles, les valeurs chaîne sont enveloppées de guillemets simples avec des guillemets embarqués doublés — la forme O''Brien que chaque dialecte SQL lit correctement — et les lignes sont émises comme une seule instruction INSERT multi-lignes. L’analyse est stricte RFC 4180, donc les champs cités avec des virgules ou des sauts de ligne embarqués survivent intacts, ce qui est précisément là où les convertisseurs rapides qui divisent sur la virgule corrompent vos données.

La conversion s’exécute entièrement dans cet onglet de navigateur. Le CSV est parsé par le code de la page, le SQL est assemblé en mémoire, et aucune requête ne quitte la page — le panneau Réseau dans DevTools reste vide pendant que vous travaillez, et la politique de sécurité de contenu du site interdit les connexions sortantes.

Si vos enregistrements possèdent déjà des types — d’une API ou d’un export qui les a conservés — le Convertisseur JSON vers SQL les prend tels quels au lieu d’inférer, avec les mêmes règles de guillemets et de NULL.

Vous voulez les données sous forme de JSON plutôt que SQL ? Le Convertisseur CSV vers JSON utilise le même parseur RFC 4180 et vous donne des enregistrements typés au lieu d’instructions.

Comment la conversion fonctionne réellement

Le moteur analyse votre CSV selon les règles réelles de RFC 4180 — enregistrements, champs, guillemets doublés à l’intérieur des champs cités, fins de ligne CRLF ou LF — puis traite le premier enregistrement comme l’en-tête et chaque enregistrement suivant comme une ligne de l’INSERT. Le typage est appliqué par cellule, juste avant l’émission :

Deux détails des exports réels de tableur sont gérés plutôt que subis : un marqueur d’ordre d’octets UTF-8 au début du fichier, qu’Excel ajoute par défaut, est supprimé avant l’analyse, et le nom de table que vous tapez dans le champ de l’outil devient l’identifiant cité dans l’INSERT — l’exemple ci-dessous utilise products.

  • Nombres : une cellule correspondant à un motif d’entier ou de décimal est émise sans guillemets — 42 et 24.99 deviennent des nombres. Un zéro en tête la disqualifie, donc 02134 reste une chaîne et vos codes postaux survivent.
  • Booléens : true ou false, dans n’importe quelle casse, deviennent TRUE ou FALSE.
  • Cellules vides : un champ vide devient NULL. Un champ présent mais vide entre guillemets ("") reste une chaîne vide, car RFC 4180 et SQL distinguent les deux.
  • Chaînes : tout le reste est entre guillemets simples avec les guillemets embarqués doublés — O’Brien devient 'O''Brien'.
  • Identifiants : les noms d’en-tête sont émis comme des noms de colonne entre guillemets doubles, dans l’ordre de l’en-tête.

Le mappage cellule vers littéral

Une ligne par règle, pour que vous puissiez prédire la sortie avant de l’exécuter. Notez que la cellule vide et la cellule vide entre guillemets sont délibérément deux lignes différentes de ce tableau, car ce sont les cas que les gens interrogent le plus souvent :

Cellule CSVLittéral SQLPourquoi
4242Motif entier
24.9924.99Motif décimal
trueTRUEMotif booléen, toute casse
(vide)NULLValeur absente
02134'02134'Zéro en tête conservé — code postal
O’Brien'O''Brien'Guillemet doublé selon la norme

À quoi ressemble la sortie

L’exemple ci-dessous est la paire exacte que le bouton Charger l’exemple du convertisseur produit pour une table nommée products. Trois lignes, chacune testant une règle : le prix de la lampe de bureau est un décimal nu et son indicateur de stock TRUE nu ; la ligne de tente a nécessité des guillemets RFC 4180 dans le CSV car le nom de produit contient une virgule, et le SQL émis double son apostrophe ; la ligne de lanterne laisse deux cellules vides et les deux deviennent NULL, pas des chaînes vides. Enregistrez la sortie comme un fichier .sql et il s’exécute tel quel dans psql, sqlite3 ou n’importe quel outil de migration — l’instruction est complète et terminée par un point-virgule.

Lignes incomplètes et autres refus honnêtes

RFC 4180 autorise techniquement des enregistrements avec plus ou moins de champs que l’en-tête, mais SQL non — un tuple INSERT doit remplir exactement les colonnes que son instruction déclare. Ainsi deux entrées sont refusées avec un message indiquant la ligne, plutôt que complétées ou tronquées :

  • Un enregistrement dont le nombre de champs diffère de l’en-tête — compléter avec NULL inventerait des valeurs que vous n’avez jamais mesurées, et supprimer des champs supprimerait des données que vous avez fournies.
  • Des noms d’en-tête en double — deux colonnes avec le même nom ne peuvent pas toutes les deux être des identifiants cités dans un seul INSERT, donc le convertisseur signale la colonne au lieu de renommer l’une d’entre elles silencieusement.

Questions fréquentes

Mon CSV est-il envoyé lorsque je le convertis en SQL ?

Non. Le parseur et l’écrivain SQL s’exécutent tous les deux dans cet onglet de navigateur, en JavaScript qui a été chargé lorsque la page s’est ouverte. Il n’y a pas de route d’envoi, et la politique de sécurité de contenu empêche la page de se connecter vers l’extérieur. Vérifiez-le vous-même dans DevTools : le panneau Réseau ne montre aucun trafic pendant que la conversion s’exécute, même pour les gros fichiers.

Quel dialecte CSV le parseur accepte-t-il ?

RFC 4180, la norme : champs délimités par des virgules, échappement avec des guillemets doubles, guillemets doublés à l’intérieur des champs cités, et virgules ou sauts de ligne embarqués dans les champs cités sont tous analysés correctement. Les fins d’enregistrement CRLF et LF nues sont acceptées. Ce qu’il ne fait pas, c’est deviner — les fichiers délimités par des points-virgules ou des tabulations sont rejetés avec un message, car un convertisseur qui échange silencieusement les délimiteurs corrompt les colonnes qu’il ne voit pas.

Comment l’inférence de type décide-t-elle entre nombre, booléen et chaîne ?

Par cellule, contre des motifs stricts : un champ est un nombre seulement s’il correspond exactement à un littéral entier ou décimal, un booléen seulement s’il se lit true ou false dans n’importe quelle casse, et NULL seulement si le champ est vide. Tout le reste est émis comme une chaîne entre guillemets. La stricte est le point — un convertisseur qui tape agressivement des valeurs comme 007 donnera des surprises à votre base de données.

Pourquoi mon code postal ou mon code produit est-il resté une chaîne ?

Parce qu’il devrait l’être. Un code comme 02134 ou 007 porte une information dans ses zéros en tête, et un nombre n’a nulle part pour les conserver. Le motif d’inférence refuse les zéros en tête volontairement, donc de telles cellules sont émises comme des chaînes entre guillemets et la signification de la colonne survit intacte dans la base de données.

Que devient-il des dates dans le CSV ?

Elles arrivent comme des chaînes entre guillemets, par conception. Les littéraux de date SQL diffèrent selon les dialectes, et un convertisseur qui réécrit 2024-01-05 en une forme spécifique au dialecte modifie vos données. La chaîne atteint la base de données intacte ; une colonne DATE, ou le propre cast de la base de données, applique le type à l’insertion — ce qui est le seul endroit où cette décision appartient.

Puis-je obtenir une instruction INSERT par ligne ?

La sortie est un seul INSERT multi-lignes — une analyse, une instruction transactionnelle compatible, et la forme recommandée par les guides de chargement en masse. Les tuples VALUES sont placés un par ligne sous la liste des colonnes, donc si vos outils nécessitent des instructions mono-ligne, le fractionnement est une modification mécanique : copiez la liste des colonnes et terminez chaque tuple par un point-virgule.