Convertir un CSV en SQL

1. 1

   Ajoutez votre CSV

   Déposez un fichier .csv, .tsv ou .txt sur la page, ou ouvrez la zone de collage et collez directement du texte CSV.

2. 2

   Choisissez votre base de données

   Choisissez MySQL, PostgreSQL, SQLite, SQL Server, Oracle ou le SQL standard. L'échappement, les noms de types et les littéraux de date suivent votre choix.

3. 3

   Choisissez un type d'instruction

   Un INSERT par ligne, un INSERT groupé, CREATE TABLE, UPDATE, DELETE ou MERGE. Pour les trois derniers, cochez les colonnes clés sur lesquelles la clause WHERE doit s'appuyer.

4. 4

   Vérifiez les colonnes

   L'onglet Colonnes affiche le type inféré pour chaque colonne et le type SQL exact qu'elle produira. Vous pouvez remplacer n'importe lequel et décocher les colonnes dont vous ne voulez pas.

5. 5

   Générez et téléchargez

   Générez le script, puis téléchargez le fichier .sql ou copiez-le. Rien n'est envoyé à aucun moment.

Générez du SQL propre depuis un CSV avec contrôle du délimiteur et de l'encodage, nom de table personnalisé, correspondance des en-têtes et export rapide. Les valeurs sont échappées pour la base de données choisie, les colonnes reçoivent de vrais types au lieu d'être mises entre guillemets comme du texte, et toute la conversion s'exécute sur votre appareil.

• Six dialectes de base de données. MySQL et MariaDB, PostgreSQL, SQLite, SQL Server, Oracle et le SQL standard, chacun avec ses guillemets, son échappement, ses noms de types et ses littéraux de date.
• Sept types d'instruction. Un INSERT par ligne, un INSERT groupé, CREATE TABLE, DROP puis CREATE puis INSERT, UPDATE, DELETE, et MERGE ou UPSERT.
• De vrais types de colonnes. Entiers, grands entiers, décimaux, virgule flottante, booléens, dates, horodatages, heures et texte dimensionné, inférés depuis toutes les lignes et non depuis un échantillon.
• Un remplacement par colonne. Si l'inférence ne vous convient pas, fixez le type vous-même, ou décochez une colonne pour qu'elle n'atteigne jamais la base de données.
• Gestion des NULL. Les cellules vides deviennent NULL ou une chaîne vide, et vous pouvez nommer vos propres jetons NULL comme \N, NA ou NULL.
• Des identifiants sûrs. Mots réservés, noms commençant par un chiffre, doublons et noms trop longs pour la base de données sont tous résolus avant de pouvoir casser le script.
• Deux aperçus. Une grille de données montrant ce qui a été analysé et le type retenu pour chaque colonne, et un aperçu SQL en direct des instructions que vous allez télécharger.
• Rien n'est envoyé. Le fichier est lu, converti et écrit sur votre appareil, donc l'outil fonctionne hors ligne et sur mobile une fois la page chargée.

Le dialecte est le premier réglage à poser, car il change bien plus que les noms de types. Les guillemets, l'échappement des chaînes, les littéraux booléens et de date, la clause d'identité et la forme d'un upsert diffèrent tous, et un script écrit pour une base de données est fréquemment invalide sur une autre.

• MySQL et MariaDB. Identifiants entre accents graves, antislashs échappés dans les chaînes, booléens en 1 et 0, AUTO_INCREMENT, et ON DUPLICATE KEY UPDATE pour les upserts.
• PostgreSQL. Identifiants entre guillemets doubles, antislashs laissés tels quels puisque les chaînes standard sont la valeur par défaut, vrais TRUE et FALSE, littéraux DATE et TIMESTAMP, colonnes d'identité et ON CONFLICT DO UPDATE.
• SQLite. Guillemets doubles, affinité de type respectée plutôt qu'inventée, AUTOINCREMENT sur une clé primaire entière, et ON CONFLICT DO UPDATE.
• SQL Server. Identifiants entre crochets, préfixe N sur tout littéral contenant du texte non ASCII pour que les accents survivent, colonnes NVARCHAR assorties, IDENTITY avec sa protection INSERT, et MERGE pour les upserts.
• Oracle. Guillemets doubles, limite de 30 caractères pour les identifiants, TO_DATE et TO_TIMESTAMP avec masques explicites pour que le format de date de la session ne change pas le sens, un bloc PL/SQL pour la suppression conditionnelle, et MERGE contre dual.
• SQL standard. Syntaxe ANSI portable pour tout ce qui n'est pas dans la liste, ou comme point de départ que vous comptez ajuster.

Changer de dialecte ne relit jamais le fichier, c'est donc instantané même sur un gros export. Changez-le, regardez l'aperçu SQL, et changez encore jusqu'à ce que le script ressemble à quelque chose que votre client acceptera.

Chaque tâche appelle des instructions différentes. Charger une table neuve n'est pas la même chose que corriger des lignes qui existent déjà, et générer des INSERT pour la seconde est la manière classique de se retrouver avec des doublons.

• INSERT. Une instruction par ligne. La sortie la plus lisible et la plus facile à modifier à la main ou à utiliser pour charger quelques centaines de lignes.
• INSERT groupé. Une instruction par groupe de lignes, avec la taille du lot sous votre contrôle. Beaucoup plus rapide à exécuter sur un gros chargement, et environ moitié moins volumineux.
• CREATE TABLE. La définition de la table seule, avec types inférés, NOT NULL là où les données n'ont pas de trous, et clé primaire facultative.
• DROP, CREATE et INSERT. Tout le script dans un fichier : supprimer l'ancienne table si elle existe, la créer, puis la remplir. C'est le choix pour un chargement reproductible.
• UPDATE. Une instruction par ligne, qui affecte toutes les colonnes non clés et s'appuie sur les colonnes clés que vous cochez.
• DELETE. Une instruction par ligne, sur les colonnes clés. Utile pour supprimer une liste précise d'enregistrements.
• MERGE ou UPSERT. Insère la ligne si elle est nouvelle, la met à jour si elle existe déjà. Écrit dans la forme que votre base de données prend réellement en charge.

Colonnes clés

UPDATE, DELETE et MERGE doivent savoir quelles colonnes identifient une ligne. Cochez-les dans l'onglet Colonnes. Si vous n'en cochez aucune, la première colonne est utilisée et l'outil le signale, car un UPDATE sans clause WHERE réécrirait toutes les lignes de la table. Lorsqu'une colonne clé ne contient aucune valeur, l'instruction est écrite avec IS NULL plutôt que = NULL, qui ne correspondrait jamais à rien.

Chaque cellule de chaque ligne est lue avant qu'une seule instruction ne soit écrite, si bien que les types déclarés décrivent tout le fichier et non les premiers milliers de lignes. Une colonne prend le type le plus étroit qui contient tout, et le moindre désaccord l'élargit en texte plutôt que d'abandonner une valeur.

• Entiers. Jusqu'à neuf chiffres pour un entier, jusqu'à dix-neuf pour un grand entier, et au-delà un décimal exact, si bien qu'un numéro de compte à vingt chiffres n'est jamais arrondi.
• Décimaux et virgule flottante. La précision et l'échelle viennent de la partie entière la plus large et de la partie fractionnaire la plus large de toute la colonne, si bien qu'une colonne contenant 1234 et 1.5 est dimensionnée pour les deux. Les valeurs en notation exponentielle donnent une colonne à virgule flottante.
• Booléens. Uniquement les mots true, false, yes et no. Voir plus bas pourquoi 1 et 0 n'en font pas partie.
• Dates et horodatages. ISO 8601 uniquement, et la date est vérifiée contre le calendrier, si bien que 2026-02-30 reste du texte au lieu de devenir une date invalide.
• Texte. Dimensionné sur la valeur la plus longue du fichier et arrondi au palier suivant, pour que l'import suivant n'échoue pas sur une valeur d'un caractère de trop.

Ce qui reste du texte volontairement

Quatre cas ressemblent à autre chose et n'en sont pas. Les deviner, c'est ainsi qu'un convertisseur détruit discrètement des données tout en produisant une sortie d'apparence parfaite.

• Zéros initiaux. 007, 01730 et 0044 sont un rang, un code postal et un indicatif téléphonique. En entiers ils deviennent 7, 1730 et 44, et les zéros ont disparu de la base pour de bon.
• Un plus initial. +15551234567 correspond parfaitement à un entier et c'est un numéro de téléphone. En nombre, il perd le plus et son sens.
• Dates ambiguës. 03/04/2026 est le 3 avril presque partout et le 4 mars aux États-Unis, et rien dans un CSV ne tranche. Une colonne entière peut rester cohérente sous les deux lectures pendant des années.
• Indicateurs d'une seule lettre. Une colonne de t, f, y et n est une convention booléenne, et c'est aussi une note, une initiale et un code de catégorie. Les mots true, false, yes et no sont sans ambiguïté ; les lettres ne le sont pas.

Rien de tout cela n'est un mur. Chacun de ces cas peut être fixé à la main dans l'onglet Colonnes, et un remplacement explicite est honoré à la lettre, lettres isolées comprises. La différence est qu'aucune supposition n'est faite à votre place. Lorsqu'un remplacement ne peut pas être satisfait par une cellule donnée, cette valeur est écrite NULL et l'outil vous indique combien de cellules sont concernées, plutôt que de faire échouer le script des centaines d'instructions plus loin.

Une mesure absente et une mesure de rien sont deux faits différents, et dès lors que les deux sont une chaîne vide dans la base de données, plus rien ne peut les distinguer. La version précédente de cet outil écrivait chaque cellule vide en chaîne vide sans aucun moyen de le changer.

• Cellules vides en NULL. Le comportement par défaut, et ce que veut presque tout import. La colonne est aussi marquée comme acceptant NULL dans le CREATE TABLE.
• Cellules vides en chaîne vide. Pour charger dans une table existante dont les colonnes sont déclarées NOT NULL.
• Jetons NULL personnalisés. Les exports écrits par mysqldump utilisent \N, et beaucoup de feuilles tenues à la main utilisent NA, N/A ou le mot NULL. Indiquez ceux qu'utilise votre fichier, séparés par des virgules, et ils deviendront de vrais NULL.
• NULL dans une colonne clé. Écrit IS NULL dans la clause WHERE, jamais = NULL, qui n'est jamais vrai en SQL et ne correspondrait silencieusement à aucune ligne.
• Caractères qu'aucune base ne peut stocker. Les octets nuls sont retirés et comptés, car PostgreSQL les rejette purement et simplement tandis que MySQL tronque la valeur à cet endroit. On vous dit combien ont été concernés au lieu de vous donner trois mauvaises réponses différentes.

Un en-tête de feuille de calcul n'est pas un identifiant SQL, et transformer l'un en l'autre est précisément là où la version précédente de cet outil produisait des scripts qu'aucune base de données n'acceptait. Quatre problèmes doivent être résolus avant qu'un nom soit sûr à écrire.

• Mots réservés. order, group, key, desc, from et table sont des en-têtes de colonne ordinaires et tous sont réservés. Ils sont mis entre guillemets automatiquement.
• Noms commençant par un chiffre. 1st et 2nd ne peuvent être écrits sans guillemets dans aucun dialecte. Ils sont mis entre guillemets plutôt que déformés.
• Noms en double. col-1 et col.1 se replient tous deux en col_1. Le second devient col_1_2, et la vérification ignore la casse car MySQL sous Windows et SQL Server traitent Total et total comme la même colonne.
• Noms trop longs pour la base. Oracle autorise trente caractères, PostgreSQL soixante-trois, MySQL soixante-quatre. Les noms longs sont raccourcis, et toute collision créée par ce raccourcissement est résolue ensuite.

Deux styles de nommage

Noms propres replie un en-tête en minuscules, chiffres et tirets bas, si bien que First Name devient first_name et Café Total devient cafe_total. Conserver l'original garde l'en-tête exactement tel que vous l'avez écrit et le met entre guillemets là où la base l'exige. Il n'y a volontairement pas de troisième option qui supprimerait les guillemets, car un mot réservé ou une espace n'a aucune écriture sans guillemets et ce réglage ne pourrait produire qu'un script cassé.

Un CSV, c'est ainsi que les données sortent d'un tableur, et un script SQL, c'est ainsi qu'elles entrent dans une base. Passer de l'un à l'autre à la main est lent et sujet aux erreurs, et ces erreurs sont du genre silencieux.

• Alimenter une base de données. Données de référence, tables de correspondance et jeux de test vivent dans des tableurs et doivent arriver en base sous forme d'instructions reproductibles et relisibles.
• Jeux de test. Un script généré peut être versionné à côté du code et rejoué sur chaque nouvel environnement.
• Migrations et chargements ponctuels. Un script peut être lu, modifié et appliqué via le processus de relecture que la base possède déjà, ce qu'un import en masse par interface graphique ne permet pas.
• Travailler sans assistant d'import. Beaucoup de bases en production ne sont accessibles que via un client SQL, et un fichier .sql est le seul format que tous les clients acceptent.
• Corriger des lignes existantes. UPDATE et MERGE transforment un tableur corrigé en les instructions exactes nécessaires pour aligner une table en production dessus.

Ces réglages contrôlent la façon dont le fichier est lu, avant qu'aucun SQL ne soit écrit. En changer un relit le fichier ; tout le reste ne fait que remodeler la sortie.

• Délimiteur. Auto, virgule, point-virgule, tabulation ou barre verticale. Auto analyse un échantillon avec chaque candidat et retient celui qui donne les largeurs de ligne les plus régulières, si bien qu'une virgule dans une adresse entre guillemets ne peut pas le tromper.
• Caractère de guillemet. Auto, guillemet double, apostrophe, ou aucun. Des fichiers cités avec des apostrophes existent, et les lire avec le mauvais caractère fusionne des lignes.
• Encodage. Auto, UTF-8, UTF-16LE, UTF-16BE, Windows-1252 ou ISO-8859-1. Une marque d'ordre des octets présente dans le fichier l'emporte toujours sur la liste, car un fichier qui déclare son propre encodage bat une supposition.
• La première ligne est un en-tête. Activé par défaut. Désactivez-le et les colonnes sont nommées par position, la première ligne étant traitée comme des données.
• Ignorer des lignes. Pour les exports qui commencent par un titre, un horodatage ou une ligne vide avant le vrai en-tête.
• Inférer les types de colonnes. Activé par défaut. Désactivez-le et chaque colonne devient du texte dimensionné, ce que vous voulez pour charger dans une table de transit existante.

Laissez d'abord le délimiteur sur Auto. Ne le fixez à la main que si l'aperçu montre que le fichier est mal lu.

• Virgule. La valeur par défaut, et ce qui donne son nom au format. La plupart des exports de logiciels anglophones.
• Point-virgule. Ce qu'écrit Excel dans une grande partie de l'Europe, où la virgule est le séparateur décimal.
• Tabulation. Les fichiers TSV, et tout ce qui est copié directement d'un tableur vers un fichier texte.
• Barre verticale. Courante dans les chaînes de traitement de données et les extractions mainframe, où les données elles-mêmes peuvent contenir des virgules et des points-virgules.

La liste est fermée. Tout ce qui n'y figure pas est refusé à la sélection du fichier avec une phrase disant ce que c'est et où l'emmener, plutôt que d'être accepté et d'échouer plus tard.

Ce que vous pouvez convertir

• .csv avec l'un des quatre délimiteurs et l'un des cinq encodages.
• .tsv exports séparés par des tabulations.
• .txt texte délimité sous n'importe quelle extension écrite par un tableur.
• Texte collé. Collez du CSV directement dans la page sans enregistrer de fichier au préalable.

Ce qui est refusé, et où aller à la place

• Classeurs Excel. Un .xlsx ou .xls est une archive compressée, pas du texte délimité. Convertissez-le d'abord en CSV.
• JSON. Utilisez d'abord l'outil JSON vers CSV, puis amenez le résultat ici.
• Fichiers contenant une image ou une archive sous un nom .csv. Détectés d'après le contenu et non l'extension, et refusés avant toute analyse.
• Fichiers vides. Refusés avec un message plutôt que de produire un script vide.

Limites de taille et de lot

La version gratuite convertit un fichier à la fois, jusqu'à 25 Mo, avec tous les dialectes, types d'instruction, remplacements de type et réglages NULL disponibles. Pro convertit jusqu'à 50 fichiers en une passe et les livre dans une seule archive ZIP, et est limitée par ce que votre appareil peut traiter plutôt que par un chiffre fixe. Rien de ce qui rend le SQL correct n'est derrière le paiement, car un script qui ne s'exécute pas n'est pas une finition premium.

Le fichier est décodé, le délimiteur et le caractère de guillemet sont détectés en analysant un échantillon et en notant à quel point chaque lecture est rectangulaire, et les lignes sont analysées par un lecteur qui comprend les champs entre guillemets contenant délimiteurs et sauts de ligne. Chaque cellule est ensuite classée, et chaque colonne prend le type le plus étroit qui convient à toutes ses valeurs.

Le script est écrit par morceaux et envoyé directement dans un fichier plutôt qu'assemblé en un seul énorme bloc de texte, ce qui permet de produire un script de 23 Mo sans que la page cesse de répondre. L'aperçu montre les premières instructions immédiatement, pour que vous voyiez ce que vous allez télécharger avant de le télécharger.

Rien ne quitte votre appareil

Il n'y a aucune étape d'envoi ni aucun serveur impliqué dans la conversion. Le fichier est lu depuis le disque vers la page, converti sur place, et réécrit sous forme de téléchargement. Une fois la page chargée, vous pouvez couper le réseau et cela fonctionne toujours, ce qui est la seule version d'une promesse de confidentialité que vous pouvez vérifier vous-même.

Un export de 10 Mo comptant 104 000 lignes est lu, typé et écrit sous forme de script SQL de 23 Mo en une seconde environ, sans que la page ne se fige.

• CSV vers JSON
• CSV vers Excel
• CSV vers XML
• Visionneuse CSV
• Filtre CSV
• Outils CSV