Ferramentas para desenvolvedores · Formatador e validador JSON
Toda a gramática JSON em uma página: seis tipos de valores, dois contêineres
· Fundo
JSON padrões validação
Toda a gramática de JSON cabe em uma página, e saber de cor torna óbvio cada erro do validador. Esta postagem aborda os seis tipos de valor, os dois contêineres e o punhado de regras que enganam as pessoas.
Cada erro que você já viu vem de uma página
Todo erro de sintaxe é uma expectativa quebrada em uma gramática compacta. Depois que um objeto é aberto, um analisador espera um nome de membro entre aspas ou uma chave de fechamento; depois de um nome, espera dois pontos; depois de um valor, espera uma vírgula ou o final do contêiner. Ler um erro como uma transição falhada é mais útil do que tratar o personagem relatado como misterioso.
ToolAcre aceita os valores JSON padrão e espaços em branco e, em seguida, aplica dois limites práticos de entrada. Texto com mais de 8,000,000 caracteres é rejeitado antes da análise, e o aninhamento do scanner além dos contêineres 512 é rejeitado em vez de ser percorrido indefinidamente. Esses são limites do produto, não novos tipos de JSON. Dentro deles, o diagnóstico identifica o primeiro ponto onde o fluxo de tokens não consegue mais satisfazer a gramática.
Os seis valores – objeto, array, string, número, true/false e null, e o fato de que não há mais nada
Um valor JSON é um objeto, array, string, número, booleano ou nulo. Objetos e matrizes podem conter qualquer um dos seis, incluindo mais contêineres. As grafias literais são exatamente `true`, `false` e `null`; a capitalização não é flexível. Tokens como `True`, `None`, `undefined`, `NaN` e `Infinity` estão fora do estrito JSON mesmo quando outro idioma reconhece alguns deles.
Esta pequena lista torna a classificação uma técnica de depuração útil. Em `{"reading": NaN}`, os dois pontos introduzem corretamente um valor, mas `N` não pode iniciar nenhum valor permitido. Substitua-o somente depois de decidir o que os dados devem significar, talvez `null` ou um status entre aspas. Uma ferramenta de sintaxe pode rejeitar o token; não pode escolher o substituto da aplicação ou decidir se o campo pertence a ele.
Objetos e matrizes - membros separados por vírgula, dois pontos e por que RFC 8259 deixa ordenação e nomes duplicados para implementações
Os objetos contêm membros name/value separados por vírgula. Cada nome é uma string entre aspas duplas seguida por dois pontos e um valor. As matrizes contêm valores separados por vírgula, sem nomes ou dois pontos. Os contêineres `{}` e `[]` vazios são válidos, mas uma vírgula não pode iniciar, seguir ou aparecer duas vezes. A correspondência de cada delimitador com seu contêiner expõe rapidamente muitas falhas aparentes de “token inesperado”.
Espera-se que os nomes dos objetos sejam exclusivos, mas a ortografia duplicada não é rejeitada por este validador. `{"port": 80, "port": 443}` analisa e `JSON.parse` retém o valor posterior. A formatação emite então apenas o membro sobrevivente, de modo que o texto anterior não pode ser recuperado do resultado. As posições do array se comportam de maneira diferente: cada elemento permanece presente e sua ordem faz parte do valor.
Strings e números com precisão
Strings usam aspas duplas. Uma barra invertida pode introduzir uma aspa, barra invertida, barra, `b`, `f`, `n`, `r`, `t` ou escape Unicode de quatro dígitos; caracteres de controle brutos são proibidos. Aspas simples são tokens inválidos comuns fora de uma string. Essas regras explicam por que literais JavaScript copiados e texto multilinha colado podem parecer legíveis enquanto falham na validação estrita de JSON.
Um número pode ter um sinal de menos, uma parte inteira, uma fração opcional e um expoente opcional. Não pode começar com `+`, usar notação hexadecimal, carregar um zero à esquerda antes de outro dígito ou soletrar um valor não finito. `-0.25e+2` é válido; `01`, `.5`, `2.` e `Infinity` não são. A análise verifica a gramática, não se JavaScript pode preservar cada dígito com exatidão.
Espaço em branco e o nível superior
Fora das strings, o espaço em branco JSON é limitado a espaço, tabulação horizontal, avanço de linha e retorno de carro. Um espaço ininterrupto copiado de uma página da web não é intercambiável com um espaço comum. A formatação pode escolher livremente entre os espaços em branco permitidos em torno dos tokens, mas deve preservar os espaços em branco que pertencem a uma string entre aspas porque esses caracteres são dados.
O documento completo pode ser qualquer valor JSON único, não apenas um objeto ou array. `42`, `false` e `"ready"` são textos de nível superior válidos. O que é proibido é um segundo valor após o primeiro: `42 43` são dois documentos, não um. Essa distinção explica por que JSON delimitado por nova linha requer manipulação registro por registro em vez de uma análise comum de todo o arquivo.
Exemplo resolvido: analisar um pequeno documento manualmente
Pegue `{"order": [17, null, {"paid": true}], "note": "ship soon"}`. O objeto raiz inicia um membro chamado `order`; seu valor é uma matriz contendo um número, nulo e outro objeto. Uma vírgula então introduz `note`, cujo valor é uma string com uma nova linha de escape. Cada dois pontos, vírgula e delimitador de fechamento têm uma função gramatical.
Agora remova a aspa antes de `paid`. Após a chave aninhada, o analisador espera uma chave de fechamento ou um nome entre aspas, portanto falha em `p`. Como alternativa, adicione uma vírgula após `true`; o analisador aceita a vírgula e falha em `}` porque outro membro deve seguir. Prever essas posições manualmente transforma a validação em confirmação e desencoraja edições aleatórias de pontuação.
O que isso não cobre
A gramática não possui data, dinheiro decimal, binário, UUID ou tipo de duração. Os aplicativos geralmente representam esses conceitos com strings ou números e impõem convenções separadamente. Um carimbo de data/hora pode ser uma string JSON perfeitamente válida, embora contenha uma data impossível. Da mesma forma, um objeto sintaticamente válido pode omitir propriedades necessárias ou usar unidades erradas sem violar uma única regra de análise.
ToolAcre não realiza verificações de esquema, validação de domínio ou canonização. Ele também não reinterpreta recursos JSON5 ou JSONC, como comentários e vírgulas finais. Seu trabalho é mais restrito: aceitar um texto JSON estrito dentro dos limites do produto, formatar o valor analisado e identificar falhas de sintaxe. Mantenha as perguntas posteriores sobre forma e significado na camada de validação do aplicativo consumidor.
Conclusão: memorize a gramática, confie na posição
A lista de verificação durável é curta: seis categorias de valores, nomes de objetos entre aspas, vírgulas apenas entre itens, dois pontos apenas entre nomes e valores, escapes de string estritos, ortografia estrita de números, quatro caracteres de espaço em branco e exatamente um valor de nível superior. Quando um documento falha, identifique o que a gramática permitiu imediatamente antes da posição relatada e compare essa expectativa com o caráter realmente presente.
Confie na posição como o primeiro ponto impossível, nem sempre o personagem que precisa ser apagado. Uma chave de fechamento pode ser destacada porque uma vírgula anterior prometia outro membro; uma carta inocente pode ser destacada porque falta a citação inicial. Repare a causa, execute novamente a validação e repita. Para entradas superdimensionadas ou extremamente profundas, aborde o limite do produto com 8 milhões de caracteres ou 512 de profundidade antes que o diagnóstico de sintaxe possa ajudar.