JSON5 vs JSON

O que o JSON5 realmente adiciona

As extensões do JSON5 vêm todas da sintaxe de literais de objeto do ES5 — o lugar de onde o JSON veio originalmente. Os comentários voltam, como // até o fim da linha e /* block */. As chaves podem ficar sem aspas quando são identificadores válidos. As strings podem usar aspas simples e mais escapes. Os números ganham hexadecimal, ponto decimal à esquerda ou à direita, sinal de mais à esquerda e os valores especiais Infinity, -Infinity e NaN. Vírgulas finais são permitidas nos dois contêineres.

O custo: quem consegue ler o arquivo

O JSON.parse rejeita o primeiro comentário, aspa simples ou chave sem aspas que encontrar — não existe JSON5 nativo de navegador nem plataforma de servidor que o traga. Por isso, todo consumidor precisa da mesma biblioteca, fixada em comportamento compatível. No instante em que um documento deixa de ser JSON estrito, “qualquer parser serve” deixa de ser verdade — e essa garantia é o principal que a RFC 8259 comprava.

Um custo mais sutil é o zoológico de dialetos crescendo na lacuna: JSONC — apenas comentários e vírgulas finais — é o que o tsconfig e o VS Code realmente aceitam, e não é JSON5, já que o JSONC mantém aspas e números estritos. Arquivos derivam entre dialetos, editores discordam do realce, e um upgrade da cadeia de ferramentas pode transformar um constructo tolerado em erro. O JSON estrito não tem essa ambiguidade para administrar.

Onde cada um se encaixa

A divisão segue o leitor. Configuração escrita e revisada por pessoas se beneficia de comentários que explicam um campo, opções comentadas durante o debug e chaves sem aspas que reduzem ruído — esse é o território do JSON5, onde quer que a cadeia de ferramentas já o suporte. Tudo que um programa emite ou consome — payloads de API, estado armazenado, logs estruturados, mensagens de fila — permanece JSON estrito, onde a universalidade é o ponto principal.

• Formato de transmissão: JSON, sempre — qualquer consumidor precisa fazer o parse com zero configuração compartilhada.
• Configuração mantida por pessoas: JSON5 ou JSONC, se suas ferramentas já falam isso nativamente.
• Schema e documentação: o JSON estrito empurra a explicação para os schemas, porque comentários não têm onde viver.
• Dados em repouso: JSON — seus futuros leitores incluem ferramentas que ainda não foram escolhidas.

Convertendo entre eles

De JSON para JSON5 é de graça: JSON estrito já faz parse como JSON5, então “converter” é questão de estilo, não de estrutura. De JSON5 para JSON há perdas exatamente nos pontos que você esperaria: comentários não têm destino e desaparecem, e Infinity, -Infinity e NaN não têm valor em JSON, então viram null ou strings. Todo o resto sobrevive: chaves ganham aspas, aspas se normalizam, números hexadecimais chegam como o mesmo valor em decimal.

Você pode ver a fronteira com seus próprios olhos: cole um arquivo JSON5 em um validador estrito e o primeiro erro aponta o constructo que a cruzou — um comentário, uma aspa, uma vírgula final. O diagnóstico funciona no outro sentido também: se um arquivo de configuração precisará um dia ser lido por ferramentas estritas, mantenha-o dentro do subconjunto estrito desde o primeiro dia, porque fazer downgrade é a viagem com perdas.

Quando escolher cada um

Fique com JSON por padrão e recorra ao JSON5 apenas com um motivo. O motivo é um arquivo que pessoas mantêm e máquinas apenas consomem — configuração de build, feature flags, definições de ambiente — combinado com uma cadeia de ferramentas que já faz o parse de JSON5 nativamente. Se seus consumidores são desconhecidos, externos ou de longa vida, o rigor não é burocracia; é o contrato da interface.

A orientação se inverte com clareza: um arquivo de configuração que nunca precisou de um comentário também não precisa de JSON5, e um arquivo JSON5 que um serviço passou a fazer parse em tempo de execução virou discretamente um formato de transmissão — o que significa que ele quer ser JSON de novo.