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.function
Ok 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é )