Ferramentas para desenvolvedores · Formatador e validador JSON
Chaves duplicadas em JSON: o que RFC 8259 permite e o que os analisadores fazem
· Fundo
JSON padrões validação
A gramática de JSON permite a mesma chave duas vezes, a especificação apenas diz que os nomes 'deveriam' ser únicos e os analisadores discordam sobre qual valor vence. Esta postagem explica por que isso é importante para correção e segurança.
Qual 'função' o servidor leu?
Considere `{"role":"viewer","role":"editor"}`. Ambos os membros estão gramaticalmente completos, portanto ToolAcre reporta JSON válido. Quando o texto atinge `JSON.parse`, o objeto resultante possui uma propriedade `role` cujo valor é `"editor"`. O membro anterior não é retido como histórico oculto. Uma verificação de sintaxe bem-sucedida, portanto, não responde nada sobre se os nomes dos objetos apareceram mais de uma vez.
A formatação torna a perda visível somente depois de ter acontecido: a saída contém `{"role":"editor"}` no layout escolhido. Ele não pode reproduzir o membro `viewer` descartado porque a serialização recebe o objeto analisado, não a sequência de membros original. Se nomes repetidos forem importantes para uma revisão, preserve e inspecione o texto fonte antes de pressionar Formatar, em vez de confiar no resultado normalizado.
A gramática permite, as especificações desencorajam
RFC 8259 diz que os nomes dentro de um objeto devem ser exclusivos. Esse “deveria” promove resultados interoperáveis sem tornar a exclusividade parte da gramática básica do objeto. Um nome repetido ainda consiste em uma string válida, dois pontos e um valor na posição correta separada por vírgula. Consequentemente, um validador gramatical pode aceitar o documento enquanto uma política de aplicação o rejeita.
Essa distinção é fácil de ignorar porque muitos erros são falhas de sintaxe obrigatórias: dois pontos ausentes ou vírgula final não podem formar um objeto JSON. As duplicatas são diferentes. Eles criam uma questão de interoperabilidade depois que o analisador reconhece cada token. ToolAcre para intencionalmente na sintaxe e não adiciona uma regra de nome duplicado, portanto, seu resultado válido não deve ser lido como uma garantia de exclusividade.
O que JSON.parse e ToolAcre fazem
`JSON.parse` usa a ocorrência posterior quando os nomes dos objetos se repetem. ToolAcre herda esse comportamento porque analisa antes da formatação. Para `{"limit":10,"limit":25,"unit":"items"}`, a validação foi bem-sucedida, o limite analisado é 25 e a saída formatada contém um `limit`. A classificação opcional de chaves pode reposicionar a propriedade sobrevivente, mas não pode expor a ocorrência substituída.
Não generalize esse resultado para todos os analisadores ou configurações. Alguns sistemas podem rejeitar duplicatas e outras pilhas de processamento podem aplicar uma política diferente ou inspecionar tokens antes de construir um objeto. A declaração segura entre sistemas é restrita: nomes repetidos não são interoperáveis de forma confiável. Verifique os modos reais do analisador usados em cada limite quando a distinção for importante, em vez de confiar em uma declaração que abrange toda a linguagem.
Quando a discordância do analisador se torna um risco
As duplicatas tornam-se uma preocupação de segurança apenas em um caminho concreto de vários estágios, onde os componentes interpretam o mesmo texto de maneira diferente. Por exemplo, um filtro de solicitação pode inspecionar uma ocorrência enquanto o aplicativo consome outra. Se isso pode acontecer depende dos analisadores exatos, das opções, do comportamento de encaminhamento e do uso do campo. A sintaxe duplicada por si só não prova ser um desvio explorável.
O controle defensável é estabelecer uma política no limite de confiança e testar a pilha real. Rejeite nomes duplicados antes da construção de objetos com perdas quando a ambiguidade for inaceitável ou garanta que cada componente receba a mesma representação já analisada. ToolAcre pode demonstrar seu próprio comportamento de formatação de última vitória, mas não pode auditar gateways, estruturas ou serviços que não fazem parte da ferramenta do navegador.
Exemplo resolvido: um documento com chave repetida
Cole `{"theme":"light","prefs":{"density":"roomy","density":"compact"},"theme":"dark"}`. ToolAcre aceita o texto porque cada membro é sintaticamente válido. A análise deixa o tema raiz como `dark` e a densidade aninhada como `compact`. A formatação emite uma cópia de cada nome, de modo que ambos os valores anteriores desaparecem do documento exibido.
Esse exemplo também mostra por que a pesquisa do resultado formatado é tarde demais. A detecção duplicada deve observar os nomes dos membros durante a leitura do fluxo de token original, em cada profundidade do objeto. Arrays não precisam de regra de nome duplicado, embora regras de aplicação separadas possam se preocupar com valores de elementos repetidos. Mantenha a fonte inalterada, execute um analisador ou linter com reconhecimento de duplicatas e decida se a política é de aviso ou rejeição.
Detectando duplicatas propositalmente
Use ferramentas que prometem explicitamente a detecção de nomes duplicados na fonte JSON. As abordagens adequadas incluem um modo de analisador que falha nas repetições, um manipulador de token de streaming que rastreia nomes para cada objeto aberto ou um linter com uma regra de chave duplicada documentada. Verifique objetos aninhados e nomes com escape: `"name"` e `"name"` decodificam para o mesmo nome de membro, mesmo que suas grafias de origem sejam diferentes.
JSON O esquema não é um substituto, uma vez que a análise comum descarta ocorrências anteriores. Um validador de esquema geralmente recebe o valor construído e vê uma propriedade, não o histórico de token duplicado. Execute a verificação de exclusividade antes ou durante a análise e, em seguida, aplique verificações de esquema ao valor inequívoco. ToolAcre não executa detecção de duplicatas nem validação de esquema, portanto, ambos exigem uma etapa separada e específica.
O que isso não cobre
Nomes de objetos repetidos não são iguais a valores repetidos entre registros. `[ {"id":7}, {"id":7} ]` contém dois objetos separados, cada um com um `id`; detectando um identificador duplicado, existe uma regra de conjunto de dados. Da mesma forma, dois elementos de array com a mesma string permanecem em duas posições intencionais, a menos que um contrato de aplicação diga que o array representa um conjunto.
Este artigo não reivindica uma política universal de quem ganha, quem ganha ou rejeita, para amplos ecossistemas linguísticos. Ele registra o comportamento observável de ToolAcre `JSON.parse` e explica por que outro componente deve ser verificado diretamente. Também não determina a explorabilidade apenas de uma duplicata. O impacto na segurança exige provas de que diferentes interpretações ultrapassam limites relevantes de autorização, encaminhamento ou validação.
Conclusão: JSON válido nem sempre é inequívoco JSON
Um resultado ToolAcre válido significa que a sequência de token é estrita JSON; isso não significa que cada nome de objeto seja único. `JSON.parse` mantém o último valor para um nome repetido e a formatação serializa apenas esse sobrevivente. Como a ocorrência anterior é apagada, a saída formatada é uma evidência inadequada para decidir se a fonte original continha duplicatas.
Quando a exclusividade é importante, inspecione o texto original com ferramentas com reconhecimento de duplicatas antes da análise ou formatação comum. Aplique a validação de esquema e domínio posteriormente ao valor inequívoco resultante. Para análise de segurança, rastreie o caminho real da solicitação e as configurações do analisador em vez de presumir discordância. A regra prática é simples: a aceitação da sintaxe, a política de nomes duplicados e o significado posterior são verificações separadas com evidências separadas.