Les commentaires peuvent-ils être utilisés dans JSON?
https://stackoverflow.com/questions/244777
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Puis-je utiliser des commentaires dans un fichier JSON? Si oui, comment?
La solution
Non.
Les fichiers JSON doivent tous être des données, et si vous incluez un commentaire, il s'agira également de données.
Vous pourriez avoir un élément de données désigné appelé " _comment & <; code> (ou quelque chose) qui serait ignoré par les applications qui utilisent les données JSON.
Il serait probablement préférable d’avoir le commentaire dans les processus qui génèrent / reçoivent le JSON, car ils sont supposés savoir ce que les données JSON seront à l’avance, ou du moins leur structure.
Mais si vous avez décidé de:
{
"_comment": "comment text goes here...",
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
Autres conseils
Non , les commentaires de la forme //… ou / *… * / ne sont pas autorisés dans JSON. Cette réponse est basée sur:
- http://www.json.org
- RFC 4627 :
Le type de média
application / jsonpour la notation d'objet JavaScript (JSON) - RFC 7159 Formatage d'échange de données JSON (JavaScript Object Notation) - Format d'échange de données - Obsolet: 4627 , 7158
Inclure les commentaires si vous le souhaitez. éliminez-les avec un minifier avant de les analyser ou de les transmettre.
Je viens de publier JSON.minify () , qui se désactive commentaires et les espaces d'un bloc de JSON et le rend valide JSON qui peut être analysé. Donc, vous pourriez l’utiliser comme:
JSON.parse(JSON.minify(my_str));
Lorsque je l'ai publié, j'ai reçu une énorme réaction de gens qui n'étaient pas d'accord avec l'idée, alors j'ai décidé d'écrire un article de blog complet expliquant pourquoi Les commentaires ont un sens dans JSON . Il inclut ce commentaire notable du créateur de JSON:
Supposons que vous utilisez JSON pour conserver les fichiers de configuration que vous souhaitez annoter. Allez-y et insérez tous les commentaires que vous aimez. Puis transmettez-le à JSMin avant de le remettre à votre analyseur JSON. - Douglas Crockford, 2012
J'espère que cela sera utile à ceux qui ne sont pas d'accord avec la raison pour laquelle JSON.minify () pourrait être utile.
Les commentaires ont été supprimés de JSON par conception.
J'ai supprimé les commentaires de JSON car je voyais que des personnes les utilisaient pour conserver des directives d'analyse syntaxique, une pratique qui aurait détruit l'interopérabilité. Je sais que le manque de commentaires rend certaines personnes tristes, mais cela ne devrait pas.
Supposons que vous utilisez JSON pour conserver les fichiers de configuration que vous souhaitez annoter. Allez-y et insérez tous les commentaires que vous aimez. Puis transmettez-le à JSMin avant de le remettre à votre analyseur JSON.
Source: Déclaration publique de Douglas Crockford sur le groupe G +
CLAUSE DE NON-RESPONSABILITÉ: VOTRE GARANTIE EST ANNULÉE
Comme cela a été souligné, ce hack tire parti de la mise en œuvre de la spécification. Tous les analyseurs JSON ne comprendront pas ce type de JSON. La lecture en continu des parseurs va s’étouffer.
C’est une curiosité intéressante, mais vous ne devriez vraiment pas l’utiliser pour quoi que ce soit . Vous trouverez ci-dessous la réponse initiale.
J'ai trouvé un petit hack qui vous permet de placer des commentaires dans un fichier JSON sans affecter l'analyse ni de modifier les données représentées de quelque manière que ce soit.
Il semble que lors de la déclaration d'un littéral d'objet, vous pouvez spécifier deux valeurs avec la même clé et la dernière est prioritaire. Croyez-le ou non, il s'avère que les analyseurs syntaxiques JSON fonctionnent de la même manière. Nous pouvons donc l'utiliser pour créer des commentaires dans le JSON source qui ne seront pas présents dans une représentation d'objet analysé.
({a: 1, a: 2});
// => Object {a: 2}
Object.keys(JSON.parse('{"a": 1, "a": 2}')).length;
// => 1
Si nous appliquons cette technique, votre fichier JSON commenté pourrait ressembler à ceci:
{
"api_host" : "The hostname of your API server. You may also specify the port.",
"api_host" : "hodorhodor.com",
"retry_interval" : "The interval in seconds between retrying failed API calls",
"retry_interval" : 10,
"auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
"auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "An array containing my all-time favorite numbers",
"favorite_numbers": [19, 13, 53]
}
Le code ci-dessus est JSON valide . Si vous l'analysez, vous obtiendrez un objet comme celui-ci:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": [19,13,53]
}
Ce qui signifie qu'il n'y a aucune trace des commentaires et qu'ils n'auront pas d'effets secondaires étranges.
Joyeux piratage!
JSON ne prend pas en charge les commentaires. En outre, il n’a jamais été prévu d’utiliser les fichiers de configuration pour lesquels des commentaires seraient nécessaires.
Hjson est un format de fichier de configuration pour les humains. Syntaxe détendue, moins d'erreurs, plus de commentaires.
Voir les hjson.org pour les bibliothèques JavaScript, Java, Python, PHP, Rust, Go, Ruby et C #.
Pensez à utiliser YAML. C'est presque un sur-ensemble de JSON (pratiquement tout le JSON valide est valide au format YAML) et autorise les commentaires.
Vous ne pouvez pas. Du moins, c’est ce que j’ai pu voir en un coup d’œil rapide sur json.org .
La syntaxe de JSON est visualisée sur cette page. Il n'y a pas de note à propos des commentaires.
Vous devriez plutôt écrire un schéma JSON . Le schéma JSON est actuellement un projet de spécification Internet. Outre la documentation, le schéma peut également être utilisé pour valider vos données JSON.
Exemple:
{
"description":"A person",
"type":"object",
"properties":
{
"name":
{
"type":"string"
},
"age":
{
"type":"integer",
"maximum":125
}
}
}
Vous pouvez fournir de la documentation en utilisant l'attribut de schéma description .
Si vous utilisez Jackson comme analyseur JSON, procédez comme suit pour l'activer afin d'autoriser les commentaires:
ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);
Ensuite, vous pouvez avoir des commentaires comme celui-ci:
{
key: "value" // Comment
}
Et vous pouvez également avoir des commentaires commençant par # en définissant:
mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);
Mais en général (comme indiqué précédemment), la spécification ne permet pas de commentaires.
Les commentaires ne sont pas une norme officielle. Bien que certains analyseurs prennent en charge les commentaires de style C. J'utilise JsonCpp . Dans les exemples, il y a celui-ci:
// Configuration options
{
// Default encoding for text
"encoding" : "UTF-8",
// Plug-ins loaded at start-up
"plug-ins" : [
"python",
"c++",
"ruby"
],
// Tab indent size
"indent" : { "length" : 3, "use_space": true }
}
jsonlint ne le valide pas. Les commentaires sont donc une extension spécifique à l’analyseur et non standard.
Un autre analyseur est JSON5 .
Alternative à JSON TOML .
Une autre alternative est jsonc .
Voici ce que j'ai trouvé dans la documentation sur Google Firebase . cela vous permet de mettre des commentaires en JSON:
{
"//": "Some browsers will use this to enable push notifications.",
"//": "It is the same for all projects, this is not your project's sender ID",
"gcm_sender_id": "1234567890"
}
Si votre fichier texte, qui est une chaîne JSON, va être lu par certains programmes, serait-il difficile de supprimer les commentaires de style C ou C ++ avant de les utiliser?
Réponse: Il s'agirait d'un one-liner. Si vous faites cela, les fichiers JSON pourraient être utilisés comme fichiers de configuration.
Si vous utilisez la bibliothèque Newtonsoft.Json avec ASP.NET pour lire / désérialiser, vous pouvez utiliser des commentaires dans le contenu JSON:
// "nom": "chaîne"
// "id": int
ou
/ * Ceci est un
exemple de commentaire * /
PS: les commentaires sur une ligne ne sont pris en charge que par 6 versions ou plus de Newtonsoft Json.
Remarque supplémentaire pour les personnes qui ne peuvent pas penser à tout ce qui se passe au dehors: j'utilise le format JSON pour les paramètres de base d'une application Web ASP.NET que j'ai créée. Je lis le fichier, le convertis en objet de configuration avec la bibliothèque Newtonsoft et l’utilise si nécessaire.
Je préfère écrire des commentaires sur chaque paramètre individuel dans le fichier JSON lui-même. L'intégrité du format JSON ne m'intéresse pas vraiment tant que la bibliothèque que j'utilise est acceptable.
Je pense que ceci est un moyen "plus facile à utiliser / à comprendre" que de créer un fichier séparé "settings.README" et d'expliquer les paramètres qu'il contient.
Si vous rencontrez un problème avec ce type d'utilisation; désolé, le génie est sorti de la lampe. Les gens trouveraient d’autres utilisations du format JSON et vous ne pouvez rien y faire.
L’idée de JSON est de fournir un échange de données simple entre les applications. Celles-ci sont généralement basées sur le Web et le langage est JavaScript.
Cela n'autorise pas vraiment les commentaires en tant que tels, cependant, le fait de passer un commentaire comme l'une des paires nom / valeur dans les données fonctionnerait certainement, bien que ces données devraient évidemment être ignorées ou traitées spécifiquement par le code d'analyse .
Cela étant dit, le fichier JSON ne doit pas contenir de commentaires au sens traditionnel du terme. Ce ne devrait être que les données.
Consultez le site Web JSON pour plus de détails.
Je viens juste de le rencontrer pour les fichiers de configuration. Je ne souhaite pas utiliser XML (verbeux, graphique, laid, difficile à lire) ou "ini". format (pas de hiérarchie, pas de standard réel, etc.) ou Java "Propriétés". format (comme .ini).
JSON peut faire tout ce qu'il peut, mais il est beaucoup moins verbeux et plus lisible par l'homme - et les analyseurs syntaxiques sont faciles et omniprésents dans de nombreuses langues. C'est juste un arbre de données. Cependant, les commentaires hors bande sont souvent nécessaires pour documenter "défaut". configurations et similaires. Les configurations ne doivent jamais être des "documents complets", mais des arbres de données sauvegardées pouvant être lisibles par l'homme en cas de besoin.
Je suppose que l'on pourrait utiliser "#": "commentaire" , pour "valide". JSON.
JSON ne prend pas en charge les commentaires de manière native, mais vous pouvez créer votre propre décodeur ou au moins un préprocesseur pour effacer les commentaires, c'est très bien (tant que vous ignorez simplement les commentaires et ne les utilisez pas pour orienter le traitement de votre application). les données JSON).
JSON n'a pas de commentaire. Un encodeur JSON NE DOIT PAS produire de commentaires. Un décodeur JSON PEUT accepter et ignorer les commentaires.
Les commentaires ne doivent jamais être utilisés pour transmettre quelque chose de significatif. C'est à quoi sert JSON.
Cela dépend de votre bibliothèque JSON. Json.NET prend en charge les commentaires de style JavaScript, / * commment * / . .
Voir la question relative au dépassement de capacité de la pile .
JSON est très utile pour les fichiers de configuration et autres utilisations locales car il est omniprésent et beaucoup plus simple que XML.
Si les utilisateurs ont des raisons sérieuses de ne pas avoir de commentaires dans JSON lors de la communication de données (valides ou non), alors JSON peut éventuellement être scindé en deux:
- JSON-COM: JSON sur le réseau ou règles applicables à la communication de données JSON.
- JSON-DOC: document JSON ou JSON dans des fichiers ou localement. Règles définissant un document JSON valide.
JSON-DOC autorisera les commentaires. D'autres différences mineures peuvent exister, telles que la gestion des espaces. Les analyseurs peuvent facilement convertir une spécification à l’autre.
En ce qui concerne la remarque de Douglas Crockford sur ce sujet (référencé par @Artur Czajka)
Supposons que vous utilisez JSON pour conserver les fichiers de configuration que vous souhaitez annoter. Allez-y et insérez tous les commentaires que vous aimez. Puis transmettez-le à JSMin avant de le remettre à votre analyseur JSON.
Nous parlons d'un problème de fichier de configuration générique (cross language / platform), et il répond avec un utilitaire spécifique à JS!
Bien sûr, une minify spécifique à JSON peut être implémentée dans n’importe quel langage, mais standardisez-le pour qu'il devienne omniprésent dans les analyseurs dans toutes les langues et sur toutes les plates-formes, afin que les utilisateurs cessent de perdre du temps, car ils ont de bons cas d'utilisation, recherchent la question sur des forums en ligne et incitent les gens à leur dire que c'est une mauvaise idée. ou suggérant qu'il est facile d'implémenter des commentaires de strip-tease sur des fichiers texte.
L'autre problème est l'interopérabilité. Supposons que vous ayez une bibliothèque, une API ou tout type de sous-système associé à des fichiers de configuration ou de données. Et ce sous-système est être accessible à partir de différentes langues. Alors allez-vous dire aux gens: à propos n'oubliez pas de supprimer les commentaires des fichiers JSON avant de les transmettre à l'analyseur!
Le toolkit JavaScript de Dojo Toolkit (au moins à partir de la version 1.4) vous permet d'inclure des commentaires dans votre JSON. Les commentaires peuvent être au format / * * / . Dojo Toolkit utilise le code JSON via l'appel dojo.xhrGet () .
D'autres kits d'outil JavaScript peuvent fonctionner de la même manière.
Cela peut être utile lorsque vous expérimentez d'autres structures de données (ou même des listes de données) avant de choisir une option finale.
Si vous utilisez JSON5 , vous pouvez inclure des commentaires.
JSON5 est une extension proposée à JSON qui vise à faciliter la rédaction et la maintenance manuelles à la main. Pour ce faire, il ajoute certaines fonctionnalités de syntaxe minimale directement à partir de ECMAScript & 5.
JSON n'est pas un protocole encadré . C'est un format libre de langue . Le format d'un commentaire n'est donc pas défini pour JSON.
Comme beaucoup de personnes l'ont suggéré, il existe des astuces, telles que des clés en double ou une clé spécifique _comment que vous pouvez utiliser. C'est à vous.
Vous pouvez avoir des commentaires dans JSONP , mais pas en mode pur JSON. Je viens de passer une heure à essayer de faire fonctionner mon programme avec cet exemple tiré de Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Si vous suivez le lien, vous verrez
?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Comme j'avais un fichier similaire dans mon dossier local, le origine identique n'a posé aucun problème. politique , j’ai donc décidé d’utiliser du JSON pur ... et, bien sûr, $. getJSON échouait en silence à cause des commentaires.
Finalement, je viens d'envoyer une requête HTTP manuelle à l'adresse ci-dessus et me suis rendu compte que le type de contenu était text / javascript puisque, bien, JSONP renvoie du code JavaScript pur. Dans ce cas, les commentaires sont autorisés . Mais mon application a renvoyé le type de contenu application / json et j'ai donc dû supprimer les commentaires.
JSON supportait les commentaires, mais ceux-ci ont été mal utilisés et supprimés de la norme.
Du créateur de JSON:
J'ai supprimé les commentaires de JSON car je voyais que des personnes les utilisaient pour conserver des directives d'analyse syntaxique, une pratique qui aurait détruit l'interopérabilité. Je sais que le manque de commentaires rend certaines personnes tristes, mais cela ne devrait pas. - Douglas Crockford, 2012
Le site JSON officiel se trouve à l'adresse JSON.org . JSON est défini comme un standard par ECMA International. Il existe toujours un processus de pétition pour faire réviser les normes. Il est peu probable que des annotations soient ajoutées à la norme JSON pour plusieurs raisons.
JSON, de par sa conception, constitue une alternative au XML simple à l’analyse inverse. C'est simplifié au point que les annotations sont inutiles. Ce n'est même pas un langage de balisage. L’objectif est la stabilité et l’interopérabilité.
Toute personne qui comprend le " has-a " relation d'orientation d'objet peut comprendre n'importe quelle structure JSON - c'est le point entier. Il s’agit simplement d’un graphe acyclique dirigé (DAG) avec des étiquettes de nœud (paires clé / valeur), qui est une structure de données quasi universelle.
Cette seule annotation requise peut être "// Ce sont des balises DAG". Les noms de clé peuvent être aussi informatifs que nécessaire, permettant une arité sémantique arbitraire.
Toute plate-forme peut analyser JSON avec seulement quelques lignes de code. XML nécessite des bibliothèques OO complexes qui ne sont pas viables sur de nombreuses plates-formes.
Les annotations ne feraient que rendre JSON moins interopérable. Il n'y a tout simplement rien d'autre à ajouter, à moins que vous n'ayez vraiment besoin d'un langage de balisage (XML) et ne vous inquiétez pas si vos données persistantes sont facilement analysées.
Il s'agit d'une question "Pouvez-vous" ? Et voici une "oui" réponse.
Non, vous ne devez pas utiliser de membres d'objet duplicatif pour insérer des données de canal latéral dans un codage JSON. (Voir " Les noms contenus dans un objet DEVRAIENT être uniques " dans le RFC .)
Et oui, vous pouvez insérer des commentaires autour de le code JSON , que pourrait analyser.
Mais si vous voulez un moyen d'insérer et d'extraire des données de canal latéral arbitraires dans un JSON valide, voici une réponse. Nous tirons parti de la représentation non unique des données dans un codage JSON. Ceci est autorisé * dans la section deux de la RFC sous "Les espaces sont autorisés avant ou après l'un des six caractères structurels".
* La RFC n'indique que "les espaces sont autorisés avant ou après l'un des six caractères structurels", sans mentionner explicitement les chaînes, les nombres, "faux", "vrai". et "null". Cette omission est ignorée dans TOUTES les implémentations.
Tout d'abord, canonisez votre JSON en le réduisant:
$jsonMin = json_encode(json_decode($json));
Ensuite, encodez votre commentaire en binaire:
$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);
Puis steg votre binaire:
$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);
Voici votre sortie:
$jsonWithComment = $steg . $jsonMin;
Nous utilisons strip-json-comments pour notre projet. Il supporte quelque chose comme:
/*
* Description
*/
{
// rainbows
"unicorn": /* ❤ */ "cake"
}
Il suffit de installer npm --save strip-json-comments pour l'installer et l'utiliser comme:
var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}
Pour couper un élément JSON en plusieurs parties, j'ajoute "commentaire fictif". lignes:
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
Il existe une bonne solution (hack), qui est un code JSON valide. Il suffit de faire la même clé deux fois (ou plus). Par exemple:
{
"param" : "This is the comment place",
"param" : "This is value place",
}
Donc, JSON comprendra ceci:
{
"param" : "This is value place",
}
L'auteur de JSON souhaite que nous incluions des commentaires dans le JSON, mais supprimez-les avant de les analyser (voir lien fourni par Michael Burr). Si JSON doit avoir des commentaires, pourquoi ne pas les normaliser et laisser l’analyseur JSON faire le travail? Je ne suis pas d'accord avec la logique, mais, hélas, c'est la norme. Utiliser une solution YAML, comme suggéré par d’autres, est une bonne chose, mais cela nécessite une dépendance de la bibliothèque.
Si vous souhaitez supprimer les commentaires, mais ne pas avoir de dépendance de bibliothèque, voici une solution à deux lignes, qui fonctionne pour les commentaires de style C ++, mais peut être adaptée à d’autres:
var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));
Notez que cette solution ne peut être utilisée que dans les cas où vous pouvez être sûr que les données JSON ne contiennent pas l'initiateur de commentaire, par exemple. ('//').
Une autre façon de réaliser l'analyse JSON, la suppression de commentaires et l'absence de bibliothèque supplémentaire, consiste à évaluer le JSON dans un interpréteur JavaScript. La mise en garde avec cette approche, bien sûr, est que vous voudriez uniquement évaluer des données non corrompues (aucune entrée utilisateur non fiable). Voici un exemple de cette approche dans Node.js - autre mise en garde: l'exemple suivant ne lira les données qu'une fois, puis sera mis en cache:
data = require(fs.realpathSync(doctree_fp));
Soupir. Pourquoi ne pas simplement ajouter des champs, par exemple.
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
Assurez-vous simplement que votre " notex " les noms ne sont en conflit avec aucun champ réel.
