JaguarVPN logo

Formatador e validador de JSON

Formate, valide e inspecione JSON — com um erro que aponta para o caractere exato.

Saída
{
  "name": "jaguar",
  "speed_kph": 80,
  "habitats": [
    "rainforest",
    "wetland"
  ],
  "conservation": {
    "status": "Near Threatened",
    "assessed": 2016
  },
  "nocturnal": null
}

JSON válido

Tamanho
145 B
Minificado
145 B
Poupado
0%
Chaves
7
Objetos
2
Profundidade máxima
3

Os quatro erros

Quase todos os documentos recusados falham por um do mesmo punhado de motivos, e os quatro são coisas que o JavaScript teria aceitado. É essa a armadilha: o JSON parece um literal de objecto de JavaScript e é um subconjunto bastante mais estrito dele.

EscritoProblemaCorrecto
{"a": 1,}Vírgula a mais no fim{"a": 1}
{'a': 1}Plicas{"a": 1}
{a: 1}Chave sem aspas{"a": 1}
{"a": 1} // noteComentárioRemova-o

Mais dois, que apanham menos gente mas são mais difíceis de ver. NaN, Infinity e undefined são valores válidos em JavaScript e nenhum deles é um valor de JSON — a substituição é null ou uma cadeia de texto. E uma mudança de linha literal dentro de uma cadeia é inválida; ali têm de estar os dois caracteres \n.

Como este validador reporta erros

Vale a pena explicar, porque é a razão para preferir um formatador a outro. O JSON.parse do próprio navegador é usado para o caminho de sucesso, mas não para descrever falhas: o formato das suas mensagens é um detalhe de implementação que mudou duas vezes em versões recentes do V8. O mesmo documento partido reporta «Unexpected end of JSON input» numa versão do Node e «Expected ‘,’ or ‘}’ after property value at position 6» noutra, e às vezes não dá posição nenhuma.

Por isso, quando a análise falha, esta página percorre ela própria a gramática e indica a linha, a coluna e o carácter em que parou, com um sinal por baixo. A mensagem que recebe não depende do navegador que calhou estar a usar.

O problema de precisão de que ninguém o avisa

Este provoca defeitos a sério e quase nunca é mencionado. Os números de JSON passam a números de JavaScript, e os números de JavaScript são duplos IEEE 754. Inteiros acima de 2⁵³ — cerca de 9,007 mil biliões — não podem ser representados exactamente.

Um identificador de 19 dígitos do género dos que o Twitter, o Discord e a maioria dos esquemas ao estilo Snowflake produzem volta alterado, em silêncio, sem erro nenhum em lado nenhum. Cole {"id": 9007199254740993} no formatador acima e veja o último algarismo mexer-se.

A correcção é do lado de quem produz: envie os identificadores de 64 bits como texto. Todas as APIs que foram mordidas por isto já o fazem.

Quando recorrer a outra coisa

Esta página serve para ler e corrigir um documento que tem à sua frente. Há duas tarefas vizinhas para as quais é a ferramenta errada:

  • Consultar e transformar. Para isso há o jq na linha de comandos, que também lê em fluxo em vez de carregar tudo para memória — a resposta certa para tudo acima de alguns megabytes.
  • Impor uma forma. Isso é o JSON Schema, e validar a estrutura é uma pergunta diferente de validar a sintaxe. Um documento pode estar perfeitamente bem formado e continuar sem nenhum dos campos que a sua API exige.

Relacionado

Se o JSON chegou codificado em Base64, descodifique-o primeiro. Se saiu de um token, o descodificador de JWT separa e analisa os dois segmentos por si. E se vai entrar num URL, o codificador de URL mostra qual das três regras de escape quer.

Perguntas sobre JSON

Porque é que o meu JSON falha se parece bem?

Quatro causas explicam quase tudo. Uma vírgula a mais antes de um fecho, que o JavaScript aceita e o JSON não. Plicas em vez de aspas. Comentários, para os quais o JSON não tem sintaxe nenhuma. E chaves sem aspas — {name: "x"} é JavaScript válido e JSON inválido. O validador acima diz qual delas encontrou, em vez de repetir o erro do analisador.

É seguro colar aqui dados de produção?

Nesta página, sim — é analisado no seu navegador e não há pedido nenhum que os pudesse levar. Pode confirmá-lo vendo o separador de rede enquanto escreve. Ainda assim, vale a pena manter o hábito em geral: o JSON que se depura costuma ser uma resposta real de API com registos reais de clientes, e muitos formatadores em linha enviam-no para um servidor para fazer o trabalho. Verifique antes de colar, seja qual for a ferramenta.

O JSON pode ter comentários?

Não. Douglas Crockford retirou-os de propósito, porque as pessoas tinham começado a meter neles directivas de análise. Se precisa de comentários num ficheiro de configuração, as respostas habituais são JSON5 ou JSONC (o que o VS Code usa), ou a convenção de uma chave "_comment" que os consumidores ignoram. Nada disso é JSON, por isso um analisador estrito continuará a rejeitá-los.

O que faz «ordenar chaves» e porque haveria de o querer?

Reordena alfabeticamente, de forma recursiva, as chaves de cada objecto. Os objectos JSON não têm ordem por especificação, portanto dois documentos que só diferem na ordem das chaves são equivalentes — mas um diff de texto mostra todas as linhas como alteradas. Ordenar os dois antes de comparar reduz isso às diferenças que interessam de facto.

Há limite de tamanho?

Só o do seu navegador. A análise acontece na própria página, por isso alguns megabytes num computador de secretária não são problema e vão dar trabalho a um telemóvel mais antigo. Documentos muito grandes tratam-se melhor com jq na linha de comandos, que lê em fluxo em vez de manter a árvore toda em memória.

Porque é que o meu inteiro grande volta errado?

Porque os números do JSON passam a números de JavaScript, que são duplos IEEE 754, e esses perdem precisão acima de 2⁵³ — cerca de 9,007 mil biliões. Um identificador de 19 dígitos ao estilo do Twitter ou um bigint de base de dados volta subtilmente alterado. Não é um defeito do formatador; é a razão pela qual as APIs que usam identificadores de 64 bits os enviam como texto.

Última revisão . Encontrou algo desactualizado? Diga-nos.