Existe algum motivo prático para usar strings entre aspas para chaves JSON?

87

De acordo com o json.org de Crockford , um objeto JSON é composto de membros , que são compostos de pares .

Cada par é feito de uma string e um valor , com uma string sendo definida como:

Uma string é uma sequência de zero ou mais caracteres Unicode, colocados entre aspas duplas, usando escapes de barra invertida. Um caractere é representado como uma única string de caracteres. Uma string é muito parecida com uma string C ou Java.

Mas, na prática, a maioria dos programadores nem sabe que uma chave JSON deve estar entre aspas duplas, porque a maioria dos navegadores não exige o uso de aspas duplas.

Faz algum sentido se preocupar em colocar o JSON entre aspas duplas?

Exemplo válido:

{
  "keyName" : 34
}

Ao contrário do inválido:

{
   keyName : 34
}
Mark Rogers
fonte
20
"Por que se preocupar em fazer isso direito?" Esse é o tipo de pensamento preguiçoso que leva a sites carregados de marcação inválida. À prova de futuro o seu código no caso de algum navegador não requerem aspas duplas.
meagar
21
"Por que se preocupar em fazer isso direito?" - Por que se preocupar em seguir uma convenção que ninguém mais faz, se não há benefício real? Talvez você confunda pensamento preguiçoso com pragmatismo.
Mark Rogers
15
@Mark - "que ninguém mais faz" ... de onde você tirou essa ideia? o serializador JSON embutido em cada plataforma principal faz as cotações adequadas.
Nick Craver
7
A função json_encode do PHP @Mark Rogers produz um JSON válido, com strings entre aspas duplas, por exemplo. Talvez você esteja pensando em literais de objeto em JavaScript? É verdade que esses funcionam sem citar as chaves, mas isso não é JSON.
JAL
9
Só para constar, anos atrás, quando postei isso, fiquei confuso sobre a diferença entre JSON e a notação literal de objeto como @JAL sugeriu. Os dois têm uma sintaxe muito semelhante, o que acabou gerando alguma confusão na descrição do problema.
Mark Rogers,

Respostas:

155

O verdadeiro motivo pelo qual as chaves JSON devem estar entre aspas é a semântica dos Identificadores do ECMAScript 3.

Palavras reservadas não podem ser usadas como nomes de propriedade em literais de objeto sem aspas, por exemplo:

({function: 0}) // SyntaxError
({if: 0}) // SyntaxError
({true: 0}) // SyntaxError
// etc...

Se você usar aspas, os nomes das propriedades serão válidos:

({"function": 0}) // Ok
({"if": 0}) // Ok
({"true": 0}) // Ok

O próprio Crockford explica isso nesta palestra , eles queriam manter o padrão JSON simples e não gostariam de ter todas essas restrições semânticas nele:

....

Foi quando descobrimos o problema do nome não citado. Acontece que o ECMA Script 3 tem uma política de palavras reservadas do tipo whack. As palavras reservadas devem ser citadas na posição chave, o que é realmente um incômodo. Quando comecei a formular isso em um padrão, não queria ter que colocar todas as palavras reservadas no padrão, porque pareceria muito estúpido.

Na época, eu estava tentando convencer as pessoas: sim, você pode escrever aplicativos em JavaScript, na verdade vai funcionar e é uma boa linguagem. Eu não quis dizer, então, ao mesmo tempo: e olhe só que bobagem eles fizeram! Então decidi, em vez disso, vamos apenas citar as chaves.
Dessa forma, não precisamos contar a ninguém sobre o quão maluco é.

É por isso que, até hoje, as chaves são citadas em JSON.

...

O ECMAScript 5th Edition Standard corrige isso, agora em uma implementação ES5, mesmo palavras reservadas podem ser usadas sem aspas, em ambos, literais de objeto e acesso de membro ( obj.functionOk em ES5).

Apenas para registro, este padrão está sendo implementado atualmente por fornecedores de software. Você pode ver quais navegadores incluem esse recurso nesta tabela de compatibilidade (consulte Palavras reservadas como nomes de propriedade )

Christian C. Salvadó
fonte
1
@Mark, de nada. Lembre-se de que JSON é simplesmente um formato de intercâmbio de dados independente de linguagem , mesmo que sua sintaxe tenha sido inspirada na sintaxe do Literal do objeto Javascript, há diferenças entre eles (muito mais do que apenas as chaves citadas).
Christian C. Salvadó
2
@CMS, então por que deve ser apenas aspas duplas? Por que as aspas simples são inválidas em JSON?
Pacerier
1
As aspas simples não são permitidas para manter o padrão JSON o mais simples possível. JSON só precisa ser um subconjunto de Javascript, não precisa implementar o máximo possível de Javascript.
thomasrutter
A especificação do superconjunto JSON5 adere à sintaxe ES5 e, portanto, oferece suporte a chaves não citadas, entre outras coisas. A biblioteca possui métodos parsee compatíveis stringify.
Inigo
Nesse link de tabela de compatibilidade (na parte inferior da resposta), a entrada Palavras reservadas está na seção Extensões literais de objeto / matriz . E TL; DR, todos os navegadores listados (todos que você já ouviu falar e cerca de 20 mais) dizem "Sim".
i336_
16

Sim, é JSON inválido e será rejeitado em muitos casos, por exemplo, jQuery 1.4+ tem uma verificação que faz com que o JSON não citado falhe silenciosamente. Porque não ser compatível?

Vamos dar outro exemplo:

{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }

... tudo isso valeria com aspas, por que não ser consistente e utilizá-las em todos os casos, eliminando a possibilidade de um problema?

Mais um exemplo comum no mundo do desenvolvedor da web: Existem milhares de exemplos de HTML inválido que são renderizados na maioria dos navegadores ... isso torna menos doloroso depurar ou manter? De forma alguma, muito pelo contrário.

Além disso, @Matthew faz o melhor ponto de todos nos comentários abaixo, isso falha, as chaves não citadas irão lançar um erro de sintaxe com JSON.parse()em todos os principais navegadores (e quaisquer outros que as implementem corretamente), você pode testá-lo aqui .

Nick Craver
fonte
Sim, eu tinha alguns aplicativos ajax antigos gerando o lado do servidor schonky json, que falhou ao atualizar para o jquery 1.4 devido à falta de aspas duplas em torno dos nomes das chaves.
JAL
Você pode querer acrescentar que todos os principais navegadores JSON.parsetambém o rejeitarão corretamente.
Matthew Flaschen
Estou curioso, em que caso exatamente o JQuery 1.4 falhará silenciosamente com este tipo de json inválido?
Mark Rogers de
1
@Mark - Em qualquer caso, não está devidamente citado ou possui caracteres inválidos ... basicamente irá falhar com qualquer JSON inválido.
Nick Craver
É interessante, não tem sido minha experiência com JQuery 1.4. Além disso, não acho que jquery seja responsável por criar objetos json, não é isso que o interpretador de javascript do navegador faz? Você está se referindo à desserialização Jquery json?
Mark Rogers
-3

YAML, que na verdade é um superconjunto de JSON, oferece suporte ao que você deseja fazer. Embora seja um superconjunto, permite mantê-lo tão simples quanto você deseja.

YAML é uma lufada de ar fresco e pode valer a pena dar uma olhada nele. O melhor lugar para começar é aqui: http://en.wikipedia.org/wiki/YAML

Existem libs para todos os idiomas existentes, incluindo JS, por exemplo, https://github.com/nodeca/js-yaml

user1649339
fonte
10
YAML não é um superconjunto de JSON.
John Gibb,
para obter informações sobre o motivo: stackoverflow.com/questions/25974485/…
Ben Página