Pular para o conteúdo principal
ToolsByUs

CSV para SQL INSERT

Este conversor lê CSV RFC 4180 no seu navegador e escreve comandos SQL INSERT. Cada célula é tipada por inspeção — números sem aspas permanecem números, true e false se tornam TRUE e FALSE, o resto é uma string com aspas simples e escapadas. Nomes de cabeçalho se tornam identificadores de colunas com aspas duplas; nada é enviado.

Só local

CSV para SQL INSERT: explicação

CSV não tem tipos. Tudo em uma exportação de planilha é texto, e o banco de dados é quem decide o que um valor significa — o que torna a conversão CSV para SQL aquela onde a tipagem é feita por você, mesmo que você não tenha pensado nisso. Este conversor faz isso por célula e estabelece suas regras claramente: uma célula que lida como número se torna um número, true ou false se torna TRUE ou FALSE, uma célula vazia se torna NULL, e o resto é uma string.

O lado SQL usa as defesas padrão e nada exótico: nomes de cabeçalho se tornam identificadores de colunas com aspas duplas, valores de string são envolvidos em aspas simples com aspas incorporadas dobradas — o formato O''Brien que todo dialeto SQL lê corretamente — e as linhas são emitidas como um único comando INSERT multi-linha. A análise é estritamente RFC 4180, então campos com vírgulas ou novas linhas incorporadas sobrevivem intactos, que é exatamente onde conversores rápidos que dividem por vírgula corrompem seus dados.

A conversão roda inteiramente nesta aba do navegador. O CSV é analisado por código na página, o SQL é montado na memória, e nenhuma requisição sai da página — o painel de Rede no DevTools fica vazio enquanto você trabalha, e a Content-Security-Policy do site proíbe conexões de saída.

Se seus registros já carregam tipos — de uma API ou de uma exportação que os manteve — o Conversor JSON para SQL os leva como dados, em vez de inferir, com as mesmas regras de aspação e NULL.

Quer os dados como JSON em vez de SQL? O Conversor CSV para JSON usa o mesmo parser RFC 4180 e entrega registros tipados em vez de comandos.

Como a conversão realmente funciona

O motor analisa seu CSV pelas regras reais do RFC 4180 — registros, campos, aspas dobradas dentro de campos entre aspas, terminações CRLF ou LF — e trata o primeiro registro como cabeçalho e cada registro seguinte como uma linha do INSERT. A tipagem é aplicada por célula, imediatamente antes da emissão:

Dois detalhes de exportações reais de planilhas são tratados em vez de sofridos: uma marca de ordem de bytes UTF-8 no início do arquivo, que o Excel adiciona por padrão, é removida antes da análise, e o nome de tabela que você digita no campo de tabela do instrumento se torna o identificador entre aspas no INSERT — o exemplo abaixo usa products.

  • Números: uma célula que combina com um padrão de inteiro ou decimal é emitida sem aspas — 42 e 24.99 se tornam números. Um zero à esquerda a desqualifica, então 02134 permanece uma string e seus códigos postais sobrevivem.
  • Booleanos: true ou false, em qualquer caixa, se tornam TRUE ou FALSE.
  • Células vazias: um campo vazio se torna NULL. Um campo que está presente mas vazio entre aspas ("") permanece uma string vazia, porque o RFC 4180 distingue os dois e o SQL também.
  • Strings: o resto é tudo entre aspas simples com aspas incorporadas dobradas — O'Brien se torna 'O''Brien'.
  • Identificadores: nomes de cabeçalho são emitidos como nomes de colunas entre aspas duplas, na ordem do cabeçalho.

O mapeamento célula para literal

Uma linha por regra, para que você possa prever a saída antes de executar. Note que a célula vazia e a célula vazia entre aspas são deliberadamente linhas diferentes desta tabela, porque são o par que as pessoas perguntam mais:

Célula CSVLiteral SQLPorquê
4242Padrão de inteiro
24.9924.99Padrão de decimal
trueTRUEPalavra booleana, qualquer caixa
(vazio)NULLValor ausente
02134'02134'Zero à esquerda mantido — código postal
O'Brien'O''Brien'Aspa dobrada por padrão

Como a saída se parece

O exemplo abaixo é o par exato que o botão “Carregar exemplo” do conversor produz para uma tabela chamada products. Três linhas, cada uma testando uma regra: o preço da lampa de mesa é um decimal nu e seu estoque um TRUE nu; a linha da barraca precisou de aspação RFC 4180 no CSV porque o nome do produto contém uma vírgula, e o SQL emitido dobra seu apóstrofo; a linha da lanterna deixa duas células vazias e ambas se tornam NULL, não strings vazias. Salve a saída como um arquivo .sql e ele executa como está em psql, sqlite3 ou qualquer executor de migração — o comando está completo e terminado por ponto e vírgula.

Linhas irregulares e outras recusas honestas

O RFC 4180 tecnicamente permite registros com menos ou mais campos que o cabeçalho, mas o SQL não permite — uma tupla INSERT deve preencher exatamente as colunas que seu comando declara. Então duas entradas são recusadas com uma mensagem nomeando a linha, em vez de serem preenchidas ou truncadas:

  • Um registro cuja contagem de campos difere do cabeçalho — preencher com NULLs inventaria valores que você nunca mediu, e descartar extras descartaria dados que você forneceu.
  • Nomes de cabeçalho duplicados — duas colunas com o mesmo nome não podem ser identificadores entre aspas em um INSERT, então o conversor relata a coluna em vez de renomear uma delas silenciosamente.

Perguntas frequentes

Meu CSV é enviado quando eu converto para SQL?

Não. O parser e o escritor de SQL rodam dentro desta aba do navegador, em JavaScript que foi carregado quando a página abriu. Não há rota de upload, e a Content-Security-Policy impede que a página se conecte para fora. Verifique você mesmo no DevTools: o painel de Rede não mostra tráfego enquanto a conversão roda, mesmo para arquivos grandes.

Qual dialeto CSV o parser aceita?

RFC 4180, o padrão: campos delimitados por vírgula, escape com aspas duplas, aspas dobradas dentro de campos entre aspas, e vírgulas ou novas linhas incorporadas dentro de campos entre aspas são todas analisadas corretamente. Tanto terminações de registro CRLF quanto LF são aceitas. O que ele não faz é adivinhar — arquivos delimitados por ponto e vírgula ou tabulação são recusados com uma mensagem, porque um conversor que troca delimitadores silenciosamente corrrompe as colunas que não vê.

Como a inferência de tipos decide entre número, booleano e string?

Por célula, contra padrões estritos: um campo é número só se combina exatamente com um literal inteiro ou decimal, é booleano só se lê true ou false em qualquer caixa, e NULL só se o campo estiver vazio. Tudo o mais é emitido como string entre aspas. A estritação é o ponto — um conversor que tipa valores como 007 agressivamente entregará surpresas ao seu banco de dados.

Por que meu código postal ou código de produto permaneceu string?

Porque deveria. Um código como 02134 ou 007 carrega informação em seus zeros à esquerda, e um número não tem lugar para mantê-los. O padrão de inferência recusa zeros à esquerda de propósito, então tais células são emitidas como strings entre aspas e o significado da coluna sobrevive intacto na viagem para o banco de dados.

O que acontece com as datas no CSV?

Elas chegam como strings entre aspas, por design. Literais de data SQL diferem entre dialetos, e um conversor que reescreve 2024-01-05 em uma forma específica de dialeto está editando seus dados. A string chega ao banco de dados intacta; uma coluna DATE, ou o próprio cast do banco de dados, aplica o tipo na inserção — que é o único lugar onde essa decisão pertence.

Posso obter um comando INSERT por linha em vez disso?

A saída é um único INSERT multi-linha — uma análise, um comando amigável para transações, e a forma que guias de carregamento em massa recomendam. As tuplas VALUES ficam uma por linha sob a lista de colunas, então se suas ferramentas exigem comandos de linha única, a divisão é uma edição mecânica: copie a lista de colunas e termine cada tupla com ponto e vírgula.

Equipe ToolsByUs · Como verificamos nossas ferramentas