Converter NDJSON para XML

Os dois formatos ficam em extremos opostos da mesma questão. NDJSON é feito para que nenhuma linha dependa de outra: dá para cortar em qualquer ponto, retomar depois de uma falha, processar sem carregar tudo. Um documento XML é o outro extremo — não é válido até a tag de fechamento da raiz chegar, então o arquivo inteiro é uma unidade só do primeiro ao último byte.

É essa propriedade que vale planejar, mais que os nomes dos elementos. Uma conversão de uma exportação grande produz um documento único que precisa ser transmitido, interpretado e aceito por inteiro, e uma falha em qualquer ponto dele falha tudo. Onde o sistema de destino tem limite de tamanho de mensagem, dividir a origem em lotes antes de converter é a diferença entre um envio que retoma e um que recomeça do zero.

A forma é fixa porque a entrada é fixa. Um arquivo delimitado por linha sempre é uma lista, e uma lista não tem nome próprio, então o documento é um elemento raiz contendo um elemento item por registro. Cada campo vira um elemento filho nomeado com sua chave, e um objeto aninhado vira elementos aninhados abaixo dele.

Não há opção de mudar esses dois nomes durante a conversão, e não há jeito sensato do conversor adivinhá-los — nada num arquivo NDJSON diz se os registros são pedidos, sinistros ou medições. A saída é deliberadamente o documento correto mais simples possível, o que torna a renomeação seguinte um simples buscar e substituir.

Quase todo sistema que recebe XML nomeia seu elemento de registro num schema: um documento Pedidos contendo elementos Pedido, um Lote contendo Transacoes. Então os dois nomes genéricos são espaços reservados, e substituí-los é trabalho de dois minutos em qualquer editor.

Fazer isso antes do primeiro envio, e não depois de uma rejeição, vale a pena. Um sistema que valida contra um schema vai rejeitar o documento inteiro pelo nome do elemento e geralmente vai avisar de um jeito que não deixa isso óbvio. Se os envios vão ser regulares, a renomeação pertence ao script que move o arquivo, não à memória de uma pessoa.

Uma lista em XML sempre foi a mesma tag escrita várias vezes, então um registro com três etiquetas produz três elementos tags um do lado do outro. Sem numeração, sem junção, sem decisão tomada por você — a estrutura chega intacta.

Esse é o argumento mais forte a favor do XML sobre os destinos tabulares para o mesmo arquivo. Converter esses registros para CSV força uma escolha entre colunas numeradas, uma string unida e linhas extras, e cada uma delas perde alguma coisa. Um pedido com cinco itens converte para XML sem nenhuma concessão, e é frequentemente por isso que o sistema de destino escolheu XML em primeiro lugar.

Chaves JSON podem ser qualquer coisa: espaços, barras, um dígito no início, um símbolo de moeda. Nomes de elemento XML não podem. O escritor reescreve em vez de falhar — caracteres proibidos em XML viram sublinhado e um nome começando com dígito ganha um antes — então um campo chamado "2024 total" vira um elemento _2024_total.

Exportações geradas por máquina esbarram nisso mais que exportações escritas à mão. Qualquer coisa indexada por uma data, um nome de métrica ou uma referência de cliente vai produzir nomes reescritos, e a reescrita é silenciosa. Se o destino tem um schema, esses elementos vão falhar na validação com um nome que você não reconhece.

A reconciliação que as conversões tabulares fazem não acontece aqui, e não precisa acontecer. Cada elemento item carrega exatamente os campos que sua linha tinha, então um arquivo de eventos misturados produz elementos item de várias formas dentro de um documento — o que é XML válido e geralmente inválido contra um schema.

Um schema que declara uma sequência fixa de elementos filhos vai rejeitar o primeiro registro que omitir um deles. Onde isso é o caso, filtre a origem para um tipo de registro antes de converter, ou acrescente os elementos faltantes vazios — e note que um elemento vazio e um elemento declarado como nulo são coisas diferentes para um validador rigoroso.

E comercial, colchetes angulares e aspas duplas num valor são escapados, o que impede que uma descrição de produto ou uma mensagem de log contendo marcação encerre o documento cedo demais. Todo o resto, incluindo texto acentuado e não latino, é escrito em UTF-8.

Um nulo em JSON vira um elemento vazio: a tag existe sem nada entre as duas metades. Alguns schemas querem xsi:nil no lugar disso, e alguns querem o elemento ausente por completo. Se o destino distingue esses casos, é uma edição via script sobre a saída, não algo que a conversão consiga decidir sozinha.

Todo nome de campo aparece duas vezes por registro — uma na tag de abertura e outra na de fechamento — onde o NDJSON escreve uma vez só. Some a indentação e um documento de valores curtos com nomes de campo longos chega a duas ou três vezes o tamanho do arquivo de origem.

Num envio por SFTP isso é irrelevante. Numa fila de mensagens com limite de tamanho, decide quantos registros cabem num lote. A resposta quase sempre é compressão em vez de reestruturação: XML desse tipo é extremamente repetitivo e comprime muito bem com gzip.

A conversão roda nesta aba do navegador: o arquivo é interpretado linha a linha e o documento é escrito por um pequeno escritor na página. Nada é enviado, não há cadastro nem fila, e o plano gratuito aceita até 100 MB, com a memória como teto prático, porque o documento é montado por inteiro.

Os dados que passam por essa rota raramente são triviais. Envios a órgãos reguladores, bancos, seguradoras e sistemas parceiros são exatamente os arquivos com cláusula de confidencialidade anexada, e rodar a conversão por um serviço web desconhecido seria uma segunda divulgação que ninguém autorizou.