eu construo Toolz.dev& antes disso EU passei anos a enviar plugins WordPress e APIs Laravel Em tudo isso, a única mensagem de erro em que perdi mais horas é alguma variação do & quot; Token inesperado no JSON na posição 428." Ele não lhe diz quase nada Não há linha, nenhuma coluna, e a posição que nomeia é frequentemente alguns caracteres além da coisa que está errada Você acaba contando caracteres em um blob minificado à mão, ou colando toda a carga útil num editor e apertando os olhos Eu construí o Validador JSON então, nunca mais preciso fazer isso, e este é o guia para o que ele faz e por que validar JSON é mais complicado do que parece.
tl;dr: Um validador JSON verifica o texto contra a gramática na RFC 8259 e, quando o texto é quebrado, informa a linha, coluna e caractere exatos do primeiro erro, formulado em termos do que esperava Também captura coisas que um analisador normal esconde: chaves duplicadas, que são silenciosamente colapsadas para o último valor, e relata a estrutura de um documento válido (contagens de objetos, matriz e chave, profundidade de aninhamento e tamanho de byte).Não é um formatador Um formatador assume que a entrada já é válida; um validador é a coisa que você alcança precisamente quando não é.
O que significa para o JSON ser válido?
JSON é um formato pequeno com uma gramática estrita O padrão atual é RFC 8259, que se alinha com ECMA-4040, e entre eles definem exactamente o que um documento válido pode conter Um texto JSON é um valor único Esse valor é um objecto, um array, uma cadeia de caracteres, um número, true, false, ou null. Os objetos são enrolados em aparelhos e seguram separados por vírgulas "key": value pares. Matrizes são embrulhadas entre colchetes e mantêm valores separados por vírgulas As strings são embrulhadas em aspas duplas, nunca aspas simples Os números seguem uma forma específica sem zeros à esquerda e sem ponto decimal à direita Não há comentários, e não há vírgulas à direita.
Essa última frase é onde a maioria dos JSON do mundo real dá errado, porque muitas pessoas JSON escrevem à mão não é realmente JSON. É um arquivo de configuração com // comentários, ou um objeto copiado de fonte JavaScript onde aspas simples e vírgulas à direita estão bem, ou um acessório editado à mão onde alguém adicionou um campo e deixou uma vírgula pendente. Todos eles são rejeitados por um analisador estrito e um validador & #39; O trabalho é rejeitá-los em um local específico, e não com os ombros.
Vale a pena esclarecer um ponto, porque faz tropeçar pessoas que aprenderam JSON anos atrás: um valor simples é um documento JSON completo e válido. 42 por si só é válido JSON. Assim é "hello", e assim é true. O antigo RFC 4627 exigia que o nível superior fosse um objeto ou uma matriz, mas essa restrição foi descartada em 2014, quando a RFC 7159 (mais tarde 8259) a substituiu Se uma ferramenta lhe disser 42 não é JSON válido, essa ferramenta segue uma especificação obsoleta há mais de uma década.
Por que JSON.parse é um repórter de erro tão ruim?
A razão pela qual um validador dedicado ganha seu lugar é que o analisador embutido em seu idioma é otimizado para o caminho feliz, não para explicar o triste. JSON.parse em um navegador lança um SyntaxError cuja mensagem é específica do motor e geralmente lhe dá um deslocamento de caracteres sem linha ou coluna V8 diz & quot; Token inesperado} em JSON na posição 148." Firefox diz " JSON.parse: caractere inesperado na linha 1 coluna 149." Safari diz algo diferente novamente Nenhum deles lhe diz o que eles esperavam, e a posição é medida desde o início da string, o que é inútil no momento em que seu JSON tem mais de um par de linhas.
O validador em Toolz.dev não usa JSON.parse. Ele anda o texto em si com um analisador recursivo-descendente escrito à mão, rastreando a linha e a coluna à medida que avança, então quando ele parar pode entregar-lhe todas as três coordenadas: a linha, a coluna e o deslocamento absoluto do caractere Mais importante, ele sabe a regra de gramática que estava no meio, então a mensagem é específica Em vez de & quot; token inesperado, & quot; você obtém " Vírgula à direita não é permitida antes da chave de fechamento, & quot; ou " As chaves de objeto devem ser cadeias com aspas duplas, & quot; ou " Esperava-se uma vírgula ou uma chave de fechamento após um membro de objeto. " Essa diferença é a diferença entre fixar o arquivo em cinco segundos e caçar por ele.
Também desenha um acerto sob o carácter exacto na linha ofensiva, da forma como um compilador faz Quando você está a ver a linha 34 de um ficheiro de configuração, o & quot; coluna 12 & quot; está bem, mas a ^ sentar-se diretamente sob a citação perdida é mais rápido.
Quais erros JSON o validador detecta pelo nome?
Estas são as falhas que vejo com mais frequência, tanto no meu próprio trabalho quanto nos threads de suporte para ferramentas como esta O validador nomeia cada um em vez de relatar um erro genérico de token.
| Erro | Como é | Por que é inválido |
|---|---|---|
| Vírgula | {"a": 1,} ou [1, 2,] |
JSON não tem vírgulas à direita; a gramática padrão & #39; s simplesmente não permite um antes de uma cinta de fechamento ou colchete |
| Cotações únicas | {'name': 'Liton'} |
Strings e chaves devem usar aspas duplas; aspas simples são um hábito JavaScript, não JSON |
| Vírgula ausente | {"a": 1 "b": 2} |
Cada membro após o primeiro deve ser precedido por uma vírgula |
| comentários | {"a": 1} // note |
JSON não possui sintaxe de comentários; o // e tudo depois é conteúdo inesperado |
| Chave não citada | {name: "Liton"} |
As chaves são strings e devem ser citadas, ao contrário dos literais de objetos JavaScript |
| Zero líder | {"n": 007} |
Um número pode não ter um zero à esquerda, portanto 007 é inválido; escrever 7 |
| Ponto decimal final | {"n": 5.} |
A fração após uma vírgula precisa de pelo menos um dígito |
| Personagem de controle bruto | uma guia literal ou nova linha dentro de uma string | Os caracteres de controle dentro das strings devem ser escapados como \t, \n, e assim por diante |
| NaN ou Infinito | {"n": NaN} |
Estes são válidos em JavaScript, mas não são valores JSON |
| String não terminada | {"a": "oops} |
Uma string sem citação de fechamento é executada até o final da entrada |
Cada um deles produz uma mensagem em linguagem simples e uma posição O caso zero inicial é um bom exemplo de por que um analisador específico ajuda: um analisador genérico lê 007 como o número 0 e então tropeça no 7 como & quot; conteúdo extra, & quot; apontando para você no 7, quando o problema real são os dois zeros na frente dele O validador verifica primeiro o padrão zero à esquerda e informa isso diretamente.
E quanto às chaves duplicadas?
Aqui está aquele que me mordeu na produção mais do que qualquer erro de sintaxe, porque não é um erro de sintaxe em tudo Isso é válido JSON:
{
"timeout": 30,
"retries": 3,
"timeout": 60
}
A RFC 8259 diz os nomes dentro de um objecto & quot; DEVE ser único, & quot; mas não proíbe duplicados, por isso é necessário que um analisador aceite isto O que acontece a seguir é onde o problema começa: o padrão diz que o comportamento com nomes duplicados é imprevisível e, na prática, quase todos os analisadores mantêm o último valor e descartam silenciosamente os anteriores. Então, esse objeto analisa {"timeout": 60, "retries": 3}, e o "timeout": 30 você cuidadosamente definido na parte superior do arquivo se foi sem um aviso Se duas pessoas editaram a configuração, ou uma mesclagem deu errado, ou uma etapa de modelo emitiu a mesma chave duas vezes, você tem um bug que nenhum analisador jamais sinalizará para você.
O validador sinaliza-o A detecção de chave duplicada está ligada por padrão, e como uma duplicata é legal, ela é relatada como um aviso e não como um erro: o documento ainda é válido, mas você é informado de cada chave que aparece mais de uma vez no mesmo objeto, com sua linha e a Ponteiro JSON caminho para que você possa encontrá-lo dentro de uma estrutura aninhada. Se você realmente deseja duplicatas, pode desligar o cheque. Na maioria das vezes, ver o aviso é o momento em que você percebe o que deu errado.
Como um validador é diferente de um formatador?
As pessoas usam as palavras de forma intercambiável, e as ferramentas se sobrepõem, mas elas respondem a perguntas diferentes. A formatador json leva JSON você já acredita que é válido e re-imprime-lo com indentação consistente para que um ser humano pode lê-lo Se você entregar um formatador quebrado JSON, o melhor que ele pode fazer é recusar Um validador' todo o propósito é o caso quebrado: ele diz-lhe onde e por que O validador Toolz.dev faz ambos os trabalhos, porque uma vez que ele confirmou um documento é válido já analisou, por isso ele bonita-imprime o resultado na mesma passagem Mas o recurso de manchete é o diagnóstico, não o recuo.
A mesma relação é válida com as ferramentas vizinhas. O Minificador JSON retira espaços em branco para reduzir uma carga útil, o que só faz sentido em entradas válidas. O Classificador JSON reordena chaves para diferenças estáveis, novamente em entrada válida. O JSON escapa e desescapa tool lida com a incorporação de JSON dentro de uma string. E o Testador JSONPath consultas um documento que você já confirmou está bem formado A validação é o passo que vem antes de todos eles, por isso é o que EU executo primeiro sempre que uma resposta de API ou um arquivo de configuração está se comportando de forma estranha Há um tour mais amplo de como estes se encaixam no Guia definitivo para ferramentas JSON.
O que as estatísticas da estrutura lhe dizem?
Quando um documento valida, a ferramenta relata sua forma: quantos objetos e matrizes ele contém, quantas chaves, quantas strings, números, booleanos e nulos, quão profundamente ele nidifica e seu tamanho em ambos os caracteres e bytes UTF-8 Isso não é decoração Quando você recebe uma resposta API desconhecida, o número de profundidade informa rapidamente se você está lidando com um registro plano ou uma árvore profundamente aninhada, e a contagem de chaves informa aproximadamente quanto trabalho será analisá-lo.
A figura de bytes importa mais do que as pessoas esperam Os limites de tamanho de solicitação, os limites de filas de mensagens e os limites de colunas do banco de dados são quase sempre medidos em bytes, não em caracteres, e os dois diferem no momento em que seu JSON contém algo fora do ASCII Um emoji ou um nome acentuado é um caractere na tela, mas dois, três ou quatro bytes no fio Se uma carga estiver colidindo com um limite de 256 KB, a contagem de caracteres enganará você e a contagem de bytes não. O validador calcula o verdadeiro comprimento de bytes UTF-8 para que o número que você vê seja o número que o limite está contando.
Como EU uso
Meu fluxo de trabalho é chato e rápido, que é o ponto Quando uma integração quebra, EU copio o corpo de resposta bruta direto da guia de rede e colar no validador Se for válido, o resultado verde e as estatísticas me dizem que o problema está em outro lugar, no meu código, em vez de seus dados, e EU descartei toda uma classe de causas em dois segundos Se for inválido, EU obtenho a linha e coluna, fixá-lo, e seguir em frente Quando estou editando manualmente um arquivo de configuração, EU colo-o antes de cometer, principalmente para pegar a vírgula final Eu sempre pareço deixar para trás e a chave duplicada ocasional de uma cópia-colar Para qualquer um montando seu próprio kit, o validador senta-se ao lado dos outros essenciais no Kit de ferramentas para desenvolvedores web.
O ângulo de privacidade também não é uma reflexão tardia As pessoas JSON mais precisam validar é exatamente o JSON com o qual devem ter mais cuidado: respostas API carregando tokens, arquivos de configuração com credenciais, cargas úteis com dados do cliente Tudo o que o validador faz acontece no seu navegador, em JavaScript, na sua máquina Nada é carregado, registrado ou armazenado Você pode provar abrindo a guia de rede enquanto você valida, ou desconectando-se da internet e observando a ferramenta continuar funcionando.
Perguntas frequentes
Por que meu JSON diz que é inválido quando parece bom?
As razões mais comuns são uma vírgula atrás antes de uma cinta de fechamento ou colchete, aspas simples onde JSON requer aspas duplas, uma vírgula ausente entre dois membros ou um comentário, que JSON não permite em tudo Todos os quatro são fáceis de perder a olho nu, especialmente em um arquivo grande O validador nomeia qual encontrou e dá-lhe a linha e coluna exata, então em vez de digitalizar todo o documento você pular direto para o caractere que parou.
Um único número ou string é JSON válido por si só?
Sim. Sob RFC 8259, qualquer valor JSON é um texto JSON completo, então 42, "hello", true, e null todos validam por si mesmos A regra de que o nível superior tinha que ser um objeto ou uma matriz veio do RFC 4627 mais antigo e foi removido em 2014 Uma ferramenta que rejeita um valor simples está seguindo uma especificação obsoleta.
O validador altera ou carrega meus dados?
Não. Ele analisa o texto no seu navegador e nunca o envia para lugar nenhum Em um documento válido produz uma cópia bastante impressa por conveniência, mas essa cópia é gerada localmente e o original nunca é transmitido, registrado ou armazenado. Como não há servidor de ida e volta, a ferramenta também funciona com a rede desconectada após o carregamento da página.
Por que devo me preocupar com chaves duplicadas se o JSON ainda é válido?
Porque uma duplicata quase sempre significa perda de dados que você não pretendia O padrão permite chaves duplicadas, mas deixa seu manuseio indefinido e, na prática, os analisadores mantêm apenas o último valor e deixam cair o resto Então, um config onde timeout aparece duas vezes silenciosamente perde a primeira configuração O validador avisa sobre cada chave repetida com sua posição, que geralmente é o momento em que você identifica uma mesclagem ruim ou um erro de copiar e colar.
Isso pode validar o JSON com comentários, como um arquivo de configurações do tsconfig ou do VS Code?
Não, e isso é deliberado Esses arquivos são JSON com Comentários (JSONC) ou JSON5, que são formatos separados que relaxam as regras O validador tem como alvo a RFC 8259 estrita, por isso sinalizará um comentário como um erro Se você precisar de comentários em um arquivo de configuração, isso é um sinal de que o formato deve ser algo construído para ele, como YAML ou TOML, em vez de JSON esticado além do que o padrão permite.
Qual é a diferença entre validar e formatar JSON?
Validar verifica se o texto obedece à gramática JSON e, caso não o faça, informa exatamente onde ele quebra A formatação assume que o texto já é válido e apenas ajusta seu espaço em branco para legibilidade Você procura um validador quando algo está errado e precisa saber o quê; você procura um formatador quando tudo está bem e você só quer que ele seja legível Essa ferramenta faz as duas coisas, mas sua razão de existir é o diagnóstico.
Qual o tamanho de um arquivo que posso validar?
Confortavelmente nas dezenas de megabytes, limitado apenas pelo seu navegador & #39; s memória, porque todo o documento é analisado em uma passagem no seu dispositivo Não há limite de tamanho de upload porque não há upload Para um arquivo genuinamente enorme, nos gigabytes, um validador de linha de comando de streaming é o melhor instrumento, uma vez que o navegador mantém todo o texto na memória de uma só vez.
