Les commentaires peuvent-ils être utilisés dans JSON?
Puis-je utiliser des commentaires dans un fichier JSON? Si c'est le cas, comment?
Non.
Le JSON doit 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" (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"
}
}
}
}
}
Non, les commentaires de la forme //… ou /*…*/ ne sont pas autorisés en 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 Format d'échange de données JSON (JavaScript Object Notation) - Obsolètes: 4627, 7158
Inclure les commentaires si vous choisissez; éliminez-les avec un minifier avant de les analyser ou de les transmettre.
Je viens de publier 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));
Lorsque je l'ai publié, j'ai eu 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 comprend ce commentaire notable du créateur de JSON:
Supposons que vous utilisiez 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 parce que je voyais des personnes les utiliser 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 utilisiez 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.
LIMITATION DE RESPONSABILITÉ: VOTRE GARANTIE IS NUL
Comme il 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. Les parseurs en streaming vont s’étouffer.
C’est une curiosité intéressante, mais vous ne devriez vraiment pas l’utiliser pour rien du tout. Voici la réponse originale.
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.
Il semble que lorsque vous déclarez un littéral d'objet, vous pouvez spécifier deux valeurs avec la même clé, la dernière étant 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 valide JSON . 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.
Bonne 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 hjson.org pour les bibliothèques JavaScript, Java, Python, PHP, Rust, Go, Ruby et C #.
Tu ne peux pas. Du moins, c’est mon expérience d’un coup d’œil rapide à json.org .
JSON a sa syntaxe visualisée sur cette page. Il n'y a pas de note sur les commentaires.
Pensez à utiliser YAML. C'est presque un sur-ensemble de JSON (pratiquement tout le JSON valide est valide au format YAML) et permet les commentaires.
Vous devriez écrire un schéma JSON à la place. 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 en tant que votre analyseur JSON, voici comment vous l'activez pour 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 n’autorise pas les commentaires.
Les commentaires ne sont pas une norme officielle. Bien que certains analyseurs prennent en charge les commentaires de style C. Celui que j'utilise est JsonCpp . Dans les exemples, il y en a un:
// 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 à l’analyseur et non standard.
Un autre analyseur est JSON5 .
Une alternative à JSON TOML .
Voici ce que j'ai trouvé dans la documentation Google Firebase qui 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"
}
Désolé, nous ne pouvons pas utiliser de commentaires dans JSON ... Voir le diagramme de syntaxe pour JSON dans JSON.org .
Douglas Crockford explique " pourquoi il a supprimé les commentaires dans JSON et fourni un autre moyen de le faire ":
J'ai supprimé les commentaires de JSON car j'ai vu des gens les utiliser pour tenir des directives d'analyse, une pratique qui aurait détruit interopérabilité. Je sais que le manque de commentaires rend certaines personnes triste, mais ça ne devrait pas.
Supposons que vous utilisiez JSON pour conserver les fichiers de configuration que vous avez aimerait annoter. Allez-y et insérez tous les commentaires que vous aimez . Puis transmettez-le à JSMin avant de le remettre à votre analyseur JSON.
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 l'utiliser?
Réponse: Ce serait un one-liner. Si vous le faites, les fichiers JSON peuvent ê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
/* C'est un
exemple de commentaire * /
PS: Les commentaires sur une seule 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 sortir des sentiers battus: J'utilise le format JSON pour les paramètres de base dans 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 et je me fiche de l'intégrité du format JSON tant que la bibliothèque que j'utilise est en bon état.
Je pense que c'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 avez un problème avec ce type d’utilisation; désolé, le génie est sorti de la lampe. Les gens trouveraient d’autres utilisations pour le format JSON, et vous ne pouvez rien y faire.
L'idée derrière JSON est de fournir un échange de données simple entre les applications. Ce sont généralement basés sur le Web et la langue est JavaScript.
Cela n'autorise pas vraiment les commentaires en tant que tels, cependant, le fait de passer un commentaire comme 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 dit, le fichier JSON ne doit pas contenir de commentaires au sens traditionnel. Ce ne devrait être que les données.
Consultez le site Web JSON pour plus de détails.
Je viens de rencontrer cela pour les fichiers de configuration. Je ne veux pas utiliser le formatXML(verbeux, graphique, laid, difficile à lire), ni le format "ini" (pas de hiérarchie, pas de standard réel, etc.) ni le format Java "Propriétés" .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. Mais les commentaires hors bande sont souvent nécessaires pour documenter les configurations "par défaut", etc. 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 "#": "comment", pour JSON "valide".
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 indiquer comment votre application doit 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 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 */.
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 lors de la communication de données JSON.
- JSON-DOC: document JSON ou JSON dans des fichiers ou localement. Règles qui définissent 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 faite par Douglas Crockford sur cette question (référencé par @Artur Czajka)
Supposons que vous utilisiez 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 quelle langue, Mais elle est standardisée de sorte qu’elle devient omniprésente dans les analyseurs syntaxiques de toutes les langues et de toutes les dans les forums en ligne, et incitez les gens à leur dire que c'est une mauvaise idée ou à suggérer qu'il est facile d'implémenter des commentaires de suppression des fichiers texte.
L'autre problème est l'interopérabilité. Supposons que vous ayez une bibliothèque ou une API ou tout type de sous-système associé à des fichiers de configuration ou de données. Et ce sous-système est accessible depuis différentes langues. Ensuite, allez-vous dire aux gens: à propos N'oubliez pas de supprimer les commentaires des fichiers JSON avant de les transmettre à l'analyseur!
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 par les utilisateurs. Pour ce faire, il ajoute des fonctionnalités de syntaxe minimale directement à partir de ECMAScript 5.
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 JSON via l'appel dojo.xhrGet().
D'autres toolkits 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.
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 certaines astuces, telles que des clés dupliquées ou une clé spécifique _comment que vous pouvez utiliser. C'est à vous.
Vous pouvez avoir des commentaires dans JSONP , mais pas dans du JSON pur. 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 pas de problème avec la politique de même origine , alors j'ai décidé d'utiliser du JSON pur ... et, bien sûr, $.getJSON échouait en silence à cause du 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, eh 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.
Ceci est une question "pouvez-vous". Et voici une réponse "oui".
Non, vous ne devez pas utiliser de membre d'objet duplicatif pour insérer des données de canal latéral dans un codage JSON. (Voir "Les noms dans un objet DEVRAIENT être uniques" dans le RFC ).
Et oui, vous pourriez insérer des commentaires environ le JSON , que vous pourriez analyser.
Mais si vous souhaitez insérer et extraire des données de canaux secondaires arbitraires dans un JSON valide, voici la réponse. Nous tirons parti de la représentation non unique des données dans un codage JSON. C'est permis* 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 indique uniquement "les espaces sont autorisés avant ou après l'un des six caractères structurels", sans mentionner explicitement les chaînes, les nombres, "false", "true" 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));
Puis 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;
AVERTISSEMENT: CECI IS SILLY
Il existe en fait un moyen d’ajouter des commentaires et de rester dans les spécifications (aucun analyseur supplémentaire n’est nécessaire). Cela n'aboutira pas à des commentaires lisibles par l'homme sans analyse préalable.
Vous pouvez abuser des éléments suivants:
Les espaces insignifiants sont autorisés avant ou après tout jeton. Un espace est une séquence de l'un ou de plusieurs des points de code suivants: tabulation de caractères (U + 0009), saut de ligne (U + 000A), retour chariot (U + 000D) et espace (U + 0020).
De manière hacky, vous pouvez en abuser pour ajouter un commentaire. Par exemple: commencez et terminez votre commentaire avec un onglet. Encodez le commentaire en base3 et utilisez les autres caractères d'espacement pour les représenter. Par exemple.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hello base three en ASCII) Mais au lieu de 0, utilisez espace, pour 1 utilisation saut de ligne et pour 2 utilisation retour chariot.
Cela vous laissera simplement beaucoup d'espaces illisibles (à moins que vous ne créiez un plugin IDE pour l'encoder/le décoder à la volée).
Je n'ai même jamais essayé cela, pour des raisons évidentes et vous ne devriez pas non plus.
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'}
Il existe une bonne solution (hack), qui est un 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 comme:
{
"param" : "This is value place",
}
Pour couper un élément JSON en plusieurs parties, j'ajoute les lignes "commentaire factice":
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
JSON supportait les commentaires, mais ils ont été maltraités et supprimés de la norme.
Du créateur de JSON:
J'ai supprimé les commentaires de JSON parce que je voyais des personnes les utiliser 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 officiel JSON est à 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, est une alternative à XML facilement analysable (analyse humaine). 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 la relation "a-un" d'orientation d'objet peut comprendre n'importe quelle structure JSON - c'est tout le problème. 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.
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 rendraient simplement JSON moins interopérable. Il n'y a tout simplement rien d'autre à ajouter, sauf si vous avez vraiment besoin d'un langage de balisage (XML) et ne vous inquiétez pas du fait que vos données persistantes soient facilement analysées.
L'auteur de JSON souhaite que nous incluions des commentaires dans le JSON, mais supprimons-les avant de les analyser (voir link 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 créer de dépendance à la bibliothèque, voici une solution à deux lignes, qui fonctionne pour les commentaires de style C++, mais qui 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 syntaxique JSON, la suppression de commentaires et l'absence de bibliothèque supplémentaire consiste à évaluer le code 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 vos noms "notex" ne sont pas en conflit avec de vrais champs.
Vous pouvez utiliser JSON avec des commentaires, si vous le chargez en tant que fichier texte, puis supprimez les commentaires.
Vous pouvez utiliser decomment library pour cela. Vous trouverez ci-dessous un exemple complet.
JSON d'entrée (fichier input.js):
/*
* multi-line comments
**/
{
"value": 123 // one-line comment
}
Test Application:
var decomment = require('decomment');
var fs = require('fs');
fs.readFile('input.js', 'utf8', function (err, data) {
if (err) {
console.log(err);
} else {
var text = decomment(data); // removing comments
var json = JSON.parse(text); // parsing JSON
console.log(json);
}
});
Sortie:
{ value: 123 }
Voir aussi: gulp-decomment , grunt-decomment
Je viens de trouver " grunt-strip-json-comments ".
“Strip commentaires de JSON. Il vous permet d’utiliser des commentaires dans vos fichiers JSON! ”
{
// Rainbows
"Unicorn": /* ❤ */ "cake"
}
Si votre contexte est la configuration Node.js, vous pouvez envisager d'utiliser JavaScript via module.exports comme alternative au format JSON:
module.exports = {
"key": "value",
// And with comments!
"key2": "value2"
};
La syntaxe require sera toujours la même. En tant que JavaScript, l’extension de fichier devrait être .js.
Dans mon cas, j'ai besoin d'utiliser des commentaires à des fins de débogage, avant la sortie de la structure JSON. J'ai donc décidé d'utiliser les informations de débogage dans l'en-tête HTTP pour éviter de casser le client:
header("My-Json-Comment: Yes, I know it's a workaround ;-) ");
Vous pouvez utiliser un prétraitement simple via des expressions régulières. Par exemple, la fonction suivante décodera JSON commenté en PHP:
function json_decode_commented ($data, $objectsAsArrays = false, $maxDepth = 512, $opts) {
$data = preg_replace('~
(" (?:[^"\\\\] | \\\\\\\\ | \\\\")*+ ") | \# [^\v]*+ | // [^\v]*+ | /\* .*? \*/
~xs', '$1', $data);
return json_decode($data, $objectsAsArrays, $maxDepth, $opts);
}
Il supporte tous les commentaires de style PHP:/*, #, //. Les littéraux de chaîne sont conservés tels quels.
JSON n'autorise pas les commentaires, en soi. Le raisonnement est complètement idiot, car vous pouvez utiliser JSON lui-même pour créer des commentaires, ce qui supprime totalement le raisonnement. Et charge l'espace de données de l'analyseur sans raison valable. pour exactement le même résultat et les mêmes problèmes potentiels, tels qu’ils sont: un fichier JSON avec des commentaires.
Si vous essayez de mettre des commentaires dans (en utilisant
//ou/* */ou#par exemple), alors certains analyseurs échoueront car ce n'est pas le cas dans la spécification JSON. Donc, vous devriez jamais faire cela.
Voici un exemple où mon système de manipulation d'image a enregistré des notations d'image et des informations de base formatées (commentaires) les concernant (en bas):
{
"Notations": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Ellipse",
"extentX": 356,
"extentY": 294,
"opacity": 0.5,
"text": "Elliptical area on top",
"textX": 333,
"textY": 265,
"title": "Notation 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rectangle",
"extentX": 109,
"extentY": 412,
"opacity": 0.5,
"text": "Rect area\non bottom",
"textX": 98,
"textY": 385,
"title": "Notation 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygon",
"extentX": 102,
"extentY": 136,
"opacity": 0.5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Simple polygon",
"textX": 85,
"textY": 104,
"title": "Notation 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON image notation data:",
"c02": "-------------------------",
"c03": "",
"c04": "This data contains image notations and related area",
"c05": "selection information that provides a means for an",
"c06": "image gallery to display notations with elliptical,",
"c07": "rectangular, polygonal or freehand area indications",
"c08": "over an image displayed to a gallery visitor.",
"c09": "",
"c10": "X and Y positions are all in image space. The image",
"c11": "resolution is given as imageXW and imageYW, which",
"c12": "you use to scale the notation areas to their proper",
"c13": "locations and sizes for your display of the image,",
"c14": "regardless of scale.",
"c15": "",
"c16": "For Ellipses, anchor is the center of the ellipse,",
"c17": "and the extents are the X and Y radii respectively.",
"c18": "",
"c19": "For Rectangles, the anchor is the top left and the",
"c20": "extents are the bottom right.",
"c21": "",
"c22": "For Freehand and Polygon area modes, the pointList",
"c23": "contains a series of numbered XY points. If the area",
"c24": "is closed, the last point will be the same as the",
"c25": "first, so all you have to be concerned with is drawing",
"c26": "lines between the points in the list. Anchor and extent",
"c27": "are set to the top left and bottom right of the indicated",
"c28": "region, and can be used as a simplistic rectangular",
"c29": "detect for the mouse hover position over these types",
"c30": "of areas.",
"c31": "",
"c32": "The textx and texty positions provide basic positioning",
"c33": "information to help you locate the text information",
"c34": "in a reasonable location associated with the area",
"c35": "indication.",
"c36": "",
"c37": "Opacity is a value between 0 and 1, where .5 represents",
"c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
"c39": "backdrop. Recommendation is that regions be drawn",
"c40": "only if the user hovers the pointer over the image,",
"c41": "and that the text associated with the regions be drawn",
"c42": "only if the user hovers the pointer over the indicated",
"c43": "region."
}
}
Si vous utilisez PHP, vous pouvez utiliser cette fonction pour rechercher et supprimer ///* les commentaires de type de la chaîne JSON avant de l'analyse dans un objet/tableau:
function json_clean_decode($json, $assoc = true, $depth = 512, $options = 0) {
// search and remove comments like /* */ and //
$json = preg_replace("#(/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|([\s\t]//.*)|(^//.*)#", '', $json);
if(version_compare(phpversion(), '5.4.0', '>=')) {
$json = json_decode($json, $assoc, $depth, $options);
}
elseif(version_compare(phpversion(), '5.3.0', '>=')) {
$json = json_decode($json, $assoc, $depth);
}
else {
$json = json_decode($json, $assoc);
}
return $json;
}
J'espère que cela t'aides!
Non, json ne peut pas avoir de commentaires directement. Cependant, comme suggéré par this , vous pouvez obtenir un effet similaire en faisant quelque chose comme
{
"//name": "Name comment here",
"name": "Jack",
"//age": "Age comment here",
"age": "25"
}
La plupart des analyseurs syntaxiques json ignorent les propriétés qui ne sont pas mappées.
Bien sûr, vous pouvez commenter JSON. Pour lire un fichier JSON commenté à partir de javascript, vous pouvez supprimer les commentaires avant de les analyser (voir le code ci-dessous). Je suis sûr que ce code peut être amélioré, mais il est facile à comprendre pour ceux qui utilisent regexp.
J'utilise des fichiers JSON commentés pour spécifier les formes de neurone pour mes systèmes réflexes synthétiques. J'utilise également des commentaires JSON pour stocker des états intermédiaires pour un système de neurones en cours d'exécution. C'est très pratique d'avoir des commentaires. N'écoutez pas les didactes qui vous disent qu'ils sont une mauvaise idée.
fetch(filename).then(function(response) {
return response.text();
}).then(function(commented) {
return commented.
replace(/\/\*[\s\S]*?\*\/|([^\\:]|^)\/\/.*$/gm, '$1').
replace(/\r/,"\n").
replace(/\n[\n]+/,"\n");
}).then(function(clean) {
return JSON.parse(clean);
}).then(function(json) {
// Do what you want with the JSON object.
});
Comme de nombreuses réponses l'ont déjà indiqué, JSON n'a pas de commentaires natifs. Bien sûr, parfois, vous les voulez quand même. Pour Python, il existe deux méthodes: commentjson (# et // pour Python 2 uniquement) ou json_tricks (# ou // pour Python 2 et Python 3), qui comporte plusieurs autres fonctionnalités. Disclaimer: J'ai créé json_tricks.
La réponse pratique pour les utilisateurs de VSCode en 2019 consiste à utiliser l'extension «jsonc».
Pratique, car c'est l'extension reconnue par VSCode pour indiquer "JSON avec des commentaires". S'il vous plaît laissez-moi savoir sur d'autres éditeurs/IDE dans les commentaires ci-dessous.
Ce serait bien si VSCode et d'autres éditeurs ajoutaient également un support natif pour 'json5', mais pour le moment, VSCode inclut uniquement le support pour 'jsonc'.
(J'ai cherché dans toutes les réponses avant de poster ceci et aucune mention "jsonc".)
Oui, vous pouvez avoir des commentaires. Mais je ne recommanderai aucune des raisons mentionnées ci-dessus.
J'ai fait des recherches et j'ai trouvé que toutes les méthodes nécessitant JSON utilisent la méthode JSON.parse. Je suis donc parvenu à une solution: nous pouvons remplacer ou appliquer des correctifs monotones autour de JSON.parse.
Note: testé sur Node.js uniquement ;-)
var oldParse = JSON.parse;
JSON.parse = parse;
function parse(json){
json = json.replace(/\/\*.+\*\//, function(comment){
console.log("comment:", comment);
return "";
});
return oldParse(json)
}
Fichier JSON:
{
"test": 1
/* Hello, babe */
}
Je suis tombé sur ce problème dans mon projet actuel, car j'ai pas mal de JSON qui nécessite quelques commentaires pour que les choses restent faciles à mémoriser.
J'ai utilisé cette simple fonction python pour remplacer les commentaires et utiliser json.loads pour le convertir en dict:
import json, re
def parse_json(data_string):
result = []
for line in data_string.split("\n"):
line = line.strip()
if len(line) < 1 or line[0:2] == "//":
continue
if line[-1] not in "\,\"\'":
line = re.sub("\/\/.*?$", "", line)
result.append(line)
return json.loads("\n".join(result))
print(parse_json("""
{
// This is a comment
"name": "value" // so is this
// "name": "value"
// the above line gets removed
}
"""))
Vous pouvez utiliser JSON-LD _ et le type { schema.org commentaire } _ pour écrire correctement les commentaires:
{
"https://schema.org/comment": "this is a comment"
}
Les fichiers * .json sont généralement utilisés comme fichiers de configuration ou données statiques, d'où la nécessité de commenter → certains éditeurs comme NetBeans acceptent les jcomments en * .json.
Le problème est d'analyser le contenu dans un objet. La solution consiste à toujours appliquer une fonction de nettoyage (serveur ou client).
PHP
$rgx_arr = ["/\/\/[^\n]*/sim", "/\/\*.*?\*\//sim", "/[\n\r\t]/sim"];
$valid_json_str = \preg_replace($rgx_arr, '', file_get_contents(path . '*.json'));
JavaScript
valid_json_str = json_str.replace(/\/\/[^\n]*/gim.'').replace(/\/\*.*?\*\//gim,'')
Il existe d'autres bibliothèques compatibles JSON, qui prennent en charge les commentaires.
Un exemple notable est le "Hashcorp Language" (HCL) " . Il est écrit par les mêmes personnes qui ont créé Vagrant, packer, consul et vault.
L'ensemble de la discussion suppose que l'ajout de commentaires est la seule amélioration à apporter à JSON. Si quelqu'un ne veut pas de commentaires dans JSON parce qu'il doit être utilisé pour la sérialisation, omettez-les. La même chose vaut pour les espaces. Mais pourquoi s'arrêter là? Pourquoi les guillemets requis en JSON? Ils n'ajoutent rien d'utile.
La seule raison pour laquelle JSON est aussi rigide, c’est si l’analyse est difficile. Mais ça ne l'est pas. Presque tous les programmeurs peuvent écrire un analyseur JSON, dans les deux sens.
Je veux que JSON soit lisible et efficace (bref), et utile pour la transmission de données, les fichiers de configuration, etc. L'exemple suivant satisfait à ces deux exigences:
{stringA: stringB, stringC: stringD, [stringE, stringF]}
Plus courte que n'importe quelle spécification JSON existante, mais tout aussi lisible et plus efficace.
Besoin d'inclure des guillemets, des apostrophes, des virgules ou des crochets dans une propriété ou une valeur? Il vous suffit de les inclure dans des points d'interrogation ou des apostrophes (avec une évasion de barre oblique inversée), comme en JavaScript.
Mais s'il vous plaît rendre les guillemets facultatifs. Pourquoi? Comme JSON ne peut pas contenir de noms de variable ou de fonction (pour éviter les attaques par injection), les guillemets ne fournissent aucune homonymie. Nous savons déjà que toutes les données sont des chaînes. Alors, s'il vous plaît, laissez de côté les guillemets déjà, à moins qu'ils ne soient vraiment nécessaires.