Conversor CSV ↔ JSON

Escopo: RFC 4180, sem inferência de tipos

O parser de CSV é compatível com RFC 4180 — campos entre aspas podem conter vírgulas e quebras de linha, e aspas literais viram "". Na direção CSV → JSON, todo valor sai como string (números e booleanos incluídos); não há inferência de tipo. Na direção JSON → CSV, o cabeçalho é a união de todas as chaves presentes em qualquer objeto da lista, e cada valor é serializado como string antes de escapar. A conversão roda automaticamente enquanto você digita, sem clique em botão.

Casos de uso

• Exportar uma planilha e popular um array de objetos para um script ou fixture de teste
• Gerar uma planilha a partir do array retornado por um endpoint de API
• Normalizar exports de ERP/CRM com vírgulas e aspas embutidas em campos de texto
• Inspecionar rapidamente um payload JSON tabular sem escrever código

Roda inteiramente no navegador — nada do conteúdo colado é enviado pela rede.

O CSV brasileiro e o problema do separador

A sigla diz "comma-separated values", mas o Excel configurado em português do Brasil exporta com ponto e vírgula. O motivo é o separador decimal: como usamos vírgula para decimais, usá-la também como separador de campos tornaria o arquivo ambíguo.

A consequência prática é que um CSV exportado do Excel brasileiro não é lido corretamente por ferramentas que assumem vírgula, e vice-versa. Se a conversão trouxer tudo em uma coluna só, é quase certo que o separador do seu arquivo não é o esperado — substitua os ; por , antes de colar, tomando cuidado com valores decimais.

Há ainda a codificação. O Excel para Windows salva em ANSI por padrão, o que quebra acentos em ferramentas que esperam UTF-8. Ao salvar, escolha "CSV UTF-8" — e note que, no caminho inverso, o Excel só reconhece UTF-8 de forma confiável se o arquivo tiver BOM no início.

Por que não há inferência de tipos

Na direção CSV → JSON, todo valor sai como string, inclusive o que parece número ou booleano. É uma decisão deliberada, porque a inferência automática corrompe dados brasileiros com frequência:

• Zeros à esquerda desaparecem. Um CEP 01310-100 sem hífen, um CPF começando com 0 ou um código de produto 007 viram números e perdem os dígitos iniciais de forma irreversível.
• Números grandes perdem precisão. Um CNPJ ou código de barras com 14 ou mais dígitos ultrapassa o limite de inteiro seguro do JavaScript e passa a ser arredondado.
• Decimais com vírgula quebram. 1.234,56 não é um número válido em JSON, e a conversão ingênua produz 1.234 ou NaN.
• Datas viram formatos imprevisíveis. 03/04/2026 é 3 de abril ou 4 de março, dependendo de quem interpreta.

Manter tudo como string preserva o dado exatamente como ele estava. A conversão de tipo, se for necessária, fica sob seu controle e com o conhecimento do que cada coluna significa.

Limites da direção JSON → CSV

CSV é um formato tabular plano, enquanto JSON é hierárquico. A conversão só funciona bem para um array de objetos com estrutura razoavelmente uniforme.

Objetos aninhados e arrays dentro de um campo não têm representação natural em CSV — eles são serializados como texto na célula, o que preserva a informação mas não a torna tabular. Estruturas profundas precisam ser achatadas antes, tipicamente com uma convenção de nomes como endereco.cidade.

O cabeçalho é a união de todas as chaves encontradas em qualquer objeto da lista. Objetos que não têm determinada chave ficam com a célula vazia, o que torna a conversão tolerante a registros heterogêneos.

Escape e quebras de linha

O parser segue a RFC 4180, o que resolve os casos que mais quebram implementações caseiras: campos entre aspas podem conter vírgulas e até quebras de linha, e uma aspa literal dentro do campo é representada duplicando-a ("").

É por isso que uma coluna de endereço ou observação com vírgula no meio não desloca as demais colunas — desde que o arquivo tenha sido gerado corretamente. Exports de ERP e CRM que montam o CSV por concatenação de string costumam falhar exatamente aí.

Para inspecionar o JSON resultante com indentação, use o formatador de JSON.