CSV en SQL INSERT

Comment ça marche

Collez le tableau CSV dans le panneau de gauche ; les instructions INSERT se forment à droite pendant que vous tapez. La première ligne est lue comme en-tête et ses cellules deviennent la liste de colonnes : un export client de 120 lignes donne 120 INSERT au moment où vous le collez. Les noms de colonnes sont adaptés au SQL — « prénom » devient prenom, car un accent ou une espace dans un identifiant écrit sans guillemets casse l'instruction ; les lettres accentuées passent à leur équivalent ASCII, ce qui ne s'y prête pas devient un tiret bas, un nom qui commence par un chiffre reçoit un tiret bas devant, et la ligne de résultat compte les noms modifiés. Pour les valeurs, la règle est fixe : le texte est mis entre apostrophes, une apostrophe dans le texte est doublée ('l''école'), la cellule vide devient NULL et les nombres restent nus. Les champs CSV entre guillemets sont lus correctement : une cellule qui contient une virgule ou un retour à la ligne reste une seule cellule tant qu'elle est entourée de guillemets doubles. En détection automatique, le séparateur n'est pas deviné sur la seule première ligne mais sur plusieurs : le candidat qui donne partout le même nombre de colonnes l'emporte. Les trois fins de ligne sont reconnues — le CR+LF de Windows, le LF de macOS et Linux et le CR seul de très vieux programmes, que beaucoup d'outils prennent pour une unique longue ligne. Si une ligne compte plus de cellules que l'en-tête, la conversion s'arrête en indiquant la ligne de données et le nombre de cellules — c'est presque toujours un séparateur non mis entre guillemets. Copiez la sortie ou téléchargez le fichier .sql et exécutez-le dans votre client de base de données.

Cet outil est aussi connu sous le nom de csv vers sql, convertir csv en sql, csv to sql, insert into depuis un fichier csv.

Qu'est-ce que Instruction INSERT ?

INSERT est la commande SQL qui ajoute une nouvelle ligne à une table, et elle se compose de trois parties : la table visée, les colonnes à remplir et les valeurs. INSERT INTO client (nom, ville) VALUES ('Marie', 'Lyon') montre les trois. La liste de colonnes est facultative dans la norme, mais l'écrire devrait être un réflexe : sans elle, les valeurs se rangent selon l'ordre des colonnes de la table, et le jour où quelqu'un ajoute une colonne, les anciennes instructions se mettent à écrire au mauvais endroit sans prévenir. Cet outil écrit toujours la liste de colonnes.

Qu'est-ce que NULL ?

NULL est la marque du « pas de valeur » en SQL, distincte à la fois du zéro et de la chaîne vide. La différence se voit dans les comparaisons : rien n'est égal à NULL, pas même NULL, c'est pourquoi on cherche les enregistrements vides avec IS NULL et non avec le signe égal ; la plupart des fonctions d'agrégation ignorent en outre les lignes NULL au lieu de les compter comme zéro. Dans un export CSV, une cellule vide veut généralement dire « information non saisie », et c'est pour cela que cet outil écrit NULL plutôt qu'une chaîne vide entre apostrophes.

Qu'est-ce que Échappement de l'apostrophe ?

L'échappement consiste à neutraliser, à l'intérieur d'une valeur, le caractère que le langage utilise comme délimiteur. En SQL, ce caractère est l'apostrophe : elle ouvre et ferme les valeurs texte, donc chaque apostrophe interne doit être écrite deux fois. C'est le mécanisme prévu par la norme et il se comporte à l'identique dans MySQL, PostgreSQL, SQLite et SQL Server ; l'échappement par barre oblique inverse, lui, est un comportement propre à MySQL et n'est pas portable. Quand le doublement manque, le symptôme est toujours le même : chaque enregistrement contenant une apostrophe échoue ou arrive tronqué dans la table.

Quelle différence entre un INSERT par ligne et un INSERT groupé ?

Les deux écrivent les mêmes lignes dans la même table ; la différence tient à la vitesse et au comportement en cas d'erreur. Avec une instruction par ligne, la base analyse chaque instruction séparément, ce qui est sensiblement plus lent sur des dizaines de milliers de lignes — mais une ligne au type incompatible ou à la clé en double échoue seule, les autres sont écrites, et la ligne fautive se retrouve facilement dans le message d'erreur. Avec un seul INSERT portant plusieurs VALUES, l'analyse se fait une fois et l'aller-retour vers le serveur est unique : le chargement en masse est plusieurs fois plus rapide. Le prix : l'instruction forme un tout, et une seule ligne défectueuse peut faire rejeter le bloc entier. Règle pratique : chargez ligne par ligne les données non vérifiées, et en une seule instruction les données déjà validées.

Pourquoi l'apostrophe est-elle doublée ?

En SQL, une valeur texte s'écrit entre apostrophes. Quand la valeur en contient une elle-même — et le français en est plein : l'école, d'Artagnan, aujourd'hui —, la base de données lit cette apostrophe comme la fin du texte et tente d'interpréter la suite comme des commandes. Résultat : une erreur de syntaxe, ou pire, un enregistrement tronqué.

La solution de la norme est le doublement : chaque apostrophe interne est écrite deux fois et la base la relit comme un seul caractère. Cet outil applique ce doublement à toutes les valeurs. Le doublement n'est pas l'échappement par barre oblique inverse, et la préférence a une raison concrète : la barre oblique inverse est un comportement par défaut de MySQL, pas une norme ; le doublement fonctionne à l'identique dans tous les moteurs.

Ce qui change selon la base : MySQL, PostgreSQL, SQLite

Le SQL produit est volontairement sobre pour tourner sur les trois systèmes. Voici les différences à connaître avant d'exécuter la sortie :

• Dates et heures : les valeurs sont écrites comme texte. PostgreSQL n'accepte pas d'office l'écriture 24/08/2026 ; selon le type de colonne, une conversion (TO_DATE) peut être nécessaire — l'écriture ISO 2026-08-24 passe partout
• Barre oblique inverse : MySQL la traite par défaut comme caractère d'échappement, PostgreSQL et SQLite non. Si vos données contiennent des chemins de fichiers, vérifiez la sortie d'abord sur MySQL
• Guillemets d'identifiants : MySQL utilise l'accent grave, PostgreSQL et SQLite le guillemet double. Les noms étant réduits ici aux lettres ASCII, chiffres et tirets bas, la sortie n'a besoin d'aucun guillemet et tourne sur les trois
• Booléens : true et false sont mis entre apostrophes comme texte. SQLite n'a pas de type booléen et MySQL attend 1/0 ; convertissez ces colonnes après le chargement si besoin
• Séparateur décimal : 1250.50 devient un nombre nu ; 1.234 et 1.250,50 restent du texte entre apostrophes, car exactement trois chiffres après le signe peuvent être un groupe de milliers aussi bien qu'une décimale — deviner ferait varier le montant d'un facteur mille. L'écriture décimale à virgule (1,25) est convertie en écriture à point, la seule que le SQL reconnaît

Quel réglage pour quel travail ?

Les cinq réglages se choisissent d'après l'endroit où la sortie sera exécutée ; les valeurs par défaut couvrent le cas le plus courant.

• Quelques centaines de lignes vers une base de test → un INSERT par ligne (si une ligne échoue, les autres passent)
• Des dizaines de milliers de lignes vers la production → un seul INSERT, plusieurs VALUES, nettement plus rapide
• Toutes les colonnes sont en VARCHAR ou TEXT → tout entre apostrophes
• Téléphones, codes postaux, numéros de dossier → l'outil les met déjà entre apostrophes (zéro initial ou plus de 15 chiffres restent du texte) ; si la colonne entière est en VARCHAR, « tout entre apostrophes » reste le choix le plus net
• Données copiées depuis Excel → réglez le séparateur sur point-virgule ou tabulation ; corrigez à la main si la détection automatique se trompe
• Export sans en-tête → choisissez « pas de noms de colonnes » ; les colonnes s'appellent c1, c2 et se renomment dans la sortie

Cet outil ne génère pas de CREATE TABLE

La sortie ne contient que des INSERT ; la table est supposée exister déjà dans la base. C'est un choix d'honnêteté : deviner les types de colonnes à partir d'un CSV est risqué. Une colonne de chiffres a l'air numérique mais peut être un code postal, un champ de 12 chiffres peut déborder d'un entier, et deux lignes de dates peuvent être suivies d'une troisième en texte libre.

Un type mal deviné produit une table d'apparence correcte qui perd des données en silence — les zéros initiaux effacés en sont l'exemple classique. En créant la table vous-même, vous choisissez chaque type en connaissance de cause ; cet outil y transporte ensuite les lignes avec l'échappement fait correctement.

Questions fréquentes

Comment générer des INSERT SQL à partir d'un fichier CSV ?

Collez le tableau CSV dans le panneau de gauche et saisissez le nom de la table cible ; les instructions apparaissent aussitôt à droite. Copiez-les ou téléchargez un fichier .sql et exécutez-le dans votre client de base de données. La table doit exister au préalable.

Les valeurs avec apostrophe posent-elles problème ?

Non. L'apostrophe d'une valeur comme l'école ou O'Brien est doublée comme l'exige la norme SQL, et la base la relit comme un seul caractère. Sans doublement, l'instruction se couperait à cet endroit précis et finirait en erreur ou en donnée tronquée.

Une cellule vide devient-elle NULL ou une chaîne vide ?

Elle devient NULL, car dans un export CSV une cellule vide signifie presque toujours « aucune valeur fournie ». S'il vous faut réellement des chaînes vides, chargez d'abord les lignes puis exécutez une mise à jour ciblée sur cette colonne.

Les colonnes de dates sont-elles transférées correctement ?

Les dates sont mises entre apostrophes telles quelles, comme texte. Si la colonne cible est de type date, le format doit être accepté par la base : l'écriture ISO (2026-08-24) est lue par les trois moteurs, l'écriture 24/08/2026 demande le plus souvent une conversion.

Le tableau que je colle est-il envoyé à un serveur ?

Non. La lecture du CSV et la génération du SQL tournent entièrement dans votre navigateur ; liste de clients, relevé de prix ou tableau du personnel, rien ne quitte cette page et rien n'est enregistré.