Formatador de JSON

JSON é um subconjunto estrito do que os literais de objeto do JavaScript permitem, e a diferença entre os dois é exatamente de onde vêm a maioria dos erros de "JSON inválido". Uma vírgula final depois do último item em um array ou objeto é legal no JavaScript moderno mas um erro de sintaxe em JSON. Strings com aspas simples funcionam bem em JavaScript e são rejeitadas diretamente pelo JSON, que exige aspas duplas. Chaves de objeto sem aspas — escrever `{name: "value"}` em vez de `{"name": "value"}` — são uma abreviação válida de JavaScript e inválida em JSON. Nenhum desses são casos extremos obscuros; são exatamente os hábitos adquiridos ao escrever JavaScript que silenciosamente produzem um documento que parece JSON mas não é.

Comentários são a outra fonte frequente de confusão, porque bastantes formatos de arquivo de configuração que parecem JSON — e até alguns formatos derivados de JSON usados deliberadamente — permitem comentários `//` ou `/* */`, enquanto a especificação do JSON em si não tem nenhuma sintaxe de comentário. Copiar um arquivo de configuração "JSON" que realmente contém comentários em um analisador rigoroso falha imediatamente, e a correção é ou remover os comentários ou reconhecer que o arquivo nunca usou JSON padrão para começar.

Um analisador que apenas relata "JSON inválido" sem dizer onde deixa você escaneando o documento inteiro a olho nu procurando uma única vírgula faltando ou uma aspa não escapada, o que se torna genuinamente tedioso depois de algumas dezenas de linhas. Relatar a linha e coluna exatas do primeiro problema transforma essa busca em uma localização direta — o erro descreve um caractere específico, não uma falha geral vaga — que é a diferença entre corrigir uma grande resposta de API em segundos versus minutos de escaneamento manual.

Vale notar que o erro sempre aponta para o *primeiro* problema que o analisador encontra, não necessariamente cada problema no documento: um documento com dois erros de sintaxe vai relatar o primeiro, e corrigi-lo pode revelar o segundo apenas na próxima tentativa, já que um analisador que já falhou em entender a estrutura não pode continuar procurando confiavelmente mais problemas além do primeiro ponto onde ficou confuso.

JSON embelezado, com indentação e quebras de linha consistentes, existe para a pessoa que o lê — depurando uma resposta de API, revisando um arquivo de configuração, entendendo uma estrutura de dados de relance. Nada dessa estrutura importa para um programa analisando o mesmo JSON, por isso a saída minificada remove cada caractere que existe puramente para legibilidade humana: indentação, quebras de linha, e qualquer espaço em branco entre tokens que não seja necessário para separá-los. Os dados representados são idênticos em ambas as formas; apenas a contagem de bytes necessária para transmiti-los ou armazená-los difere, muitas vezes substancialmente para estruturas profundamente aninhadas.

A regra prática é simples: formate o JSON enquanto trabalha com ele — lendo, depurando, editando à mão — e minifique-o antes de ir para qualquer lugar que pague pelo seu tamanho, como o corpo de uma requisição HTTP, um parâmetro de consulta de URL, ou um valor armazenado em uma variável de ambiente com limite de comprimento.