Convertitore da SQL a CSV

Cosa accetta il parser

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');

Diventa:

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

Regole di escape CSV applicate

• Il delimitatore è sempre una virgola; non esiste un’opzione per il separatore.
• I campi che contengono virgole, virgolette doppie o a capo vengono racchiusi tra virgolette doppie.
• Le virgolette doppie interne vengono raddoppiate (" diventa ""), secondo l’RFC 4180.
• Le virgolette singole iniziali e finali dei letterali di stringa SQL vengono rimosse.
• Il NULL SQL passa come il testo letterale NULL; sostituiscilo a valle se il tuo strumento si aspetta celle vuote.

Limitazioni da conoscere

• Elenco colonne richiesto. Il parser legge l’intestazione dall’elenco (col1, col2, ...) prima di VALUES. Un semplice INSERT INTO t VALUES (...) senza l’elenco delle colonne produce righe CSV senza intestazione.
• Una tabella alla volta. Se il tuo dump mescola INSERT per tabelle diverse, separali prima. Righe di larghezza diversa producono un CSV irregolare.
• Nessun parsing di CREATE TABLE. I tipi di colonna non vengono usati. Date, JSON e blob binari passano come testo grezzo.
• Ogni gruppo di parentesi diventa una riga. Il parser trasforma ogni gruppo (...) in una riga, quindi le clausole finali che contengono parentesi (ON DUPLICATE KEY UPDATE, RETURNING), le chiamate di funzione come NOW() o gli array annidati come (1,2,3) all’interno di un valore aggiungono righe superflue. Limita l’input a tuple INSERT ... VALUES semplici e sostituisci queste espressioni con letterali prima di incollare.