CodeKitHub
Instrumente JSON

Convertor CSV în SQL

Ultima actualizare:

Pentru a transforma un rând CSV în SQL, fiecare coloană devine o valoare într-o instrucțiune INSERT INTO — numerele rămân fără ghilimele, textul este înfășurat în ghilimele simple cu ghilimelele interioare dublate (O'Brien devine O''Brien), iar celulele goale devin NULL. Acest instrument aplică acea conversie întregului tău fișier CSV, complet în browserul tău.

Ce este acest instrument?

Popularea unei baze de date de test, încărcarea unui export de tabel într-o tabelă, sau migrarea unui set mic de date începe adesea la fel: ai un fișier CSV și ai nevoie de SQL. Acest instrument analizează CSV-ul tău (folosind rândul antet ca nume de coloane) și construiește o singură instrucțiune INSERT INTO care acoperă fiecare rând de date, gata de lipit într-un client de bază de date.

Valorile de tip șir sunt înfășurate în ghilimele simple, cu ghilimelele interioare scăpate prin dublare (deci O'Brien devine O''Brien), care este regula standard de escapare, comună MySQL, PostgreSQL și SQLite. O celulă CSV goală este scrisă ca cuvântul cheie SQL NULL, nu ca un șir gol — aceasta este o alegere deliberată, deoarece o celulă goală într-un tabel înseamnă de obicei „fără valoare”, nu „o bucată de text goală”, iar NULL este ceea ce așteaptă majoritatea schemelor pentru asta.

Dacă o valoare primește ghilimele sau rămâne simplă este decis printr-o euristică simplă, nu inferență reală de tip: dacă celula tăiată arată ca un simplu număr întreg sau zecimal (opțional cu un semn minus la început), este scrisă fără ghilimele; orice altceva — inclusiv lucruri care doar seamănă cu numere cu caractere suplimentare, precum numere de telefon sau coduri poștale cu zerouri la început — este pus între ghilimele ca un șir. Asta păstrează rezultatul onest: este un punct de plecare bun pentru un import mic, nu un substitut pentru validarea datelor tale față de schema reală a tabelului, înainte de a-l rula.

Sursă: analiza CSV urmează RFC 4180, cel mai apropiat de un standard CSV formal; dublarea ghilimelelor simple pentru escaparea șirurilor este convenția comună documentată de MySQL, PostgreSQL și SQLite.

De ce să-l folosești?

  • Nume de tabel personalizat — setează tabelul țintă o dată, iar fiecare rând vizează acel tabel.
  • Escapare corectă a șirurilor — ghilimelele simple din interiorul valorilor sunt dublate, astfel încât SQL-ul nu se strică sau nu se trunchiază.
  • Gestionare predictibilă a NULL — celulele goale devin NULL în loc de un șir gol, potrivindu-se cu modul în care majoritatea bazelor de date disting datele lipsă.
  • Sintaxă SQL comună — forma INSERT INTO ... VALUES ... generată aici funcționează nemodificată în MySQL, PostgreSQL și SQLite.
  • 100% pe partea clientului — datele tale CSV (care pot include înregistrări de clienți sau date de afaceri) sunt analizate și convertite în browserul tău și nu sunt niciodată încărcate nicăieri.

Cum se folosește

  1. Lipește date CSV cu un rând antet, de exemplu name,age\nAlice,30\nBob,25.
  2. Introdu numele tabelului țintă (implicit my_table).
  3. Apasă „Generează SQL”.
  4. Copiază instrucțiunea INSERT INTO sau descarc-o ca fișier .sql, apoi rulează-o pe baza ta de date.

Exemplu

Intrare

name,age,city
Alice,30,
Bob,,NYC

Rezultat

INSERT INTO `my_table` (`name`, `age`, `city`)
VALUES
  ('Alice', 30, NULL),
  ('Bob', NULL, 'NYC');

Observă că celulele goale au devenit NULL (nu șiruri goale), iar valoarea numerică 30 a rămas fără ghilimele, în timp ce fiecare valoare text a fost pusă între ghilimele.

Sfaturi practice

  • Popularea unei baze de date locale de test: exportă un mostră mic ca CSV dintr-un tabel, convertește-l aici, și rulează instrucțiunea INSERT pe baza ta de date de dezvoltare.
  • Verifică întotdeauna tipurile de coloane înainte de a rula SQL-ul generat pe un tabel real — acest instrument deduce numeric vs. text cu o euristică simplă, nu schema ta reală, deci o coloană întreagă care așteaptă un format specific ar putea avea nevoie de ajustare manuală.
  • Dacă ai mii de rânduri, instrucțiunea unică INSERT cu mai multe rânduri generată de acest instrument este încă SQL valid, dar instrucțiunile foarte mari pot atinge dimensiunea maximă de pachet a unei baze de date — împarte CSV-ul în loturi mai mici mai întâi, dacă întâlnești acea limită.

De ce NULL și nu un șir gol

O greșeală comună la scrierea manuală a scripturilor CSV-în-SQL este tratarea fiecărei celule lipsă ca un șir gol ''. Acesta este SQL tehnic valid, dar de obicei nu înseamnă ce vrei: o coloană definită ca întreg va respinge '' direct, iar chiar și într-o coloană text, '' înseamnă în tăcere ceva diferit de „nu cunoaștem această valoare” în majoritatea design-urilor de schemă și interogărilor de raportare (o verificare WHERE column IS NULL nu se va potrivi cu șiruri goale, și invers). Folosirea NULL pentru celule goale se potrivește cu semantica pe care majoritatea bazelor de date și ORM-urilor o așteaptă, și evită erorile de tip când o coloană numerică are valori lipsă în unele rânduri.

Întrebări frecvente

Funcționează asta cu orice bază de date SQL?

Sintaxa generată — identificatori între backtick-uri, valori text între ghilimele simple, INSERT INTO ... VALUES ... standard — este comună între MySQL, PostgreSQL și SQLite. PostgreSQL nu necesită strict backtick-uri în jurul identificatorilor (folosește ghilimele duble dacă este nevoie de ghilimele deloc), dar numele cu backtick sunt inofensive și acolo, atâta timp cât nu ai nume neobișnuite de coloane care se ciocnesc cu cuvinte rezervate. Nu există un singur standard SQL oficial urmat aici — doar sintaxa care funcționează nemodificată pe cele mai comune baze de date.

De ce o celulă goală devine NULL în loc de un șir gol ''?

Aceasta este o alegere de design deliberată: în majoritatea exporturilor CSV reale, o celulă goală înseamnă că valoarea este necunoscută sau neaplicabilă, nu literal o bucată de text goală. NULL este ce așteaptă majoritatea schemelor de bază de date pentru asta. Dacă cazul tău de utilizare are cu adevărat nevoie de șiruri goale în schimb, va trebui să editezi manual SQL-ul generat pentru acele cazuri.

Cum decide instrumentul dacă o valoare are nevoie de ghilimele?

Este o euristică simplă, nu inferență reală de tip: dacă o celulă tăiată constă doar din cifre (cu un minus opțional la început și cel mult un punct zecimal), este scrisă fără ghilimele, ca număr. Orice altceva este pus între ghilimele ca șir. Asta înseamnă că un cod poștal precum 00501 sau un număr de telefon ar fi tratat ca text (deoarece eșuează modelul strict de întreg doar dacă are caractere suplimentare — un zero la început singur încă se analizează ca numeric aici, deci verifică dublu identificatori precum coduri poștale și ID-uri înainte de a rula SQL-ul).

Sunt datele mele încărcate undeva?

Nu. Atât analiza, cât și generarea SQL au loc în JavaScript, în browserul tău — nimic nu este trimis către un server, ceea ce face acest instrument sigur de folosit cu înregistrări exportate de clienți sau afaceri.

Poate gestiona valori CSV care conțin virgule sau ghilimele?

Da. CSV-ul este analizat cu un parser adecvat pentru câmpuri cu ghilimele, care înțelege virgule, întreruperi de linie și ghilimele dublate în interiorul câmpurilor cu ghilimele — nu o simplă divizare naivă după virgule — deci un câmp precum "Smith, John" este citit ca o singură valoare, nu împărțit în două coloane.

Instrumente similare