JSON: formatação, validação e reparação do que está partido
Cole uma resposta de API, uma configuração ou um excerto de registo — obtém uma vista legível, uma árvore e a lista de tudo o que não cumpre a norma, com a linha e a posição exatas. Tudo é analisado no seu navegador: os dados nunca são enviados para lado nenhum nem guardados.
.json — o ficheiro é lido localmente. Também pode colar aquilo que ainda não é JSON válido: um registo, uma resposta de API com comentários, um excerto com vírgulas finais.
As chaves e a ordem são preservadas, a escrita dos números não muda.
Cole JSON acima e carregue em «Processar».
Cole JSON acima e carregue em «Processar».
Os dados não saem do seu navegador — a análise e a formatação correm localmente, sem enviar nada para um servidor.
Quatro edições da norma e em que diferem
O JSON é descrito por vários documentos, e eles não são idênticos. A escolha da especificação muda aquilo que a ferramenta considera um erro. RFC 4627 (2006) — a original. Um documento de nível superior só pode ser um objeto ou um array; um número ou uma cadeia isolados não são admitidos. Algumas bibliotecas antigas ainda se apoiam nesta edição. RFC 7159 (2014) — permitiu qualquer valor no nível superior. Desde então 42 e «texto» são documentos JSON autossuficientes. RFC 8259 (2017) — a que está em vigor. Acrescentou a exigência de UTF-8 para a troca entre sistemas e fixou que os nomes dentro de um mesmo objeto têm de ser únicos. ECMA-404 — descreve apenas a sintaxe. Não proíbe chaves duplicadas nem menciona substitutos solitários, por isso o conjunto de avisos é aqui o mais curto. Em caso de dúvida, fique pela RFC 8259: é o mais rigoroso dos conjuntos de regras em vigor, e o que passa nele é aceite em todo o lado.
Porquê uma análise própria e não o JSON.parse do navegador
O analisador integrado foi feito para a velocidade, não para o diagnóstico. Com os mesmos dados cala-se onde uma ferramenta devia falar: Uma mensagem sem coordenadas. O navegador diz «Unexpected token» e um deslocamento em carateres; aqui tem a linha, a posição e o que era esperado exatamente. Um único erro para todo o documento. Depois da primeira falha a análise recupera e mostra os restantes, em vez de o obrigar a corrigir um a um. As chaves duplicadas passam em silêncio. O JSON.parse fica com o último valor, e a perda só se nota em produção. Perde-se a escrita dos números. 1.0 passa a 1 e um inteiro acima de nove mil biliões muda os últimos algarismos — é exatamente assim que se estragam os identificadores vindos da base de dados. A ordem das chaves na saída mantém-se como na origem enquanto não pedir uma ordenação. Aqui os números saem por omissão tal como foram escritos: a ferramenta mostra o documento, não o resultado da sua interpretação.
O que o modo de correção repara exatamente
Os dados reais raramente são JSON limpo. O modo de reparação põe de acordo com a norma aquilo que chega de configurações, registos e API alheias: os comentários // e /* */ são removidos; as vírgulas antes do fecho de parênteses são retiradas; as aspas simples e tipográficas são uniformizadas para duplas; as chaves sem aspas e as numéricas passam a ficar entre aspas; True, NULL, None, undefined passam a true, false, null; NaN e Infinity passam a null, porque em JSON não há números sem valor finito; a escrita dos números — um mais a mais, um ponto na extremidade, zeros à frente; os carateres de controlo dentro das cadeias são escapados; o BOM no início do ficheiro e o invólucro JSONP são retirados. Nenhuma correção é feita em silêncio: cada uma entra na lista com o número de casos. Se o resultado não lhe agradar, desligue a caixa e o documento é verificado tal como está.