Convertisseur CSV vers SQL
Téléchargez un fichier CSV ou collez des données pour les convertir en requêtes SQL INSERT
Déposez un fichier CSV ici ou cliquez pour sélectionner
Qu'est-ce que CSV vers SQL ?
CSV vers SQL est un outil en ligne de conversion de formats de données qui convertit les données au format CSV (valeurs séparées par des virgules) en requêtes SQL INSERT pour faciliter l'importation dans les bases de données.
CSV est un format de données tabulaires courant, largement utilisé pour les feuilles de calcul et l'exportation de données. SQL est le langage de requête standard pour les bases de données relationnelles, et les requêtes INSERT sont utilisées pour insérer des données dans des tables de base de données.
Avec cet outil, vous pouvez rapidement convertir des données CSV en requêtes SQL exécutables, avec la prise en charge de noms de table personnalisés, de noms de champs et de styles de guillemets pour faciliter les opérations de migration et d'importation de données.
Comment utiliser
Comment utiliser
- Collez ou saisissez les données CSV dans la zone de saisie, ou téléversez un fichier CSV
- Définissez le nom de la table (par défaut : table_name)
- Sélectionnez le délimiteur approprié (la virgule par défaut)
- Choisissez si la première ligne doit être utilisée comme noms de champs
- Les instructions SQL INSERT seront générées à droite
Sécurité d'importation
- Vérifiez les instructions INSERT générées concernant le nom de la table, l'ordre des colonnes, l'échappement, les valeurs NULL et les formats numériques avant l'exécution.
- Exécutez d'abord un petit lot et lancez les importations effectives dans une transaction si votre base de données le permet.
Cas d’utilisation
Principe technique
L'entrée CSV est analysée par un automate conforme à la RFC 4180 (gérant les champs entre guillemets, les guillemets doublés d'échappement et les fins de ligne CRLF/LF), puis émise sous forme d'instructions SQL INSERT ANSI. Les deux grammaires ne se chevauchent pas : le CSV utilise le doublage de guillemets doubles pour l'échappement ("O""Brien"), tandis que SQL utilise le doublage de guillemets simples dans les littéraux de chaînes ('O''Brien') selon ISO/IEC 9075. Le convertisseur réécrit chaque apostrophe interne en une paire doublée avant d'entourer la valeur de guillemets simples, ce qui est le seul mécanisme d'échappement garanti sur MySQL, PostgreSQL, SQLite, SQL Server et Oracle. L'encadrement des identifiants est spécifique au dialecte : MySQL utilise les backticks `users`, PostgreSQL et SQL Server utilisent les guillemets doubles "users" (sensible à la casse lorsque encadré), et SQLite accepte les deux — choisissez le style correspondant au moteur cible pour éviter les erreurs de « colonne inconnue » causées par le pliage de casse. L'inférence de type est intentionnellement minimale car le CSV n'a pas de métadonnées de type. Le brouillon optionnel de CREATE TABLE émet VARCHAR(255) pour chaque colonne — sûr mais sous-optimal — et laisse à l'utilisateur le soin de substituer INT, BIGINT, DECIMAL(p,s), DATE, TIMESTAMP ou TEXT avant l'exécution en production. Les cellules vides sont émises comme NULL (l'absence dans la logique à trois valeurs SQL) plutôt que comme la chaîne vide '', car la plupart des exports de feuilles de calcul utilisent un champ vide pour représenter des données manquantes ; si la distinction chaîne vide compte, passez plutôt à un chargeur typé. Les mots réservés tels que user, order et group ne sont PAS automatiquement encadrés, donc une colonne nommée littéralement order échouera à l'analyse sur MySQL sauf si l'utilisateur l'entoure manuellement de backticks. Pour les grands imports, les instructions INSERT ligne par ligne sont correctes mais lentes : le max_allowed_packet par défaut de MySQL est de 64 Mo et un INSERT INTO t VALUES (...), (...) multi-lignes par lots d'environ 1000 lignes par instruction est généralement 5 à 10 fois plus rapide qu'une instruction par ligne en raison des allers-retours réseau et du surcoût d'analyse. Envelopper le lot dans BEGIN; ... COMMIT; permet à la base de données de préparer les insertions et de les valider de manière atomique, ce qui est essentiel lorsqu'une insertion partielle laisserait une relation de clé étrangère incohérente. Notez que cet outil n'infère pas les clés étrangères, les index, les contraintes de clé primaire ni AUTO_INCREMENT — il convertit uniquement les données de lignes, de sorte que le schéma récepteur doit déjà exister ou le brouillon de CREATE TABLE doit être modifié avant l'exécution. Pour les chargements en masse de millions de lignes, préférez la syntaxe native de la base de données : PostgreSQL COPY FROM, MySQL LOAD DATA INFILE ou SQL Server bcp.
- Échappement des littéraux de chaînes SQL selon ISO/IEC 9075 : les guillemets simples sont doublés ('O''Brien'), pas échappés par antislash.
- L'encadrement des identifiants diffère : ` pour MySQL, " pour PostgreSQL/SQL Server, les deux acceptés dans SQLite.
- Cellule CSV vide -> SQL NULL (logique à trois valeurs), pas '' — la distinction chaîne vide est perdue.
- Les mots réservés (order, user, group) ne sont pas automatiquement encadrés ; échappement manuel requis.
- Les INSERT multi-lignes par lots d'environ 1000 lignes atteignent un débit ~5 à 10 fois supérieur aux instructions ligne par ligne (MySQL max_allowed_packet 64 Mo par défaut).
- Enveloppez avec BEGIN; ... COMMIT; pour des insertions atomiques de seed ; les échecs partiels sont proprement annulés.
- Chargements en masse de plus d'1M de lignes : préférez PostgreSQL COPY, MySQL LOAD DATA INFILE, SQL Server bcp aux INSERT générés.
Exemples
CSV de base -> instructions INSERT (style backtick MySQL)
CSV :
id,name,email
1,Alice,alice@example.com
2,Bob,bob@example.com
SQL :
INSERT INTO `users` (`id`, `name`, `email`) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO `users` (`id`, `name`, `email`) VALUES (2, 'Bob', 'bob@example.com');Avec CREATE TABLE (style guillemets doubles PostgreSQL)
CSV :
product_id,price,in_stock
101,29.99,true
102,15.50,false
SQL :
CREATE TABLE "products" (
"product_id" VARCHAR(255),
"price" VARCHAR(255),
"in_stock" VARCHAR(255)
);
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('101', '29.99', 'true');
INSERT INTO "products" ("product_id", "price", "in_stock") VALUES ('102', '15.50', 'false');
-- Astuce : remplacez VARCHAR(255) par INT / DECIMAL(10,2) / BOOLEAN avant l'exécution en production.Échappement des apostrophes dans les valeurs
CSV :
id,note
1,O'Brien signed off
2,It's already done
SQL :
INSERT INTO `notes` (`id`, `note`) VALUES (1, 'O''Brien signed off');
INSERT INTO `notes` (`id`, `note`) VALUES (2, 'It''s already done');
Note : les apostrophes sont doublées (''), c'est l'échappement standard SQL.Inférence de type - INT vs DECIMAL vs TEXT
CSV :
user_id,score,bio
1,100,Hello
2,87.5,Long bio text...
Types détectés (heuristique) :
user_id -> INT
score -> DECIMAL(10,2)
bio -> VARCHAR(255) (envisagez TEXT pour des contenus plus longs)
Aperçu SQL :
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (1, 100, 'Hello');
INSERT INTO `students` (`user_id`, `score`, `bio`) VALUES (2, 87.5, 'Long bio text...');FAQ
Quel type de SQL l'outil génère-t-il ?
Il produit des instructions standard CREATE TABLE et INSERT INTO. Le dialecte est par défaut un SQL portable : il fonctionne sur MySQL, PostgreSQL, SQLite et MSSQL avec de légères adaptations de types. Certaines pages permettent de choisir un dialecte cible pour les types de données (VARCHAR vs TEXT, INT vs INTEGER, etc.).
Comment les noms de colonnes sont-ils dérivés ?
À partir de la première ligne du CSV lorsque « la première ligne est l'en-tête » est activé. La page nettoie les noms en remplaçant les espaces par des underscores et en mettant les mots réservés entre guillemets. Sans en-têtes, les colonnes deviennent col_1, col_2, etc.
Comment le type de données de chaque colonne est-il inféré ?
La page échantillonne les valeurs et choisit le type le plus restrictif qui convient : INTEGER si chaque cellule est un nombre entier, DECIMAL si certaines sont fractionnaires, VARCHAR(N) dimensionné selon la cellule la plus longue, BOOLEAN pour true/false, DATE/DATETIME pour les chaînes au format ISO. Vous pouvez remplacer le type inféré avant de générer le SQL.
Qu'en est-il des guillemets et des caractères spéciaux dans les données ?
Les apostrophes simples dans les valeurs de chaîne sont échappées en les doublant (O'Brien → 'O''Brien'). Les antislash et les caractères Unicode passent tels quels littéralement, ce qui correspond au comportement standard_conforming_strings = on de PostgreSQL. Vérifiez le résultat sous le mode NO_BACKSLASH_ESCAPES de MySQL si vous ciblez MySQL.
Pourquoi les NULL diffèrent-ils des chaînes vides ?
Une cellule CSV vide (par exemple « a,,c ») devient SQL NULL ; une chaîne vide entre guillemets (« a,"",c ») devient ''. La page suit cette convention. Désactivez « traiter le vide comme NULL » si vous voulez préserver les chaînes vides dans les deux cas.
Mes données sont-elles envoyées en ligne ?
Non. Le CSV est analysé et le SQL est généré dans votre navigateur. Les entrées et sorties ne quittent jamais la page. Utilisez le résultat comme un script SQL que vous importez vous-même dans votre serveur de base de données.
Devrais-je utiliser le SQL généré sur une base de données de production ?
Relisez-le d'abord. L'instruction CREATE TABLE peut ne pas correspondre à votre schéma existant ; les INSERT n'incluent pas de contraintes, clés étrangères ou index. Utilisez-le comme point de départ que vous éditez, en particulier pour les clés primaires, les contraintes NOT NULL et les bons types de données.