Converter JSON para NDJSON

Este é o mecanismo inteiro e vale dizer antes de qualquer outra coisa. Se o documento é um array, cada elemento vira uma linha. Se é qualquer outra coisa — um objeto, uma string, um número — o documento inteiro vira uma linha, porque NDJSON é definido como um valor JSON completo por linha e um objeto único é um valor.

Nenhum dos dois resultados é um erro e o conversor não vai avisar, então a checagem é sua: abra o arquivo e olhe o primeiro caractere. Um colchete produz o arquivo que você queria. Uma chave produz uma linha única e muito longa.

Respostas de API quase nunca são um array puro. São um objeto com uma chave — data, results, items, records — cujo valor é o array. Para as conversões tabulares deste site esse invólucro é removido automaticamente; neste par não é, e a diferença pega as pessoas.

O motivo é que o invólucro é um registro legítimo aqui. NDJSON pode guardar objetos de qualquer forma, então não há como distinguir "um envelope a descartar" de "um registro que por acaso contém uma lista". O conserto é uma edição de dez segundos num editor de texto: apague a chave de abertura, apague a chave de fechamento, salve, converta.

Todo outro destino para uma exportação JSON neste site precisa achatar. Um CSV, um TSV, um insert SQL ou uma coluna Parquet não têm onde colocar um objeto dentro de um valor. NDJSON não tem esse problema: cada linha é JSON, então um pedido carregando um cliente aninhado e cinco itens de linha chega completo.

Isso torna esta a conversão a escolher quando a estrutura é o dado. Se o destino consegue ler JSON delimitado por linha — e a maioria dos carregadores de data warehouse, produtores de fila e coletores de log consegue — você ganha as propriedades de streaming e contagem de linha sem pagar em estrutura.

Cada registro é escrito de forma compacta: sem indentação, sem quebras de linha internas, uma linha sem espaço extra por elemento. Se a origem era formatada com recuo, o arquivo fica substancialmente menor mesmo sem nada removido.

A ordem das chaves dentro de cada registro é preservada, e nenhuma chave é adicionada ou removida. Um registro que faltava um campo no array continua faltando esse campo na sua linha — NDJSON não reconcilia registros entre si como os gravadores tabulares fazem.

Uma quebra de linha dentro de um valor string é escapada dentro do JSON, não escrita literalmente, então nada nos dados pode produzir uma quebra de linha. É isso que torna a fronteira de linha uma garantia real em vez de convenção: wc -l é a contagem de registros, split -l 50000 produz pedaços válidos.

Também muda o que um arquivo quebrado custa. Um array JSON malformado não entrega nada — a análise falha e você não consegue dizer qual registro foi responsável. Uma linha malformada num arquivo NDJSON custa só essa linha, e o conversor que a lê de volta nomeia o número da linha.

Há uma ironia neste par que vale ser honesto. O benefício inteiro do NDJSON é que um consumidor nunca precisa segurar o arquivo inteiro, e produzi-lo aqui exige exatamente isso: um array JSON não é válido até que seu colchete de fechamento chegue, então o documento é analisado inteiro antes de a primeira linha poder ser escrita.

O limite prático é, portanto, sua própria memória em vez de um teto de tamanho. Se você mesmo está produzindo os dados, o conserto melhor é fazer a origem emitir NDJSON desde o início.

Um bom número aceita diretamente: jobs de carga do BigQuery e Snowflake apontados para JSON delimitado por linha, o DuckDB lendo o arquivo numa cláusula FROM, o ClickHouse com seu formato JSONEachRow, e a maioria das rotinas de importação de aplicação que descrevem sua entrada como um objeto por linha.

Um conjunto menor quer um protocolo em vez de registros. Requisições em massa do Elasticsearch e OpenSearch intercalam uma linha de instrução antes de cada documento, então um corpo tem o dobro de linhas de registros.

Nada nesta conversão é de mão única. Converter o resultado de volta para JSON remonta as linhas num array, e como cada linha já era um valor completo, o array que você recebe é o array com que começou — mesmos registros, mesmo aninhamento, mesma ordem de chave.

Vale saber isso ao decidir o que manter. Se o NDJSON é um artefato de transporte para uma carga só, não há motivo para arquivá-lo.

Nem todo consumidor se beneficia. Se o destino é um programa que vai ler o arquivo inteiro de uma vez — um fixture de teste, um script de seed, um corpo de requisição, uma importação de configuração — um array JSON é o que ele espera, e NDJSON só acrescenta um passo de remontagem do outro lado.

E se os registros vão ser consultados repetidamente em vez de carregados uma vez, nenhuma das duas formas é ideal. As duas repetem toda chave em todo registro, uma fatia grande de um arquivo real.

Nesta aba do navegador, em JavaScript puro, sem upload e sem conta. O plano gratuito aceita até 100 MB, e além disso a restrição é memória em vez de qualquer política nossa.

O ponto de privacidade é concreto para quem prepara uma carga em massa. Os arquivos convertidos para ingestão são logs de evento, históricos de pedido, registros de usuário e trilhas de auditoria, e entregar um a um serviço web para remover colchetes seria uma troca e tanto. Nada é enviado a lugar nenhum aqui.