Formatador de JSON
Formate JSON com 2 espaços, 4 espaços ou tabulação, sem perder um único dígito.
Nada do que você cola sai do seu navegador. A lista de permissões connect-src transforma isso em uma garantia do navegador, e não em uma promessa. Confira você mesmo
Formatar JSON é acrescentar o espaço em branco de que uma pessoa precisa e uma máquina não: um membro por linha, indentação consistente, um espaço depois de cada dois-pontos. Os dados não mudam. Só muda a apresentação deles.
A parte fácil de errar é exatamente essa última frase. Um formatador que faz o parsing do seu documento para valores JavaScript e os serializa de volta já reescreveu os seus números antes de imprimir qualquer coisa, e a maioria faz exatamente isso.
O que a formatação não muda
Este formatador reemite os tokens que leu, em vez de reserializar valores já parseados. Isso significa que o texto de cada número, string e literal volta byte a byte, e só o espaço em branco entre eles é reescrito.
Isso importa mais do que parece. Passe um documento com um ID de 19 dígitos por um formatador construído sobre JSON.parse e JSON.stringify e o ID volta diferente, silenciosamente, sem nenhum aviso na interface.
- Os números mantêm o texto exato
- 1.50 continua 1.50, 1e3 continua 1e3, -0 continua -0, e 12345678901234567890 continua ele mesmo em vez de virar 12345678901234567000.
- As strings são copiadas literalmente
- Um \u00e9 escapado continua escapado e um é literal continua literal. Formatar não é a hora de decidir como uma string deve ser codificada, então ele não decide.
- A ordem das chaves é preservada
- A não ser que você ligue a ordenação explicitamente. Objetos JSON não têm ordem segundo a especificação, mas na prática todo parser preserva a ordem de inserção, e os diffs dependem disso.
- Chaves duplicadas são mantidas e sinalizadas
- Remover uma delas mudaria o que quem consome o documento enxerga. Em vez disso você recebe um aviso apontando as duas posições.
Qual indentação escolher
Dois espaços é o padrão aqui porque é o que npm, Prettier e praticamente todo o ferramental JavaScript emitem, e porque o aninhamento em JSON fica profundo rápido. Quatro espaços leem melhor em arquivos de configuração rasos. Tabulações deixam cada leitor escolher a própria largura, que é o argumento de acessibilidade a favor delas, e comprimem um pouco melhor.
Para qualquer coisa que seja transmitida em vez de lida, minifique. Espaço em branco em uma resposta JSON é puro overhead, e em um payload de API típico representa entre 10 e 20 por cento dos bytes.
Fins de linha e quebra de linha final
A saída usa LF por padrão. Existe uma opção CRLF porque o ferramental do Windows e alguns sistemas de CI se importam com isso, e porque um arquivo que mistura os dois gera um diff em que toda linha parece alterada.
Espaço em branco fora das strings não significa nada para um parser, então nada disso afeta a validade. Afeta os seus diffs, que na prática é o que você percebe.
How to do this in code
A mesma operação em código. Todas essas alternativas produzem indentação de dois espaços; todas elas também vão reescrever os seus números, que é o preço que você aceita quando o payload não tem inteiros grandes.
js JavaScript
O terceiro argumento aceita um número de espaços ou uma string para usar como unidade de indentação.
const pretty = JSON.stringify(JSON.parse(text), null, 2);
// Tabs
const tabbed = JSON.stringify(JSON.parse(text), null, '\t'); py Python
ensure_ascii vem como True por padrão, o que transforma cada caractere acentuado em um escape \u. Quase ninguém quer isso.
import json
pretty = json.dumps(json.loads(text), indent=2)
# Keep non-ASCII readable rather than escaping it
pretty = json.dumps(json.loads(text), indent=2, ensure_ascii=False)
# From the command line
# python -m json.tool --indent 2 input.json sh jq
O jq não ordena nada por padrão. Use -S para ordenar as chaves.
jq . input.json # 2 spaces, the default
jq --indent 4 . input.json
jq --tab . input.json
jq -c . input.json # compact go Go
json.Indent é o que mais se aproxima, em uma biblioteca padrão, do que esta página faz: reformata os bytes sem decodificar os valores.
var buf bytes.Buffer
if err := json.Indent(&buf, data, "", " "); err != nil {
return err
}
// json.Indent works on raw bytes, so unlike Unmarshal it does
// not touch your numbers at all. rb Ruby
require 'json'
pretty = JSON.pretty_generate(JSON.parse(text)) php PHP
O PHP indenta com quatro espaços e escapa barras e Unicode a menos que você passe essas flags.
$pretty = json_encode(
json_decode($text),
JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE
); Perguntas frequentes
- Existe algum limite de tamanho?
- Esta página não impõe nenhum. O teto real é o seu navegador: um motor JavaScript limita uma única string a cerca de 512 MB, então nada maior consegue nem ser mantido em memória. Formatar um documento de 10 MB custa aqui cerca de 780 milissegundos de trabalho, executados em um worker em segundo plano para que a página continue responsiva.
- Formatar altera os meus dados?
- Não. Espaço em branco fora das strings não tem significado em JSON, e este formatador reemite cada valor exatamente como você escreveu, em vez de fazer o parsing e reserializar. Ligar a ordenação de chaves altera sim o documento, e é por isso que ela vem desligada.
- Por que o meu arquivo formatado ficou diferente do que o meu editor produz?
- Provavelmente é a quebra de linha final ou o estilo dos arrays de objetos. Alguns formatadores deixam arrays curtos em uma única linha; este é consistente, o que gera mais linhas mas diffs muito mais legíveis.