Existe-t-il une raison pratique d'utiliser des chaînes entre guillemets pour les clés JSON?

Selon json.org de Crockford , un objet JSON est composé de membres , qui sont constitués de paires .

Chaque paire est composée d'une chaîne et d'une valeur , une chaîne étant définie comme:

Une chaîne est une séquence de zéro ou plusieurs caractères Unicode, entourés de guillemets doubles, utilisant des échappements de barre oblique inverse. Un caractère est représenté sous la forme d'une chaîne de caractères unique. Une chaîne ressemble beaucoup à une chaîne C ou Java.

Mais en pratique, la plupart des programmeurs ne savent même pas qu'une clé JSON doit être entourée de guillemets doubles, car la plupart des navigateurs ne nécessitent pas l'utilisation de guillemets doubles.

Est-il judicieux de se soucier d'entourer votre JSON entre guillemets?

Exemple valide:

{
  "keyName" : 34
}

Contrairement aux invalides:

{
   keyName : 34
}

La vraie raison pour laquelle les clés JSON doivent être entre guillemets, repose sur la sémantique des identificateurs d'ECMAScript 3.

Les mots réservés ne peuvent pas être utilisés comme noms de propriété dans Object Literals sans guillemets, par exemple:

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

Alors que si vous utilisez des guillemets, les noms de propriété sont valides:

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

Le propre Crockford l'explique dans cette conférence , ils voulaient garder le standard JSON simple, et ils n'aimeraient pas avoir toutes ces restrictions sémantiques dessus:

....

C'est à ce moment-là que nous avons découvert le problème des noms sans guillemets. Il s'avère que ECMA Script 3 a une politique de mots réservés whack. Les mots réservés doivent être cités dans la position clé, ce qui est vraiment une nuisance. Quand j'ai commencé à formuler cela dans une norme, je ne voulais pas avoir à mettre tous les mots réservés dans la norme, car cela aurait l'air vraiment stupide.

À l'époque, j'essayais de convaincre les gens: oui, vous pouvez écrire des applications en JavaScript, ça va marcher et c'est un bon langage. Je ne voulais pas dire, alors, en même temps: et regardez cette chose vraiment stupide qu'ils ont faite! J'ai donc décidé, à la place, de citer simplement les clés.
De cette façon, nous n'avons pas besoin de dire à qui que ce soit à quel point c'est mauvais.

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

...

Le standard ECMAScript 5th Edition corrige ce problème, maintenant dans une implémentation ES5, même les mots réservés peuvent être utilisés sans guillemets, à la fois dans les littéraux d'objet et dans l'accès aux membres ( obj.functionOk dans ES5).

Pour mémoire, cette norme est mise en œuvre ces jours-ci par les éditeurs de logiciels, vous pouvez voir quels navigateurs incluent cette fonctionnalité dans ce tableau de compatibilité (voir Mots réservés comme noms de propriété )

Oui, c'est un JSON invalide et sera rejeté dans de nombreux cas, par exemple, jQuery 1.4+ a une vérification qui fait échouer silencieusement le JSON sans guillemets. Pourquoi ne pas être conforme?

Prenons un autre exemple:

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

... tous ces éléments seraient valables avec des guillemets, pourquoi ne pas être cohérents et les utiliser dans tous les cas, éliminant ainsi la possibilité d'un problème?

Un exemple plus courant dans le monde des développeurs Web: il existe des milliers d'exemples de code HTML invalide qui s'affiche dans la plupart des navigateurs ... est-ce que cela rend le débogage ou la maintenance moins pénible? Pas du tout, bien au contraire.

De plus, @ Matthew fait le meilleur point de tous dans les commentaires ci-dessous, cela échoue déjà , les clés sans guillemets généreront une erreur de syntaxe JSON.parse()dans tous les principaux navigateurs (et tous les autres qui l'implémentent correctement), vous pouvez le tester ici .

YAML, qui est en fait un sur-ensemble de JSON, prend en charge ce que vous voulez faire. Bien que ce soit un sur-ensemble, il vous permet de le garder aussi simple que vous le souhaitez.

YAML est une bouffée d'air frais et cela vaut peut-être la peine de l'examiner. Le meilleur endroit pour commencer est ici: http://en.wikipedia.org/wiki/YAML

Il existe des bibliothèques pour chaque langue sous le soleil, y compris JS, par exemple https://github.com/nodeca/js-yaml