en JSON, pourquoi chaque nom est-il cité?

Question

La spécification JSON dit que JSON est un objet ou un tableau. Dans le cas d'un objet,

Une structure de l'objet est représenté par une paire d'accolades entourant zéro, une ou plusieurs paires nom/valeur (ou les membres). Un nom est une chaîne de caractères. ...

Et plus tard, la spec dit qu'une chaîne de caractères entourée par des guillemets.

Pourquoi?

Ainsi,

{"Property1":"Value1","Property2":18}

et pas

{Property1:"Value1",Property2:18}

Question 1: pourquoi ne pas autoriser le nom dans les paires nom/valeur à identificateurs non cotées?

---

Question 2: Est-il une différence sémantique entre les deux représentations ci-dessus, lors de l'évaluation en Javascript?

Answer 1

Je laisse un devis à partir d'une présentation que Douglas Crockford (le créateur du JSON standard) a donné à Yahoo.

Il raconte comment il a découvert JSON, et, entre autres, pourquoi il a décidé d'utiliser cité clés:

.... C'était quand nous avons découvert l' non cotées nom de problème. Il s'avère ECMA Script 3 a une claque réservés mot de la politique. Les mots réservés doivent être cité dans la position de la touche, qui est vraiment une nuisance. Quand je suis autour de pour formulizing ce dans un standard, je n'avais pas envie de mettre toutes les les mots réservés dans la norme, car il serait vraiment stupide.

À l'époque, j'essayais de convaincre les gens: oui, vous pouvez écrire les applications en JavaScript, il est réellement aller travailler et c'est une bonne de langue. Je n'ai pas envie de dire, alors, dans le même temps, et de regarder ce vraiment stupide chose qu'ils ont fait! J'Ai Donc a décidé, au lieu de cela, nous allons simplement de citer le les touches.
De cette façon, nous n'avons pas à dire quelqu'un à propos de la façon dont whack il est.

C'est pourquoi, à ce jour, les clés sont indiqués en JSON.

Vous pouvez trouver la vidéo complète et la transcription ici.

Answer 2

Question 1: pourquoi ne pas autoriser le nom dans les paires nom/valeur à identificateurs non cotées?

La philosophie de conception de JSON est "Keep it simple"

"Citation de noms avec des "" est beaucoup plus simple que "Vous pouvez citer des noms avec " ou ' mais vous n'avez pas à, à moins qu'ils contiennent certains caractères (ou des combinaisons de caractères qui en font un mot clé) et d' ' ou " peut-être besoin d'être cité en fonction de ce délimiteur vous avez sélectionné".

Question 2: il y a une différence sémantique entre les deux représentations ci-dessus, lors de l'évaluation en Javascript?

Pas de. En JavaScript, ils sont identiques.

Answer 3

En javascript, les objets peuvent être utilisés comme un hash / hashtable avec des paires de clés.

Cependant, si votre clé contient des caractères que javascript ne peut pas identifier sous forme de nom, cela échouera si vous essayez de le faire, accédez comme une propriété sur un objet plutôt qu'une clé.

 var test  = {};
test["key"] = 1;
test["#my-div"] = "<div> stuff </div>";

// test = { "key": 1, "#my-div": "<div> stuff </div>" };

console.log(test.key);           // should be 1
console.log(test["key"]);        // should be 1
console.log(test["#my-div"]);    // should be "<div> stuff </div>";
console.log(test.#my-div);       // would not work.
 

les identifiants peuvent parfois avoir des caractères qui ne peuvent pas être évalués en tant que jeton / identifiant en javascript, il est donc préférable de mettre tous les identifiants dans des chaînes pour des raisons de cohérence.

Answer 4

Les espaces : et les espaces sont autorisés dans les identificateurs. Sans les guillemets, cela créerait une ambiguïté lorsque vous tenteriez de déterminer ce qui constitue exactement l'identificateur.

Answer 5

Je pense que la bonne réponse à Cheeso de la question est que la mise en œuvre a dépassé la documentation. Il ne nécessite plus une chaîne de caractères comme la clé, mais plutôt quelque chose d'autre, qui peut être soit une chaîne de caractères (c'est à dire cité) ou (probablement) rien de ce qui peut être utilisé comme un nom de variable, qui je suppose signifie commencer par une lettre, _, ou $, et ne comprennent que des lettres, des chiffres, et le $ et _.

J'ai voulu simplifier le reste pour la prochaine personne qui visite cette question avec la même idée que j'ai fait. Voici la viande:

Les noms de variables ne sont pas interpolés en JSON lorsqu'il est utilisé comme un objet clé (Merci Friedo!)

Breton, à l'aide de "identificateur" au lieu de "la clé", a écrit que "si un identifiant est un mot réservé, il est interprété comme le mot plutôt que comme un identifiant." Cela peut être vrai, mais je l'ai essayé, sans aucun problème:

var a = {do:1,long:2,super:3,abstract:4,var:5,break:6,boolean:7};
a.break

=> 6

À propos de l'utilisation des citations, Quentin a écrit: "...mais vous n'avez pas à, à moins que [le] contient certains caractères (ou des combinaisons de caractères qui en font un mot-clé)"

J'ai trouvé l'ancienne partie (certains caractères) est vrai, en utilisant le signe @ (en fait, je pense que $ " et " _ " sont les seuls caractères qui ne sont pas la cause de l'erreur):

var a = {a@b:1};

=> Erreur de syntaxe

var a = {"a@b":1};
a['a@b']

=> 1

mais la parenthèse sur les mots clés, comme je l'ai montré ci-dessus, n'est pas vrai.

Ce que je voulais fonctionne parce que le texte entre l'ouverture { et le côlon, ou entre la virgule et les deux points pour les propriétés suivantes est utilisée comme non cotées chaîne pour en faire un objet clé, ou, comme Friedo, un nom de variable, il n'a pas obtenir de l'interpolation:

var uid = getUID();
var token = getToken();            // Returns ABC123
var data = {uid:uid,token:token};
data.token

=> ABC123