Convertisseur SQL en CSV

Ce que le parseur accepte

INSERT INTO users (id, email, created_at) VALUES
  (1, 'alice@example.com', '2024-01-12 09:00:00'),
  (2, 'bob@example.com',   '2024-01-13 10:30:00'),
  (3, 'carol@example.com', '2024-01-13 11:15:00');

Devient :

id,email,created_at
1,alice@example.com,2024-01-12 09:00:00
2,bob@example.com,2024-01-13 10:30:00
3,carol@example.com,2024-01-13 11:15:00

Règles d’échappement CSV appliquées

• Le délimiteur est toujours une virgule ; il n’y a pas d’option de séparateur.
• Les champs contenant des virgules, des guillemets doubles ou des sauts de ligne sont entourés de guillemets doubles.
• Les guillemets doubles internes sont doublés (" devient ""), selon la RFC 4180.
• Les guillemets simples de début et de fin des littéraux de chaîne SQL sont supprimés.
• Le NULL SQL passe tel quel sous forme du texte littéral NULL ; remplacez-le en aval si votre outil attend des cellules vides.

Limitations à connaître

• Liste de colonnes requise. Le parseur lit l’en-tête à partir de la liste (col1, col2, ...) avant VALUES. Un simple INSERT INTO t VALUES (...) sans la liste de colonnes produit des lignes CSV sans en-tête.
• Une table à la fois. Si votre dump mélange des INSERT pour différentes tables, séparez-les d’abord. Des lignes de largeurs différentes produisent un CSV irrégulier.
• Pas d’analyse de CREATE TABLE. Les types de colonnes ne sont pas utilisés. Les dates, le JSON et les blobs binaires passent en texte brut.
• Chaque groupe de parenthèses devient une ligne. Le parseur transforme chaque groupe (...) en une ligne, donc les clauses finales contenant des parenthèses (ON DUPLICATE KEY UPDATE, RETURNING), les appels de fonction comme NOW() ou les tableaux imbriqués comme (1,2,3) à l’intérieur d’une valeur ajoutent des lignes superflues. Limitez l’entrée à des tuples INSERT ... VALUES simples et remplacez ces expressions par des littéraux avant de coller.