Convertisseur Excel vers SQL
Téléchargez un fichier Excel pour le convertir en requêtes SQL INSERT
Déposez un fichier Excel ici ou cliquez pour sélectionner
Qu'est-ce que Excel vers SQL ?
Excel vers SQL est un outil en ligne de conversion de formats de données qui convertit les fichiers Excel (.xlsx/.xls) en requêtes SQL INSERT pour faciliter l'importation dans les bases de données.
Excel est le format de feuille de calcul le plus couramment utilisé, largement employé pour le stockage et l'analyse 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 de feuilles de calcul Excel en requêtes SQL exécutables, avec la prise en charge de la sélection de plusieurs feuilles, de noms de table personnalisés et de styles de guillemets pour faciliter les opérations de migration et d'importation de données.
Comment utiliser
Comment utiliser
- Chargez un fichier Excel (format .xlsx ou .xls)
- Si plusieurs feuilles existent, sélectionnez la feuille à convertir
- Définissez le nom de la table (par défaut table_name)
- Choisissez si la première ligne doit être utilisée comme noms de champs
- Les instructions SQL INSERT sont générées automatiquement, copiez-les en un clic
Vérifications de génération SQL
- Inspectez les noms de colonnes, les types de données, les guillemets et la gestion des valeurs NULL avant d'exécuter le SQL généré sur une base de données réelle.
- Pour les imports en production, testez d'abord sur une table temporaire et conservez une sauvegarde de la feuille de calcul originale.
Cas d’utilisation
Principe technique
La page analyse le classeur téléchargé avec SheetJS — XLSX.read(arrayBuffer, {type: 'array'}) renvoie un objet classeur dont la feuille a des cellules indexées par clés A1, puis XLSX.utils.sheet_to_json(sheet, {header: 1, defval: null}) parcourt la plage bornée !ref en un tableau de tableaux. La première ligne non vide (lorsque l'option première-ligne-comme-en-tête est activée) est utilisée comme noms de colonnes ; sinon des noms col1, col2, col3 au style SheetJS sont synthétisés. Chaque ligne restante est émise sous forme d'une instruction SQL de la forme INSERT INTO `table` (`c1`, `c2`, ...) VALUES (v1, v2, ...);, avec optionnellement CREATE TABLE `table` (`c1` VARCHAR(255), ...); en préfixe. Les guillemets d'identifiants varient selon le dialecte SQL et sont régis par la norme SQL:1992 et les déviations de chaque éditeur : SQL standard et PostgreSQL mettent les identifiants entre guillemets doubles ("col"), MySQL et MariaDB utilisent par défaut les accents graves (`col`) et n'acceptent les guillemets doubles que lorsque le mode SQL ANSI_QUOTES est activé, SQLite accepte les accents graves et les guillemets doubles (et, pour des raisons de compatibilité ascendante, traite les identifiants entre guillemets doubles qui ne se résolvent pas comme des littéraux de chaîne — un piège bien documenté dans la page SQLite Quirks), SQL Server et Sybase utilisent les crochets ([col]). Les guillemets de valeurs suivent les règles des littéraux de chaîne SQL : les guillemets simples entourent le littéral et sont échappés par doublement ('O''Brien'), selon ISO/IEC 9075. Les cellules vides correspondent au littéral non guillemeté NULL, pas à la chaîne vide '' ; les cellules numériques avec cell.t === 'n' sont émises sans guillemets ; les booléens deviennent 1/0 ou TRUE/FALSE selon le dialecte ; les dates nécessitent un traitement explicite. Les cellules de date nécessitent une attention particulière car SheetJS préserve le numéro de série sous-jacent : Excel stocke les dates en jours depuis 1900-01-01 avec le bug historique de l'année bissextile 1900-02-29 décalant les dates antérieures à mars 1900 d'un jour, et le système Excel pour Mac 1904 utilise 1904-01-01 comme époque. La conversion en ISO 8601 (YYYY-MM-DD HH:mm:ss, le format que DATETIME MySQL et TIMESTAMP PostgreSQL acceptent tous deux) est (serial - 25569) * 86400000 ms après l'époque Unix, puis formatée en UTC. L'inférence de type est purement lexicale et superficielle : une colonne dont la première cellule non vide est un entier devient INT, un décimal devient DECIMAL(10,2), un texte devient VARCHAR(255), et une colonne commençant par 2024-01-01 peut être exportée comme chaîne à moins que la cellule source ne porte cell.t === 'd'. Les insertions en masse sont émises sous forme d'un INSERT par ligne, ce qui est lent à grande échelle ; combiner 100 à 500 lignes en un seul INSERT INTO t VALUES (...), (...), ...; réduit les allers-retours réseau d'environ 100×, et encapsuler le script dans BEGIN; ... COMMIT; transforme l'import en une transaction atomique qui annule à la première ligne en échec.
- Guillemets d'identifiants par dialecte : MySQL/MariaDB `col` (accents graves, ou "col" avec ANSI_QUOTES activé) ; PostgreSQL et SQL standard "col" ; SQL Server [col] ; SQLite accepte les deux (mais "col" revient silencieusement à un littéral de chaîne lorsque col n'est pas un identifiant connu).
- Échappement des littéraux de chaîne (ISO/IEC 9075) : entourer de guillemets simples et doubler les guillemets simples internes (O'Brien → 'O''Brien') ; ne jamais insérer de barres obliques inversées brutes — standard_conforming_strings de PostgreSQL est activé par défaut depuis la version 9.1.
- Numéro de série de date Excel : jours depuis 1900-01-01 avec le bug de 1900-02-29 (ou 1904-01-01 si workbook.date1904 est true) ; chaîne ISO 8601 = new Date((serial - 25569) * 86400000).toISOString().
- L'inférence de type est lexicale : entiers → INT, décimaux → DECIMAL(10,2), texte → VARCHAR(255) ; les dates qui ressemblent à des dates mais ne portent pas cell.t === 'd' sont exportées comme chaînes ; les cellules monétaires avec séparateur de milliers sont exportées avec le séparateur dans la chaîne.
- Gestion des NULL : une cellule Excel vide devient le littéral non guillemeté NULL, pas '' — la différence est importante pour les colonnes NOT NULL et pour COUNT(col) qui ignore les NULL mais comptabilise ''.
- Insertion en masse : combiner 100 à 500 lignes en un seul INSERT INTO t VALUES (...),(...),...; réduit les allers-retours réseau d'environ 100× par rapport à un INSERT par ligne ; max_allowed_packet de MySQL (par défaut 64 Mo) limite la taille par instruction.
- Encapsulez le script généré dans BEGIN;...COMMIT; (PostgreSQL/SQLite) ou START TRANSACTION;...COMMIT; (MySQL InnoDB) pour qu'une seule ligne en échec annule tout le lot ; les tables MyISAM ignorent la transaction et commitent partiellement.
Exemples
Feuille Excel → instructions INSERT
Feuille "users" (3 lignes) :
id | name | email | age
1 | Alice | alice@mail.com | 28
2 | Bob | bob@mail.com | 34
SQL généré :
INSERT INTO users (id, name, email, age) VALUES (1, 'Alice', 'alice@mail.com', 28);
INSERT INTO users (id, name, email, age) VALUES (2, 'Bob', 'bob@mail.com', 34);INSERT multi-lignes unique (import plus rapide)
Utilisez l'option "combiner les lignes" pour les chargements en masse :
INSERT INTO products (sku, name, price) VALUES
('A001', 'USB-C Cable', 9.90),
('A002', 'HDMI Adapter', 14.50),
('A003', 'Mouse Pad', 4.25);
Réduit 3 allers-retours à 1 — plus sûr pour les lots de 100 à 500 lignes.Échappement des apostrophes dans les noms
Cellule source : O'Brien
SQL généré (apostrophes doublées) :
INSERT INTO customers (id, name) VALUES (42, 'O''Brien');
Gestion des NULL — une cellule Excel vide devient NULL littéral, et non '' :
INSERT INTO customers (id, phone) VALUES (43, NULL);Encapsuler l'import dans une transaction
BEGIN;
INSERT INTO orders (id, customer_id, total, created_at) VALUES (1001, 7, 199.50, '2026-06-01');
INSERT INTO orders (id, customer_id, total, created_at) VALUES (1002, 7, 42.00, '2026-06-02');
INSERT INTO orders (id, customer_id, total, created_at) VALUES (1003, 9, 78.30, '2026-06-03');
COMMIT;
Si une ligne échoue, tout le lot est annulé.FAQ
Le tableur est-il téléversé ?
Non. Le fichier est analysé dans votre navigateur via SheetJS et le SQL est généré localement. Rien n'est envoyé à un serveur, donc même les jeux de données sensibles restent sur votre appareil.
Quelle sortie SQL est produite ?
Une instruction CREATE TABLE suivie de lignes INSERT INTO individuelles (une ligne par instruction). Le SQL généré utilise le nom de table que vous avez saisi et le style de guillemets que vous avez choisi (simple, double ou backtick).
Comment les types de colonnes sont-ils déduits ?
La page échantillonne chaque colonne et choisit le type le plus restrictif qui convient : INTEGER, DECIMAL, VARCHAR(N), BOOLEAN ou DATE/DATETIME. Vous pouvez le remplacer avant de générer le SQL. Les colonnes à types mixtes basculent vers VARCHAR.
Qu'en est-il des dates Excel ?
Les dates Excel sont stockées sous forme de numéros de série. La page les affiche telles que la valeur brute de la feuille. Vérifiez le SQL généré et ajustez les littéraux de date pour correspondre au format de votre base de données cible si nécessaire.
Comment les caractères spéciaux et les guillemets sont-ils échappés ?
Les apostrophes simples sont doublées (Smith's → Smith''s). Les antislashes et l'Unicode passent tels quels — cela correspond aux chaînes conformes au standard de PostgreSQL. Si vous ciblez MySQL avec NO_BACKSLASH_ESCAPES désactivé, vous devrez peut-être échapper les antislashes manuellement.
Le résultat fonctionnera-t-il sur MySQL, PostgreSQL, SQLite, MSSQL ?
Les INSERT de base fonctionnent sur les quatre. L'instruction CREATE TABLE utilise des types portables (INT, VARCHAR, DECIMAL, DATE). Pour les types spécifiques à un dialecte (SERIAL, AUTO_INCREMENT, IDENTITY), modifiez l'instruction CREATE pour correspondre à votre cible.
Les formules sont-elles évaluées ?
Non. La valeur mise en cache enregistrée par Excel est utilisée. Ouvrez le classeur source, recalculez, enregistrez, puis téléversez à nouveau si vous avez besoin de valeurs de formule actualisées.