Les commentaires peuvent-ils être utilisés dans JSON?

No , les commentaires du formulaire //… 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/json pour la Notation D'objet JavaScript (JSON)
• RFC 7159 the JavaScript Object Notation (JSON) Data Interchange Format - Obsolètes: 4627, 7158

incluez les commentaires si vous le désirez; retirez-les avec un minificateur avant de les analyser ou de les transmettre.

je viens de sortir JSON.minify () qui supprime les 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));

quand je l'ai publié, j'ai eu une énorme réaction de gens en désaccord avec même le idée de lui, donc j'ai décidé que j'écrirais un billet de blog complet sur pourquoi commentaires ont un sens dans JSON . Il inclut ce commentaire remarquable 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. Ensuite, passez-le par jsmin avant de le remettre à votre analyseur JSON. - Douglas Crockford, 2012

J'espère que c'est utile pour ceux qui ne sont pas d'accord avec pourquoi JSON.minifier() pourrait être utile.

les commentaires ont été supprimés de JSON par conception.

j'ai retiré les commentaires de JSON parce que j'ai vu des gens les utiliser pour tenir des directives d'analyse, 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 passez-le par jsmin avant de le remettre à votre analyseur JSON.

Source: déclaration publique de Douglas Crockford sur G+

CLAUSE DE NON-RESPONSABILITÉ: VOTRE GARANTIE EST ANNULÉE

comme cela a été souligné, ce piratage profite de la mise en œuvre de la spécification. Tous les analyseurs JSON ne comprendront pas ce genre de JSON. Les parsers en Streaming en particulier vont s'étouffer.

c'est une curiosité intéressante, mais vous ne devrait vraiment pas l'utiliser pour quoi que ce soit . Ci-dessous est la réponse originale à cette question.

j'ai trouvé un petit hack qui vous permet de placer des commentaires dans un fichier JSON qui n'affectera pas l'analyse, ou modifier les données représentées en aucune façon.

il apparaît que lorsque vous déclarez un objet littéral, vous pouvez spécifier deux valeurs avec la même clé, et la dernière a priorité. Croyez le ou non, il s'avère que JSON analyseurs de la même façon. Nous pouvons donc utiliser ceci pour créer des commentaires dans le JSON source qui ne seront pas présents dans une représentation d'objet parsé.

({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 valid JSON . Si vous l'analysez, vous obtiendrez un objet comme ceci:

{
    "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 ils n'auront pas d'effets secondaires bizarres.

Happy hacking!

JSON ne supporte pas les commentaires. Il n'a pas non plus été conçu pour être utilisé pour les fichiers de configuration où des commentaires seraient nécessaires.

Hjson est un format de fichier de configuration pour humains. Syntaxe détendue, moins d'erreurs, plus de commentaires.

voir hjson.org pour les bibliothèques JavaScript, Java, Python, PHP, Rust, Go, Ruby et C#.

vous ne pouvez pas. Du moins, c'est mon expérience d'un coup d'oeil rapide à json.org .

JSON a sa syntaxe visualisée sur cette page. Il n'y a aucune note sur les commentaires.

envisagez D'utiliser YAML. C'est presque un super-ensemble de JSON (pratiquement tout JSON valide est YAML valide) et il permet des commentaires.

vous devriez écrire un schéma JSON à la place. Le schéma JSON est actuellement une ébauche de spécification proposée sur Internet. En plus de 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 votre analyseur JSON, alors voici comment vous l'activez pour permettre des commentaires:

ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);   

alors vous pouvez avoir des commentaires comme ceci:

{
  key: "value" // comment
}

et vous pouvez aussi avoir des commentaires à partir de # en paramétrant:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);    

mais en général (comme répondu avant) le spec ne permet pas de commentaires.

les Commentaires ne sont pas une norme officielle. Bien que certains parsers soutiennent les commentaires de style C. Un que j'utilise est 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 valide pas cela. Les commentaires sont donc une extension spécifique de l'analyseur et non une norme.

un autre parser est JSON5 .

une alternative à JSON TOML .

voici ce que j'ai trouvé dans le Google documentation Firebase qui vous permet de mettre des commentaires dans 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"
}

Désolé, nous ne pouvons pas utiliser de commentaires dans JSON... Voir le diagramme de syntaxe pour JSON sur JSON.org .

Douglas Crockford dit" pourquoi il a supprimé les commentaires dans JSON et fournir une autre façon de faire que ":

j'ai retiré les commentaires de JSON parce que j'ai vu des gens les utilisaient pour tenir des directives d'analyse, une pratique qui aurait détruit interopérabilité. Je sais que le manque des commentaires de certaines personnes triste, mais ça 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. Ensuite, passez-le par jsmin avant de le remettre à votre analyseur JSON.

si votre fichier texte, qui est une chaîne JSON, doit être lu par un programme, à quel point serait-il difficile de supprimer les commentaires de style C ou C++ avant de l'utiliser?

Réponse: Ce serait un liner. Si vous faites cela, les fichiers JSON pourraient être utilisés comme Fichiers de configuration.

si vous utilisez Newtonsoft.Bibliothèque Json avec ASP.NET pour lire/déserialiser vous pouvez utiliser des commentaires dans le contenu JSON:

//"nom": "string"

/ / "id": int

ou

/ * Ceci est un

exemple de commentaire */

PS: pris en charge avec 6+ versions de Newtonsoft Json.

note supplémentaire pour les personnes qui ne peuvent pas penser hors de la boîte: j'utilise le format JSON pour les paramètres de base dans un ASP.NET application web j'ai fait. J'ai lu le fichier, je l'ai converti en objet settings avec la bibliothèque Newtonsoft et je l'ai utilisé si nécessaire.

je préfère écrire des commentaires sur chaque paramètre individuel dans le fichier JSON lui-même, et je ne me soucie vraiment pas de la intégrité du format JSON aussi longtemps que la bibliothèque que j'utilise est OK avec elle.

je pense que c'est une façon 'plus facile à utiliser/comprendre' que de créer des paramètres séparés.README' fichier et en expliquant les paramètres qu'il contient.

Si vous avez un problème avec ce genre d'utilisation; désolé, le génie est sorti de la lampe. Les gens trouveraient d'autres usages pour le format JSON, et il n'y a rien que vous puissiez y faire.

L'idée derrière JSON est de fournir un simple échange de données entre les applications. Ils sont typiquement basés sur le web et le langage est JavaScript.

il ne permet pas vraiment pour les commentaires en tant que tels, cependant, passer un commentaire comme l'un des noms/valeur paires dans les données fonctionnerait certainement, bien que ces données devraient évidemment être ignorées ou traitées spécifiquement par le code de parsing.

tout cela dit, ce n'est pas l'intention que le JSON le dossier doit contenir des commentaires au sens traditionnel du terme. Ça devrait être les données.

regardez le JSON website pour plus de détails.

je viens de rencontrer ceci pour les fichiers de configuration. Je ne veux pas utiliser le format XML (verbeux, graphiquement, laid, difficile à lire), ou" ini " (pas de hiérarchie, pas de véritable standard, etc.) ou Java "Propriétés" format (comme .ini).

JSON peut faire tout ce qu'ils peuvent faire, mais c'est beaucoup moins verbeux et plus lisible par les humains - et les analyseurs sont faciles et omniprésents dans de nombreuses langues. C'est juste un arbre de données. Mais les commentaires hors-bande sont souvent nécessaires pour document "par défaut" des configurations et la comme. Les Configurations ne doivent jamais être des "documents complets", mais des arbres de données sauvegardées qui peuvent être lisibles par l'utilisateur lorsque cela est nécessaire.

je suppose qu'on pourrait utiliser "#": "comment" , pour" valide " JSON.

JSON ne supporte pas les commentaires nativement, mais vous pouvez faire votre propre décodeur ou au moins préprocesseur pour supprimer les commentaires, c'est parfaitement bien (tant que vous ignorez les commentaires et ne les utilisez pas pour guider la façon dont votre application devrait traiter les données JSON).

JSON n'a pas de commentaires. Un encodeur JSON ne doit pas émettre 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 valable. C'est à quoi sert JSON?

Cf: de Douglas Crockford, auteur de la spécification JSON .

ça dépend de votre bibliothèque JSON. Json.NET supporte les commentaires de style JavaScript, /* commment */ .

Voir un autre Débordement de Pile question .

JSON fait beaucoup de sens pour les fichiers de configuration et d'autres utilisations locales parce que c'est omniprésent et parce que c'est beaucoup plus simple que XML.

si les gens ont de bonnes raisons de ne pas avoir de commentaires dans JSON lors de la communication des données (qu'elles soient valides ou non), alors peut-être JSON pourrait être divisé en deux:

• JSON-COM: JSON sur le fil, ou les règles qui s'appliquent lors de la communication des données JSON.
• JSON-DOC: document JSON, ou JSON dans les fichiers ou localement. Règles qui définissent un document JSON valide.

JSON-DOC permettra des commentaires, et d'autres différences mineures pourraient exister, comme la gestion des espaces blancs. Parsers peut facilement passer d'une spécification à l'autre.

en ce qui concerne la remarque faite par Douglas Crockford sur ces questions (référencée par @Artur Czajka)

supposez que vous utilisez JSON pour garder les fichiers de configuration que vous souhaitez annoter. Allez-y et insérez tous les commentaires que vous aimez. Ensuite, passez-le par jsmin avant de le remettre à votre analyseur JSON.

il s'agit d'un problème de fichier de configuration générique (cross language/plate-forme), et il répond avec un utilitaire spécifique à JS!

sûr qu'un minify spécifique à JSON peut être implémenté dans n'importe quelle langue, mais standardiser cela de sorte qu'il devient omniprésent à travers parsers dans tous les langues et les plates-formes donc les gens cessent de perdre leur temps sans la fonctionnalité parce qu'ils ont de bons cas d'utilisation pour elle, regarder la question dans les forums en ligne, et amener les gens leur dire que c'est une mauvaise idée ou suggérant qu'il est facile d'implémenter des commentaires de suppression des fichiers texte.

l'autre enjeu est l'interopérabilité. Supposons que vous ayez une bibliothèque ou une API ou tout autre type de sous-système qui a des fichiers de config ou de données qui lui sont associés. Et ce sous-système est pour être accessible à partir de différentes langues. Alors allez-vous dire aux gens: par la voie n'oubliez pas de supprimer les commentaires des fichiers JSON avant de les transmettre à l'analyseur!

la boîte à outils JavaScript Toolkit de Dojo (au moins à partir de la version 1.4), vous permet d'inclure des commentaires dans votre JSON. Les commentaires peuvent être DE format /* */ . Dojo Toolkit consomme le JSON via l'appel dojo.xhrGet() .

D'autres boîtes à outils JavaScript peuvent fonctionner de la même manière.

cela peut être utile lors de l'expérimentation de structures de données alternatives (ou même de 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 de JSON qui vise à rendre plus facile pour les humains d'écrire et de maintenir à la main. Il le fait en ajoutant quelques traits de syntaxe minimale directement à partir D'ECMAScript 5.

Vous peut avoir des commentaires en JSONP , mais pas dans la pure JSON. Je viens de passer une heure à essayer de faire fonctionner mon programme avec cet exemple 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, il n'y avait aucun problème avec le Politique de même origine , donc j'ai décidé d'utiliser JSON pur... et, bien sûr, $.getJSON a échoué silencieusement à cause des commentaires.

finalement j'ai envoyé une requête HTTP manuelle à l'adresse ci-dessus et j'ai réalisé que le type de contenu était text/javascript puisque, bien, JSONP renvoie du JavaScript pur. Dans ce cas, les commentaires sont autorisés . Mais mon application a retourné le type de contenu application/json , donc j'ai dû supprimer le commentaire.

JSON n'est pas encadré protocole . C'est un format libre de langue . Le format d'un commentaire n'est donc pas défini pour JSON.

comme beaucoup de gens l'ont suggéré, il y a quelques Trucs, Par exemple, des clés dupliquées ou une clé spécifique _comment que vous pouvez utiliser. C'est à vous.

c'est une question "can you" . Et voici une réponse " Oui " .

Non, vous ne devriez pas utiliser les membres d'objet dupliqués pour empiler les données des canaux latéraux dans un encodage JSON. (Voir "Les noms à l'intérieur d'un objet DOIT être unique" dans la RFC ).

Et oui, vous pouvez insérer des commentaires autour de JSON , qui vous pu analyser hors.

mais si vous voulez un moyen d'insérer et d'extraire des données de canal latéral arbitraire à un JSON valide, voici une réponse. Nous profitons de la représentation non unique des données dans un encodage JSON. Ceci est autorisé ^* dans la section 2 de la RFC sous"les espaces sont autorisés avant ou après l'un des six caractères structuraux".

^* la RFC ne dit que " les espaces blancs sont autorisés avant ou après l'un des six caractères structuraux", sans mentionner explicitement les chaînes, les nombres, "false", "true", Et "null". Cette omission est ignorée dans toutes les implémentations.

D'abord, canonisez votre JSON en le minifiant:

$jsonMin = json_encode(json_decode($json));

alors 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"
}

Simplement npm install --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 article de JSON en parties, j'ajoute "commentaire fictif" lignes:

{

"#############################" : "Part1",

"data1"             : "value1",
"data2"             : "value2",

"#############################" : "Part2",

"data4"             : "value3",
"data3"             : "value4"

}

il y a une bonne solution (hack), qui est valide JSON. 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 comme:

{
  "param" : "This is value place",
}

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 juste que vos noms" notex " n'entrent pas en conflit avec de vrais champs.

l'auteur de JSON veut que nous incluions des commentaires dans le JSON, mais que nous les enlevions avant de les analyser (voir link fourni par Michael Burr.) Si JSON devait 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 la solution YAML comme suggéré par d'autres est bon, mais nécessite une dépendance de bibliothèque.

si vous voulez supprimer les commentaires, mais ne le faites pas pour avoir une dépendance de bibliothèque, voici une solution en 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 d'obtenir JSON parsing, suppression des commentaires, et pas de bibliothèque supplémentaire, est d'évaluer le JSON dans un interpréteur JS. La mise en garde avec ça l'approche, bien sûr, est que vous voudriez seulement évaluer des données non vérifiées (aucune entrée utilisateur non fiable.) Voici un exemple de cette approche dans le nœud.js -- une autre mise en garde, l'exemple suivant Ne Lira les données qu'une seule fois, puis elles seront mises en cache:

data = require(fs.realpathSync(doctree_fp));