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


87

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
}

20
"Pourquoi prendre la peine de le faire correctement?" C'est le genre de pensée paresseuse qui mène à des sites Web chargés avec un balisage invalide. À l'épreuve votre code au cas où certains navigateur ne nécessite des guillemets doubles.
meagar

21
"Pourquoi prendre la peine de le faire correctement?" - Pourquoi se donner la peine de suivre une convention que personne d'autre ne fait, s'il n'y a pas de réel avantage? Peut-être confondez-vous la pensée paresseuse avec le pragmatisme.
Mark Rogers

15
@Mark - "que personne d'autre ne fait" ... d'où avez-vous eu cette idée? le sérialiseur JSON intégré à chaque plate-forme principale effectue des citations appropriées.
Nick Craver

7
La fonction json_encode de @Mark Rogers PHP produit un JSON valide, avec des chaînes entre guillemets, par exemple. Peut-être pensez-vous à des objets littéraux en JavaScript? Il est vrai que ceux-ci fonctionnent sans citer les clés, mais ce n'est pas JSON.
JAL

9
Pour mémoire, il y a des années, lorsque j'ai publié ceci, j'étais confus au sujet de la différence entre JSON et la notation littérale d'objet comme @JAL le suggérait. Les deux ont une syntaxe très similaire, ce qui a finalement conduit à une certaine confusion dans la description du problème.
Mark Rogers

Réponses:


155

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é )


1
@Mark, de rien. Gardez à l'esprit que JSON est simplement un format d'échange de données indépendant du langage , même si sa syntaxe a été inspirée par la syntaxe Javascript Object Literal, il existe des différences entre eux (bien plus que les clés entre guillemets).
Christian C. Salvadó

2
@CMS, alors pourquoi ne doit-il être que des guillemets doubles? Pourquoi les guillemets simples ne sont-ils pas valides dans JSON?
Pacerier

1
Les guillemets simples ne sont pas autorisés pour que la norme JSON reste aussi simple que possible. JSON ne doit être qu'un sous-ensemble de Javascript, il n'a pas besoin d'implémenter autant de Javascript que possible.
thomasrutter

La spécification de sur-ensemble JSON5 adhère à la syntaxe ES5 et prend donc en charge, entre autres, les clés sans guillemets. La bibliothèque est compatible parseet stringifyméthodes.
Inigo

Dans ce lien de table de compatibilité (au bas de la réponse), l' entrée Mots réservés se trouve sous la section Extensions littérales d'objet / tableau . Et TL; DR, tous les navigateurs répertoriés (tout ce dont vous avez entendu parler et environ 20 autres) disent tous "Oui".
i336_ le

16

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 .


Oui, j'avais de vieilles applications ajax générant schonky json côté serveur, qui ont échoué lors de la mise à niveau vers jquery 1.4 en raison du manque de guillemets doubles autour des noms de clés.
JAL

Vous voudrez peut-être ajouter que tous les principaux navigateurs le JSON.parserejetteront également correctement.
Matthew Flaschen

Je suis curieux, dans quel cas exactement JQuery 1.4 échouera-t-il silencieusement avec ce type de json invalide?
Mark Rogers

1
@Mark - Dans tous les cas, il n'est pas correctement cité ou contient des caractères invalides ... en gros, il échouera avec tout JSON invalide.
Nick Craver

C'est intéressant, cela n'a pas été mon expérience avec JQuery 1.4. De plus, je ne pense pas que jquery soit responsable de la création d'objets json, n'est-ce pas ce que fait l'interpréteur javascript du navigateur? Faites-vous référence à la désérialisation de Jquery json?
Mark Rogers

-3

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


10
YAML n'est pas un sur-ensemble de JSON.
John Gibb

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.