JSON para CSV
Transforma dados JSON num ficheiro CSV que podes abrir no Excel ou no Google Sheets.
A carregar JSON para CSV… Se nada acontecer, ativa o JavaScript.
Cola um array JSON de objetos, ou larga um ficheiro .json em qualquer ponto da ferramenta, e obtém de imediato um ficheiro CSV pronto a usar. O conversor deteta automaticamente as colunas através da união de todas as chaves encontradas em todos os objetos, pelo que registos com campos diferentes ou em falta ficam alinhados corretamente: os valores ausentes tornam-se simplesmente células vazias. A tabela de pré-visualização mostra as primeiras 20 linhas exatamente como vão aparecer na tua folha de cálculo, e um contador de linhas e colunas confirma num relance o tamanho do resultado.
Perguntas frequentes
Que estrutura JSON é que o conversor aceita?
Como são tratados os objetos aninhados?
Como são tratados os arrays dentro dos objetos?
O que acontece quando os objetos têm chaves diferentes?
Quando devo escolher o delimitador de ponto e vírgula?
O que faz a opção de aspas em todos os campos?
Como são escapados carateres especiais como aspas e quebras de linha?
O meu JSON é carregado para um servidor?
Porque é que os carateres acentuados aparecem mal quando abro o CSV no Excel?
Há limite para o tamanho do ficheiro?
Sobre JSON para CSV
O JSON do mundo real raramente é plano, por isso o conversor achata a estrutura automaticamente. Os objetos aninhados são expandidos com notação de pontos: {"address": {"city": "Lisbon"}} torna-se uma coluna chamada address.city. Os arrays são expandidos com índices entre parênteses retos: {"tags": ["admin", "dev"]} torna-se tags[0] e tags[1]. As duas regras combinam-se a qualquer profundidade, pelo que uma resposta de API profundamente aninhada como orders[0].items[2].price se transforma num nome de coluna limpo e previsível sem qualquer trabalho manual.
As opções de saída cobrem as manias de cada aplicação de folhas de cálculo. Escolhe vírgula, ponto e vírgula ou tabulação como delimitador; o ponto e vírgula é o que o Excel espera na maioria das configurações regionais europeias, onde a vírgula é o separador decimal. Desativa a linha de cabeçalho quando estiveres a acrescentar dados a uma folha existente, e ativa as aspas em tudo quando um importador rigoroso exigir que cada campo venha entre aspas duplas. O escape segue a convenção RFC 4180: os campos que contêm o delimitador, aspas ou quebras de linha são envolvidos em aspas duplas, e as aspas internas são duplicadas. O ficheiro descarregado inclui uma marca de ordem de bytes UTF-8 para o Excel mostrar corretamente os carateres acentuados.
Tudo corre do lado do cliente, no teu navegador: o JSON que colas ou largas nunca é carregado, registado ou guardado, o que torna a ferramenta segura para exportações com dados de clientes, credenciais ou registos internos. As mensagens de erro são precisas em vez de crípticas: ficas a saber se o JSON não pôde ser analisado (com a mensagem do próprio analisador), se o valor de topo não é um array ou qual o elemento concreto que não é um objeto. Os usos típicos incluem transformar respostas de APIs REST em folhas de cálculo, preparar dados para o Excel ou o Google Sheets e alimentar exportações JSON a ferramentas que só aceitam CSV.
Dos cartões perfurados às APIs REST: o estranho par dos formatos de dados
O CSV é muito mais antigo do que a maioria das pessoas imagina. Listas de valores separados por vírgulas aparecem logo na primeira versão do compilador FORTRAN da IBM, em 1972, e a ideia geral de campos separados por delimitadores remonta à tabulação com cartões perfurados. No entanto, durante as suas primeiras três décadas o CSV não teve especificação nenhuma: cada programa inventava as suas próprias regras para as aspas, os fins de linha e as vírgulas embutidas, e foi por isso que analisar ficheiros CSV alheios se tornou um rito de passagem para programadores. O formato só foi posto por escrito em 2005, quando o RFC 4180 documentou as convenções de facto: campos separados por vírgulas, aspas duplicadas para escape e registos terminados em CRLF. Mesmo assim, o RFC descreve-se a si próprio como mera documentação da prática existente, não como a definição de uma norma.
O JSON é a metade muito mais jovem do par, e foi descoberto mais do que inventado. Douglas Crockford deu-lhe nome e especificação em 2001, mas, como ele gosta de sublinhar, a sintaxe de literais de objeto do JavaScript já existia: ele limitou-se a recortar um subconjunto independente da linguagem, publicou o site de uma só página json.org e escreveu uma especificação suficientemente curta para caber num cartão de visita. A ascensão do JSON acompanhou a das APIs web: destronou o XML nos anos 2000 sobretudo por ser mais leve de transmitir e por corresponder diretamente às estruturas de dados de todas as linguagens principais, tornando-se norma ECMA em 2013 e RFC (8259) em 2017.
Os dois formatos perduram porque estão em extremos opostos de um compromisso. O JSON exprime hierarquia, aninhamento, tipos e arrays, o que o torna ideal para máquinas a falar com máquinas. O CSV exprime uma grelha plana, o que o torna ideal para humanos a olhar para dados numa folha de cálculo, ainda hoje a ferramenta analítica mais usada do mundo. Quase todos os pipelines de dados precisam, mais cedo ou mais tarde, de atravessar essa fronteira, achatando estruturas aninhadas em linhas e colunas, que é precisamente a transformação de notação de pontos e índices entre parênteses retos que este conversor executa. Meio século depois das vírgulas do FORTRAN e um quarto de século depois do json.org, traduzir entre os dois continua a ser uma das tarefas mais comuns do trabalho com dados.