Ferramentas para desenvolvedores · Formatador e validador JSON
Histórico de padrões de JSON: RFC 4627 a RFC 8259 e ECMA-404
· Fundo
JSON padrões validação
JSON foi especificado pelo menos quatro vezes por dois organismos de padronização. Esta postagem traça o caminho de json.org de Douglas Crockford para RFC 8259 e ECMA-404 e explica o que realmente mudou para os desenvolvedores ao longo do caminho.
Qual especificação meu analisador está seguindo?
Qual especificação um analisador segue? A resposta geralmente é visível nas bordas, e não em objetos e matrizes comuns. Teste uma sequência de nível superior, como `"ready"`, uma marca inicial de ordem de bytes, nomes de membros duplicados e números excepcionalmente grandes. Diferentes documentos discutem sintaxe e interoperabilidade em diferentes níveis, enquanto as implementações adicionam seus próprios tipos de dados e comportamento de erro. Nomear um padrão é útil apenas quando o contrato do analisador observado é mantido separado das suposições sobre cada implementação de JSON.
A evidência do repositório para ToolAcre é concreta e mais restrita do que um histórico geral de padrões. O formatador usa `JSON.parse` para produzir valores e `JSON.stringify` para emiti-los; após uma falha de análise, um scanner local fornece uma posição de diagnóstico estável e o motivo.
json.org e a descrição inicial de JSON
json.org apresentou JSON como uma notação compacta derivada da sintaxe literal de objeto de JavaScript e documentou suas estruturas centrais com uma pequena gramática. Essa descrição inicial ajudou a dar aos desenvolvedores um nome compartilhado e uma referência para objetos, arrays, strings, números, booleanos e nulos. É mais seguro descrever a página como uma explicação pública inicial do que afirmar, sem aqui citar provas históricas, que uma página ou pessoa descobriu sozinha um formato ou estabeleceu a sua adopção.
As fontes atuais do repositório não incluem um histórico de arquivo de json.org, uso do navegador ou discussões do comitê. Eles mostram como esse aplicativo analisa e diagnostica JSON hoje. Conseqüentemente, as declarações históricas neste artigo permanecem próximas de documentos padronizados datados e evitam atribuir motivos ou efeitos de mercado que esses arquivos locais não possam provar.
RFC 4627 em 2006 — a primeira descrição de IETF, o tipo de mídia application/json e a regra de que um texto deve ser um objeto ou array
RFC 4627, publicado em 2006, descreveu JSON para intercâmbio na Internet e registrou o tipo de mídia `application/json`. Sua definição de texto JSON exigia um objeto ou array de nível superior, mesmo que strings, números e literais existissem como valores dentro desses contêineres. Essa restrição é uma diferença histórica útil porque um documento contendo apenas `"ready"` poderia ser um valor válido em uma formulação posterior, embora estivesse fora da definição de texto JSON de RFC 4627.
O documento também discutiu questões de codificação e segurança no contexto das implementações disponíveis na época. Não deve ser lido como um changelog para este repositório: ToolAcre não contém um modo de compatibilidade RFC 4627 e seu caminho do analisador delega a construção de valor ao mecanismo host JavaScript.
ECMA-404 em 2013 — O padrão mínimo de sintaxe da Ecma e por que duas organizações acabaram descrevendo um formato
ECMA-404, publicado pela primeira vez em 2013, especifica a sintaxe JSON em um formato deliberadamente compacto. Seu foco é a gramática do texto JSON válido, em vez de um perfil de intercâmbio completo para cada uso em rede. Esse escopo ajuda a explicar por que os documentos ECMA-404 e IETF podem descrever a mesma notação básica, embora diferindo nas orientações de interoperabilidade que enfatizam. A existência de dois organismos de normalização não implica dois formatos incompatíveis no uso normal.
As alegações sobre o motivo pelo qual as organizações escolheram determinados caminhos de publicação exigem fontes documentais além desta base de código, portanto, este artigo não infere os motivos do comitê a partir das datas dos padrões. O ponto prático relevante é que RFC 8259 e ECMA-404 se destinam a se alinhar na sintaxe, enquanto RFC 8259 fornece recomendações que são importantes para a troca interoperável.
RFC 7159 e RFC 8259
RFC 7159 substituiu RFC 4627 em 2014 e ampliou a definição de um texto JSON para qualquer valor serializado, removendo a regra de nível superior somente objeto ou array. RFC 8259 substituiu RFC 7159 em 2017 e permanece a referência IETF normalmente citada para JSON. Requer UTF-8 para JSON trocado entre sistemas fora de um ecossistema fechado e registra cuidados de interoperabilidade em torno de números, nomes duplicados, Unicode e marcas de ordem de bytes, em vez de fingir que apenas a gramática garante resultados idênticos em todos os lugares.
Um `true` de nível superior é uma maneira compacta de observar a regra moderna de valor raiz em ToolAcre porque `JSON.parse` a aceita. Esse resultado demonstra o comportamento desta implementação; ele não reconstrói quando cada navegador, servidor ou API adotou a definição mais ampla.
O que mudou para os desenvolvedores que trabalham
Para desenvolvedores ativos, as mudanças de especificação mais claras são a aceitação moderna de qualquer valor JSON na raiz e uma orientação mais forte para codificação interoperável. A lição menos visível é que a sintaxe válida ainda deixa opções de implementação. Nomes de objetos duplicados podem ser recolhidos, a ordenação de membros não é um contrato semântico, números muito grandes podem perder precisão e sequências Unicode incomuns podem viajar de maneira diferente pelas bibliotecas. Um documento compatível com os padrões pode, portanto, merecer restrições adicionais de um esquema de aplicação.
Neste formatador, nomes duplicados e tokens numéricos passam primeiro por `JSON.parse`, portanto, a formatação posterior reflete o valor JavaScript resultante em vez do documento léxico original. O scanner contribui com diagnósticos após falha; não preserva membros duplicados ou números de precisão arbitrária. Essas são observações apoiadas por repositórios.
O que isso não cobre
O que isso não cobre são as especificações colocadas sobre JSON. JSON O esquema descreve restrições na forma e nos valores do documento; JSON O ponteiro aborda locais em um documento; JSON Patch representa alterações. Eles resolvem problemas diferentes da gramática base e não devem ser tratados como versões posteriores do próprio JSON. JSONC, JSON5 e formatos de autoria semelhantes também estendem ou alteram a sintaxe aceita e exigem seus próprios analisadores, em vez de serem dobrados silenciosamente em uma validação estrita.
Este artigo também evita um histórico social abrangente de adoção de JSON, suporte de navegador ou competição com XML porque as fontes de repositório listadas não podem fundamentar essa narrativa. Nenhuma citação externa foi inventada para preencher a lacuna.
Conclusão: RFC 8259 é a referência a ser citada
RFC 8259 é a referência prática IETF a ser citada para orientação atual de sintaxe e interoperabilidade JSON, com ECMA-404 fornecendo o padrão de sintaxe Ecma alinhado. RFC 4627 e RFC 7159 permanecem úteis para compreender como a definição publicada mudou, especialmente no nível superior. Cite o documento que apóia a afirmação exata em vez de usar “a especificação JSON” como um apelo vago à autoridade e distinga as regras normativas do comportamento de implementação observado em um analisador específico.
Para ToolAcre, a afirmação defensável é que o repositório usa o analisador e serializador JSON de JavaScript e adiciona um scanner local estrito para diagnóstico após falhas. Testes de valores de nível superior, pontuação malformada e manipulação de números descrevem esse caminho; eles não são fontes históricas.