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

7614

Puis-je utiliser des commentaires dans un fichier JSON? Si c'est le cas, comment?

Michael Gundlach
la source
153
@StingyJack: Pour expliquer des choses qui peuvent ne pas être évidentes, ou tout ce que l'on pourrait faire avec des commentaires. Pour ma part, j'ai souvent des commentaires dans les fichiers de données. XML, les fichiers ini et de nombreux autres formats incluent des dispositions pour les commentaires.
Michael Burr
24
Si vous, comme moi, vous vous demandiez si vous //commentsêtes d'accord avec le cas d'utilisation spécifique d'un fichier de configuration Sublime Text, la réponse est oui (à partir de la version 2). Sublime Text ne s'en plaindra pas, du moins, alors qu'il s'en plaindra {"__comment": ...}dans la console, car c'est un champ inattendu.
driftcatcher
8
et c'est peut-être une des raisons pour lesquelles TOML a été créé ..
Alex Nolasco
10
Légèrement noobish mais, j'ai aussi essayé d'utiliser // pour les commentaires en JSON. Maintenant, je me rends compte qu'il est strictement utilisé pour l'échange / échange. Soupir! Je ne peux plus commenter :(. La vie est condamnée !.
Sid
12
JSON5 prend en charge les commentaires: stackoverflow.com/a/7901053/108238
schoetbi

Réponses:

5597

Non.

Le JSON devrait tous être des données, et si vous incluez un commentaire, ce seront aussi des 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.

Vous feriez probablement mieux d'avoir le commentaire dans les processus qui génèrent / reçoivent le JSON, car ils sont censés savoir à l'avance quelles seront les données JSON, ou du moins la structure de celles-ci.

Mais si vous décidez 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"
            }
         }
      }
   }
}
Eli
la source
233
Il pourrait être avantageux d'avoir une sorte de préfixe sur le commentaire réel au cas où il y aurait un champ valide nommé commentaire:"__comment":"comment text goes here...",
Rob Fonseca-Ensor
19
BTW, la bibliothèque json pour Java google-gson prend en charge les commentaires.
Centic
11
Et si je voulais un commentaire séparé sur les propriétés Accronymet Abbrev? J'ai déjà utilisé ce modèle mais je l'ai arrêté car il ne me permet pas de le faire. C'est un hack. Peut-être que si je préfère ajouter un nom de propriété à la __comment__place. C'est "__comment__Abbrev", toujours un hack, mais permettez-moi de commenter toutes les propriétés
Juan Mendes
41
vous pouvez également utiliser "//": cela semble plus natif et est toujours reproductible dans le même parent
smnbbrv
4
Lorsque JSON est utilisé pour des fichiers de configuration destinés aux humains, ils doivent être annotés pour que les humains les comprennent mieux. Annoté, ce fichier n'est plus du JSON valide, mais il existe des solutions. Par exemple, le GYP de Google prend en charge les commentaires de style #. JSON.Minify vous aidera à supprimer les commentaires de style C / C ++ de votre fichier d'entrée.
Петър Петров
1842

Non , 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 application/jsontype de support pour la notation d'objet JavaScript (JSON)
  • RFC 8259 Format d'échange de données JSON (JavaScript Object Notation) (remplace les RFC 4627, 7158, 7159)
stakx - ne contribue plus
la source
67
Si vous souhaitez annoter votre JSON avec des commentaires (le rendant ainsi invalide JSON), réduisez-le avant d'analyser ou de transmettre. Crockford lui-même l'a reconnu en 2012 dans le contexte des fichiers de configuration.
toolbear
25
@alkuzad: En ce qui concerne les grammaires formelles, il doit y avoir quelque chose qui dit explicitement qu'elles sont autorisées, et non l'inverse. Par exemple, prenez votre langage de programmation de choix: ce n'est pas parce qu'une fonctionnalité souhaitée (mais manquante) n'est pas explicitement interdite que votre compilateur la reconnaîtra comme par magie.
stakx - ne contribue plus le
5
Oui. Le format JSON a beaucoup d'espace mort entre les éléments et est insensible à l'espace dans ces régions, il n'y a donc aucune raison pour que vous ne puissiez pas y avoir de commentaires sur une ou plusieurs lignes. De nombreux analyseurs et minificateurs prennent également en charge les commentaires JSON, alors assurez-vous simplement que votre analyseur les prend en charge. JSON est beaucoup utilisé pour les données d'application et les paramètres de configuration, des commentaires sont donc nécessaires maintenant. La "spécification officielle" est une bonne idée, mais elle est insuffisante et obsolète, donc tant pis. Réduisez votre JSON si vous êtes préoccupé par la taille ou les performances de la charge utile.
Triynko
58
Bien que votre réponse soit absolument correcte, il faut dire que c'est BS. Avec autant d'utilisateurs finaux rencontrant le besoin d'une configuration json, les commentaires sont extrêmement utiles. Tout simplement parce que certains chapeaux en papier d'aluminium ont décidé que JSON est et doit toujours être lisible par machine, ignorant le fait que les humains doivent le lire, est à mon avis une parodie de petite mentalité.
cmroanirgo
18
@cmroanirgo: Vous n'êtes évidemment pas le premier à vous plaindre de cette limitation de JSON ... c'est pourquoi nous avons des analyseurs qui autorisent silencieusement les commentaires, et d'autres formats tels que YAML et JSON5. Cependant, cela ne change pas le fait que JSON est ce qu'il est. Au contraire, je trouve intéressant que les gens aient commencé à utiliser JSON à des fins où cela n'était clairement pas suffisant en premier lieu, compte tenu de la limitation en question. Ne blâmez pas le format JSON; nous blâmer d'avoir insisté pour l'utiliser là où il ne convient pas particulièrement.
stakx - ne contribue plus le
802

Incluez des commentaires si vous le souhaitez; les retirer avec un minificateur avant d'analyser ou de transmettre.

Je viens de publier JSON.minify () qui supprime les commentaires et les espaces d'un bloc de JSON et en fait un JSON valide qui peut être analysé. Donc, vous pourriez l'utiliser comme:

JSON.parse(JSON.minify(my_str));

Lorsque je l'ai publié, j'ai eu un énorme contrecoup de personnes en désaccord avec l'idée même, j'ai donc décidé d'écrire un article de blog complet sur la raison pour laquelle les commentaires ont du sens dans JSON . Il comprend 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. Ensuite, dirigez-le via 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.

Kyle Simpson
la source
153
Le seul problème que j'ai avec JSON.minify () est qu'il est vraiment très lent. J'ai donc fait ma propre implémentation qui fait la même chose: gist.github.com/1170297 . Sur certains fichiers de test volumineux, votre implémentation prend 74 secondes et la mienne 0,06 secondes.
WizKid
56
ce serait génial si vous pouviez soumettre l'algorithme alternatif suggéré au référentiel github pour JSON.minify (), afin qu'il puisse être porté sur toutes les langues
Kyle Simpson
16
@MiniGod J'ai déjà entendu à plusieurs reprises les réflexions de Doug sur ce sujet. Je les ai abordés il y a longtemps dans mon article de blog: blog.getify.com/json-comments
Kyle Simpson
18
@ MarnenLaibow-Koser, il existe encore des utilisations valides pour les commentaires, même pour l'utilisation de flux de données (ou même de paquets): l'inclusion de métadonnées de diagnostic comme le temps de création ou les sources est une utilisation courante avec XML et parfaitement adaptée aux données JSON. Les arguments contre les commentaires sont superficiels, et tout format de données textuelles devrait permettre les commentaires, indépendamment de l'utilisation implicite prévue (rien ne spécifie que JSON ne peut pas être utilisé ailleurs, fwiw)
StaxMan
18
Si JSON doit avoir une acceptation universelle (ce qu'il fait essentiellement), il doit avoir une application universelle. Exemple: JSON peut servir de fichier de configuration d'application. Cette application souhaiterait des commentaires.
eggmatters
441

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

J'ai supprimé les commentaires de JSON parce que j'ai vu que les gens les utilisaient pour contenir 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. Ensuite, dirigez-le via JSMin avant de le remettre à votre analyseur JSON.

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

Artur Czajka
la source
198
Je pensais que JSON devait être plus lisible par l'homme que, disons, XML? Les commentaires sont pour la lisibilité.
intrepidis du
25
Quoi qu'il en soit, vous pourriez être méchant et ajouter des directives d'analyse dans les JSON: {"__directives": {"# n #": "DateTime.Now"}, "validdate": "# n #"} ... Cela ressemble à YAML est la voie à suivre alors ...
intrepidis
73
Opinion personnelle: ne pas autoriser les commentaires EST boiteux. Je n'avais pas d'autre option que de construire un analyseur JSON non standard qui ignore les commentaires, pour décoder mes fichiers de configuration.
caiosm1005
17
@ArturCzajka Je n'aime toujours pas le fait que JSON ne supporte pas les commentaires, mais j'ai essayé INI et je dois admettre qu'il est beaucoup plus logique de les utiliser sur JSON pour les fichiers de configuration. Merci pour la réponse et j'espère que plus de gens changeront d'avis en lisant cette conversation. (faire un analyseur était de toute façon plus un exercice :)
caiosm1005
77
C'est comme exiger que tous les vélos aient des roues d'entraînement parce que certaines personnes ne peuvent pas faire de vélo. Supprimer une fonctionnalité importante parce que des personnes stupides en abusent est une mauvaise conception. Un format de données devrait donner la priorité à l'utilisabilité plutôt que d'être à l'épreuve des idiots.
Phil Goetz
205

AVERTISSEMENT: VOTRE GARANTIE EST NULLE

Comme cela a été souligné, ce hack profite de l'implémentation de la spécification. Tous les analyseurs JSON ne comprendront pas ce type de JSON. Les analyseurs en streaming en particulier s'étoufferont.

C'est une curiosité intéressante, mais vous ne devriez vraiment pas l'utiliser du tout . Voici la réponse originale.


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

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 a priorité. Croyez-le ou non, il s'avère que les analyseurs 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ée.

({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.

Bon piratage!

p3drosola
la source
150
D'après la spécification : Les noms dans un objet DEVRAIENT être uniques.
Quentin
113
"toutes les implémentations le traitent de la même manière" - C'est une chose difficile à prouver.
Quentin
91
L'ordre des éléments dans JSON n'est pas garanti. Cela signifie que le «dernier» élément pourrait changer!
sep332
66
Cela viole clairement les spécifications (voir les commentaires ci-dessus), ne faites pas cela. ietf.org/rfc/rfc4627.txt?number=4627
voidlogic
334
NON - que faire si l'analyseur est en streaming? Et si l'analyseur le lit dans un dictionnaire où l'ordre des clés n'est pas défini? tuez cela avec le feu .
deanWombourne
184

JSON ne prend pas en charge les commentaires. Il n'a également jamais été destiné à être utilisé pour les fichiers de configuration où 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.

Hjson intro

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

laktak
la source
13
A voté. C'est évidemment une bonne variation que les conservateurs non ouverts aimeraient juste détester. J'espère que votre implémentation sera mieux connue - et peut-être même plus populaire que l'original;) ​​J'espère que quelqu'un pourra également l'implémenter avec Ruby. @adelphus Le langage bien défini est votre propre perspective ou opinion. Être un "développeur" conservateur si vous en êtes un ne prouve pas que vous êtes meilleur et vous pourriez être encore pire en vous enfermant dans des espaces limités. Ne jugez pas facilement les gens comme de terribles développeurs.
konsolebox
7
Désolé pour ça, @konsolebox. Peut-être pourriez-vous reconsidérer votre point de vue "JSON bien défini est votre opinion" après avoir lu ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf C'est un vrai standard et les développeurs implémentent leurs propres versions "spéciales" conduit à la fragmentation, la confusion et beaucoup de temps perdu. Regardez le désordre que les développeurs Web se retrouvent lors de l'écriture de code simplement parce que chaque navigateur implémente des versions légèrement différentes des normes. Le langage JSON n'est peut-être pas parfait, mais la fragmentation est pire. Et oui, ce n'est qu'une opinion et vous êtes libre d'être en désaccord.
adelphus
22
J'admire votre stupeur, mais vous réinventez un peu YAML. Si vous voulez beaucoup de flexibilité et de lisibilité humaine, utilisez YAML (ne faites pas réellement: stackoverflow.com/questions/450399/… ) ou restez avec curmudgeony, mais sans ambiguïté JSON.
toolbear
4
Je trouve que le format de configuration le plus convivial est toujours INI. C'est simple et pas très lourd en syntaxe. Cela rend moins intimidant pour les utilisateurs de simplement tremper leurs orteils dans l'étang de configuration.
Matt
14
Chaque fois que vous avez besoin de json comme configuration (où des commentaires sont nécessaires) - nommez votre fichier ".js" au lieu de ".json" .. js peut bien sûr gérer n'importe quel objet json valide et peut également gérer les commentaires .. C'est la raison pour laquelle il est "webpack.config.js" et non "webpack.config.json" (eh bien, il y a bien plus de raisons pour cela dans webpack: P)
jebbie
122

Pensez à utiliser YAML. C'est presque un surensemble de JSON (pratiquement tout JSON valide est YAML valide) et il permet les commentaires.

Marnen Laibow-Koser
la source
12
@ g33kz0r Correct, d'où ma description de YAML en tant que quasi-sur-ensemble de JSON.
Marnen Laibow-Koser
12
@NateS Beaucoup de gens avaient déjà souligné que la réponse était non. J'ai suggéré une meilleure façon d'atteindre l'objectif du PO. Voilà une réponse.
Marnen Laibow-Koser
5
Inconvénient: la yamlbibliothèque n'est pas livrée avec Python.
Bleeding Fingers
6
@ marnen-laibow-koser: yup, il a dû être incompétent d'utiliser les bibliothèques YAML disponibles pour Java et Perl et de s'attendre à ce que le YAML produit par chacun soit consommé par l'autre sans erreur. Cette interopérabilité YAML était un problème, mais pas l'interopérabilité JSON, s'explique entièrement par mon manque de connaissances.
toolbear
3
@ marnen-laibow-koser, un format qui accomplit la même chose avec une spécification plus simple est meilleur. Un format pragmatique avec des implémentations parfaites est meilleur qu'un format idéal avec des implémentations imparfaites. Tout le blâme pour les bibliothèques défectueuses ne repose pas sur les épaules des implémenteurs; la spécification YAML est longue, dense et obtuse. Son entrée Wikipédia cite deux exemples d'ambiguïtés; si l'on doit mettre un émetteur entre un humain et le format pour le protéger des ambiguïtés, le format perd sa prétention humaine. JSON réclame moins et réussit surtout là où YAML réclame plus et échoue.
toolbear
108

Tu ne peux pas. Du moins, c'est mon expérience d'un coup d'œil rapide sur json.org .

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

Gai
la source
67

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 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 à l'analyseur et non standard.

Un autre analyseur est JSON5 .

Une alternative à JSON TOML .

Une autre alternative est jsonc .

schoetbi
la source
Groovy a des classes intégrées pour gérer JSON . JsonSlurper peut gérer les commentaires. Bien sûr, les commentaires ne sont pas autorisés dans les spécifications officielles, donc ce comportement dans n'importe quel analyseur est non standard et non portable.
izrik
Newtonsoft Json.NET prend également en charge les commentaires de style C sans aucun problème
Max
66

Vous devez 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 de description .

tirage au sort
la source
5
Le schéma JSON est-il vivant? Il existe mais est-il pris en charge par une bibliothèque connue?
Munhitsu
1
oui, le groupe google json-schema est assez actif et je recommanderais JSV pour une bonne implémentation JavaScript d'un validateur de schéma JSON.
tombel
5
Cela n'aide que la documentation structurée, pas la documentation ad hoc
Juan Mendes
Si vous utilisez clojure (et je suis sûr que vous ne l'utilisez pas), il y a un analyseur de schéma JSON open source raisonnablement présenté ici: github.com/bigmlcom/closchema
charleslparker
@Munhitsu Manatee.Json (.Net) prend largement en charge le schéma JSON.
gregsdennis
64

Si vous utilisez Jackson comme analyseur JSON, voici comment l'activer 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 définir:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Mais en général (comme répondu précédemment), la spécification ne permet pas de commentaires.

Andrejs
la source
50

Voici ce que j'ai trouvé dans la documentation de 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"
}
mana
la source
Pour info, Firebase Realtime Database ne permet pas l'utilisation de '/' dans une clé. cela peut donc être une bonne convention pour votre propre usage, mais vous ne pouvez pas le faire dans Firebase
gutte
5
Cette méthode casse certaines bibliothèques, qui nécessitent que la clé soit unique. Je contourne ce problème en numérotant les commentaires.
MovGP0
bon commentaire, j'ai trouvé cette question sur SO ... cette partie ne semble pas être couverte par la spécification stackoverflow.com/questions/21832701/…
mana
4
J'ai tendance à l'utiliser comme ceci de nos jours: {"// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} Vous pouvez utiliser un tableau pour plusieurs commentaires: {"// foo": ["foo comment 1", "foo comment 2"], "foo": '' foo value "}
MovGP0
47

NON . JSON supportait les commentaires, mais ils ont été maltraités et retirés de la norme.

Du créateur de JSON:

J'ai supprimé les commentaires de JSON parce que j'ai vu que les gens les utilisaient 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. - Douglas Crockford, 2012

Le site officiel de JSON se trouve sur JSON.org . JSON est défini comme une norme par ECMA International. Il y a toujours un processus de pétition pour 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 facilement inversée (analysée par l'homme) à XML. Il est même 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é.

Quiconque comprend la relation "has-a" de l'orientation d'objet peut comprendre n'importe quelle structure JSON - c'est tout. Il s'agit simplement d'un graphe acyclique dirigé (DAG) avec des étiquettes de nœuds (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és 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, sauf si vous avez vraiment besoin d'un langage de balisage (XML), et ne vous souciez pas si vos données persistantes sont facilement analysées.

MAIS comme le créateur de JSON l'a également observé, il y a toujours eu un support de pipeline JS pour les commentaires:

Allez-y et insérez tous les commentaires que vous aimez. Ensuite, dirigez-le via JSMin avant de le remettre à votre analyseur JSON. - Douglas Crockford, 2012

Dominic Cerisano
la source
37

Si votre fichier texte, qui est une chaîne JSON, va ê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 paquebot. Si vous faites cela, les fichiers JSON pourraient être utilisés comme fichiers de configuration.

John T. Vonachen
la source
1
Probablement la meilleure suggestion jusqu'à présent, bien que toujours un problème pour conserver les fichiers en tant que format d'échange, car ils ont besoin d'un prétraitement avant utilisation.
Orbling
J'accepte et j'ai écrit un analyseur JSON en Java, disponible sur www.SoftwareMonkey.org, qui fait exactement cela.
Lawrence Dol
2
Malgré je pense, ce n'est pas une bonne idée d'étendre JSON (sans l'appeler un format d'échange différent): assurez-vous d'ignorer les "commentaires" dans les chaînes. {"foo": "/ * Ce n'est pas un commentaire. * /"}
stofl
27
"... serait une ligne" umm, non, en fait, JSON n'est pas une grammaire régulière où une expression régulière peut simplement trouver des paires correspondantes de / *. Vous devez analyser le fichier pour trouver si un / * apparaît dans une chaîne (et l'ignorer), ou s'il est échappé (et l'ignorer), etc. De plus, votre réponse est inutile car vous spéculez simplement (incorrectement) plutôt que de fournir Toute solution.
Kyle Simpson
1
Ce que @ kyle-simpson a dit. En outre, il est trop modeste pour diriger les lecteurs vers sa propre réponse sur l'utilisation de JSON.minify comme alternative aux expressions régulières ad hoc. Faites ça, pas ça.
toolbear
36

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 qu'avec 6+ versions 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 settings avec la bibliothèque Newtonsoft et l'utilise quand c'est 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 l'intégrité du format JSON tant que la bibliothèque que j'utilise est OK avec.

Je pense que c'est une manière «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 du format JSON, et vous ne pouvez rien y faire.

dvdmn
la source
Il est difficile de comprendre pourquoi quelqu'un aurait du mal à énoncer un fait.
dvdmn
Je suppose que quelqu'un a fait exception parce que ce qui précède n'est plus JSON ou n'est pas JSON invalide. Peut-être que l'ajout d'un bref avertissement apaiserait.
toolbear
5
Je suis entièrement d'accord avec vous, et pourtant il y a jusqu'à présent 883 votes positifs pour la non-réponse qui indique simplement l'évidence. La pureté idéologique valorisée au-dessus des informations utiles, c'est donc pour vous.
John
Le fait est qu'un fichier avec des commentaires n'est pas JSON et ne sera pas analysé par de nombreuses bibliothèques JSON. N'hésitez pas à faire ce que vous voulez dans votre propre programme mais un fichier avec des commentaires n'est pas JSON. Si vous le prétendez, les gens essaieront de l'analyser avec la langue / bibliothèque de leur choix et cela échouera. C'est comme demander si vous pouvez utiliser des crochets au lieu des crochets en XML. Vous pouvez faire ce que vous voulez mais ce ne sera plus du XML.
gman
32

L'idée derrière JSON est de fournir un échange de données simple entre les applications. Ceux-ci sont généralement basés sur le Web et la langue est JavaScript.

Cela ne permet pas vraiment les commentaires en tant que tels, cependant, 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 dit, il n'est pas dans l'intention que le fichier JSON contienne des commentaires au sens traditionnel. Ce devrait être seulement les données.

Jetez un œil au site Web JSON pour plus de détails.

Neil Albrock
la source
17
Il est vrai que le format JSON n'a pas de commentaires. Personnellement, je pense que c'est une erreur importante - la possibilité d'avoir des commentaires sous forme de métadonnées (pas de données) est une chose très utile avec xml. Les versions antérieures de la spécification JSON incluaient des commentaires, mais pour une raison quelconque, elles ont été supprimées. : - /
StaxMan
4
@StaxMan, ils ont été supprimés exactement parce que les gens ont commencé à les utiliser comme métadonnées. Crockford a déclaré qu'il avait rompu la compatibilité de la conception du format, et je suis d'accord: si vous voulez des métadonnées, pourquoi ne pas les inclure en tant que données réelles? Il est encore plus facile d'analyser de cette façon.
Camilo Martin
6
Les métadonnées appartiennent aux constructions de métadonnées (par exemple les balises HTML <meta>), pas aux commentaires. L'utilisation abusive des commentaires pour les métadonnées n'est qu'un hack utilisé lorsqu'il n'existe pas de véritable construction de métadonnées.
Marnen Laibow-Koser
C'est exactement la raison pour laquelle il a été supprimé: les commentaires utilisés comme métadonnées rompraient l'interopérabilité. Vous devez également stocker vos métadonnées au format JSON.
génial
1
Cette réponse est redondante avec des réponses mieux écrites et plus élevées, qui disent essentiellement la même chose, même si cela a peut-être été écrit plus tôt. C'est la vie.
toolbear
29

Je viens de rencontrer cela pour les fichiers de configuration. Je ne veux pas utiliser le format XML (verbeux, graphique, laid, difficile à lire), ou "ini" (pas de hiérarchie, pas de véritable standard, etc.) ou le format Java "Propriétés" (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 sont faciles et omniprésents dans de nombreuses langues. Ce n'est qu'un arbre de données. Mais les commentaires hors bande sont souvent nécessaires pour documenter les configurations "par défaut" et similaires. Les configurations ne doivent jamais être des «documents complets», mais des arbres de données enregistrées qui peuvent être lisibles par l'homme en cas de besoin.

Je suppose que l'on pourrait utiliser "#": "comment", pour JSON "valide".

peterk
la source
4
Pour les fichiers de configuration, je suggère YAML, pas JSON. C'est (presque) un surensemble plus puissant de JSON, mais prend également en charge des constructions plus lisibles, y compris les commentaires.
Marnen Laibow-Koser
1
selon vous, combien de langues prend en charge YAML par rapport à json?
mmm
@Hamidam Plus d'une douzaine de langues prennent en charge yaml: yaml.org - mais vous avez raison de demander combien ont une prise en charge intégrée, sans avoir besoin d'une dépendance de bibliothèque tierce. Ressemble à Ruby 1.9.2. Quelqu'un en connaît d'autres? Et quelles langues prennent en charge json par défaut?
nealmcb
5
L'interopérabilité YAML est un mensonge: stackoverflow.com/questions/450399/… . Si votre instinct est d'utiliser JSON pour les fichiers de configuration, suivez-le.
toolbear
C'est vieux, mais je pense que l'utilisation de # n'est pas une bonne idée. Json est proche de la syntaxe d'un littéral Javascript. Javascript prend en charge 2 types de commentaires: // et / * ... * / Si j'étais vous, je m'en tiendrais à l'un de ces types de commentaires ou aux deux.
Pascal Ganaye
28

JSON ne prend pas en charge les commentaires en mode natif, mais vous pouvez créer votre propre décodeur ou au moins un préprocesseur pour supprimer les commentaires, c'est tout à fait correct (tant que vous ignorez simplement les commentaires et ne les utilisez pas pour guider la façon dont votre application doit traiter 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 à ça que sert JSON.

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

généreux
la source
4
Crockford a ensuite écrit: "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, dirigez-le via JSMin avant de le remettre à votre analyseur JSON." Voir la réponse de @ kyle-simpson à propos de JSON.minify pour plus d'informations.
toolbear
27

JSON a beaucoup de sens pour les fichiers de configuration et autres utilisations locales car il est omniprésent et parce qu'il 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 de données (valides ou non), alors JSON pourrait être divisé en deux:

  • JSON-COM: JSON sur le fil, ou règles qui s'appliquent lors de la communication des 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 autorise les commentaires et d'autres différences mineures peuvent exister, telles que la gestion des espaces blancs. Les analyseurs peuvent facilement convertir d'une spécification à l'autre.

En ce qui concerne la remarque faite par Douglas Crockford sur ces questions (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. Ensuite, dirigez-le via JSMin avant de le remettre à votre analyseur JSON.

Nous parlons d'un problème de fichier de configuration générique (cross language / plateforme), et il répond avec un utilitaire spécifique JS!

Bien sûr, un minify spécifique JSON peut être implémenté dans n'importe quelle langue, mais standardisez-le afin qu'il devienne omniprésent dans tous les analyseurs dans toutes les langues et plates-formes afin que les gens cessent de perdre leur temps sans la fonctionnalité, car ils ont de bons cas d'utilisation pour cela, recherchant le problème dans forums en ligne, et amener les gens à leur dire que c'est une mauvaise idée ou à suggérer qu'il est facile de mettre en œuvre le retrait des commentaires 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 auquel sont associés des fichiers de configuration ou de données. Et ce sous-système doit être accessible à partir de différentes langues. Ensuite, allez-vous dire aux gens: au fait, n'oubliez pas de supprimer les commentaires des fichiers JSON avant de les transmettre à l'analyseur!

Basel Shishani
la source
Pas besoin de fragmenter JSON. JSON avec commentaires n'est plus JSON. Mais il est parfaitement acceptable d'annoter votre JSON avec des commentaires, tant que vous vous assurez de les supprimer avant de les analyser ou de les transmettre. Il ne devrait jamais être de la responsabilité du récepteur de le faire.
toolbear
json5.org est une solution pour json-doc
Michael Freidgeim
24

Si vous utilisez JSON5, vous pouvez inclure des commentaires.


JSON5 est une extension proposée pour JSON qui vise à faciliter l'écriture et la maintenance à la main par les humains. Pour ce faire, il ajoute des fonctionnalités de syntaxe minimale directement à partir d'ECMAScript 5.

Smit Johnth
la source
5
Pourriez-vous s'il vous plaît ajouter un exemple? Ensuite, vous aurez peut-être besoin de ces caractères supplémentaires.
dgilperez
6
Il est requis par les directives SO pour fournir une réponse réelle. Les réponses de lien uniquement ne sont pas souhaitées. Vous pouvez consulter les directives stackoverflow.com/help/how-to-answer
dgilperez
2
SO est modéré par ses utilisateurs. Cela signifie que je peux fournir une réponse si je l'ai de la même manière que je peux commenter la vôtre si elle ne suit pas les directives. C'est ainsi que SO devient une excellente ressource.
dgilperez
22

La boîte à outils JavaScript Dojo Toolkit (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' dojo.xhrGet()appel.

D'autres kits d'outils JavaScript peuvent fonctionner de manière similaire.

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.

David
la source
4
Non, pas ça. JSON n'a pas de commentaires. Si vous choisissez d'annoter votre JSON avec des commentaires, réduisez-le avant l'analyse ou la transmission. Cela ne devrait pas être la responsabilité du récepteur.
toolbear
2
Je n'ai pas dit que JSON avait des commentaires. Je ne voulais pas non plus laisser entendre qu'il est approprié de les inclure dans votre JSON, en particulier dans un système de production. J'ai dit que la boîte à outils Dojo vous permet de les ajouter, ce qui est (ou du moins, était) vrai. Il existe des cas d'utilisation très utiles pour le faire dans votre phase de test.
David
1
C'est mauvais vaudou de servir commenté, et donc invalide JSON, ce dojo.xhrGet()qui encourage implicitement en acceptant.
toolbear
Je vote toujours pour la mise à niveau de la spécification JSON pour permettre les commentaires. Je suis tout pour minimiser et supprimer les commentaires avant de transmettre le JSON, mais je n'ai pas la possibilité de commenter votre JSON de manière standard sans avoir à le passer par un utilitaire séparé avant de l'analyser, cela semble juste idiot. Je rend également impossible l'utilisation d'un éditeur JSON sur vos fichiers de configuration JSON, car vos fichiers ne sont pas des JSON valides.
Craig
20

JSON n'est pas un protocole encadré . Il s'agit d'un format sans langue . Le format d'un commentaire n'est donc pas défini pour JSON.

Comme beaucoup de gens l'ont suggéré, il existe des astuces, par exemple des clés en double ou une clé spécifique _commentque vous pouvez utiliser. C'est à vous.

Manish Shrivastava
la source
18

Vous pouvez avoir des commentaires en JSONP , mais pas en 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]
]);

Étant donné que j'avais un fichier similaire dans mon dossier local, il n'y avait aucun problème avec la politique de même origine , j'ai donc décidé d'utiliser du JSON pur ... et, bien sûr, $.getJSONéchouait silencieusement à cause des commentaires.

Finalement, je viens d'envoyer une demande HTTP manuelle à l'adresse ci-dessus et j'ai réalisé que le type de contenu était text/javascriptdepuis, eh bien, JSONP renvoie du JavaScript pur. Dans ce cas, les commentaires sont autorisés . Mais mon application a renvoyé le type de contenu application/json, j'ai donc dû supprimer les commentaires.

osa
la source
17

Il s'agit d'une question «pouvez-vous» . Et voici une réponse "oui" .

Non, vous ne devez pas utiliser de membres d'objet duplicatifs pour placer des données de canal latéral dans un codage JSON. (Voir «Les noms dans un objet DEVRAIENT être uniques» dans la RFC ).

Et oui, vous pouvez insérer des commentaires autour du JSON , que vous pouvez 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 profitons de la représentation non unique des données dans un encodage JSON. Ceci est autorisé * dans la section deux de la RFC sous "les espaces blancs sont autorisés avant ou après l'un des six caractères structurels".

* La RFC indique uniquement 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, "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;
William Entriken
la source
1
La RFC indique uniquement que "l'espace est autorisé avant ou après l'un des six caractères structurels", sans mentionner explicitement les chaînes, les nombres, "false", "true", "null". Cette omission est ignorée dans TOUTES les implémentations.
William Entriken du
1
Pour une plus grande densité de commentaires, ne pourriez-vous pas encoder votre commentaire en ternaire et utiliser l'espace, la tabulation et la nouvelle ligne pour le steg?
Claire Nielsen
DEVRAIT n'est pas DOIT. Voir la RFC 2119 explicitement incluse: DOIT: Ce mot, ou les termes "REQUIS" ou "DOIT", signifient que la définition est une exigence absolue de la spécification. ... DEVRAIT: Ce mot, ou l'adjectif "RECOMMANDÉ", signifie qu'il peut exister des raisons valables dans des circonstances particulières d'ignorer un élément particulier, mais toutes les implications doivent être comprises et soigneusement pesées avant de choisir un cours différent.
Jeff K
Bonne référence. Un meilleur raisonnement contre l'utilisation de clés dupliquées est la citation de la norme "Lorsque les noms dans un objet ne sont pas uniques, le comportement du logiciel qui reçoit un tel objet est imprévisible.". De plus, je comprends maintenant pourquoi la norme n'était pas "DOIT être unique", cela rend un valideur plus simple, il n'a qu'à suivre [et {, il n'a pas besoin de savoir quelles clés ont déjà été utilisées.
William Entriken
16

AVERTISSEMENT: C'EST Bête

Il existe en fait un moyen d'ajouter des commentaires et de rester dans la spécification (aucun analyseur supplémentaire nécessaire). Cela n'entraînera pas de commentaires lisibles par l'homme sans aucune sorte d'analyse.

Vous pourriez abuser des éléments suivants:

Les espaces insignifiants sont autorisés avant ou après tout jeton. Les espaces blancs sont n'importe quelle séquence d'un ou 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).

D'une 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 espaces pour les représenter. Par exemple.

010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202

( hello base threeen ASCII) Mais au lieu de 0 utiliser l'espace, pour 1 utiliser le saut de ligne et pour 2 utiliser le retour chariot.

Cela vous laissera juste beaucoup d'espace blanc illisible (sauf si vous créez un plugin IDE pour le coder / décoder à la volée).

Je n'ai même jamais essayé cela, pour des raisons évidentes et vous non plus.

Roy Prins
la source
12

Nous utilisons strip-json-commentspour notre projet. Il prend en charge quelque chose comme:

/*
 * Description 
*/
{
    // rainbows
    "unicorn": /* ❤ */ "cake"
}

Il suffit npm install --save strip-json-commentsde l'installer et de l'utiliser comme:

var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}
Joie
la source
Notez que le jsonn'est plus un JSON valide lorsqu'il inclut ces commentaires de propriété.
Roy Prins
12

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 ;-) ");

Entrez la description de l'image ici

WilliamK
la source
12

JSON n'autorise pas les commentaires en soi. Le raisonnement est complètement stupide, car vous pouvez utiliser JSON lui-même pour créer des commentaires, ce qui évite complètement le raisonnement et charge l'espace de données de l'analyseur sans aucune bonne raison pour exactement le même résultat et les problèmes potentiels, tels qu'ils sont: un JSON fichier avec commentaires.

Si vous essayez de mettre des commentaires (en utilisant //ou /* */ou #par exemple), certains analyseurs échoueront car cela ne fait strictement pas partie de la spécification JSON. Vous ne devriez donc jamais faire ça.

Voici un exemple, où mon système de manipulation d'image a enregistré des notations d'image et des informations formatées (commentaires) de base 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."
    }
}
fyngyrz
la source
Le lien "raisonnement" est rompu. Avez-vous une chance de trouver un lien actuel vers celui-ci?
Don Hatch
Don, malheureusement, Google a tué le système de médias sociaux qui contenait le message; Je ne sais pas où l'affiche originale est partie de là, si nulle part. Je tuerai le lien dans les informations ci-dessus, afin de lever l'ambiguïté. Merci.
fyngyrz
Le raisonnement n'est pas stupide, et vous venez de le prouver. L'implémentation de commentaires sous forme de balises préserve l' interopérabilité . C'est exactement pourquoi Crockford voulait que les commentaires soient analysés en tant que balises. Maintenant, tout est juste une balise et analysé de la même manière .
Dominic Cerisano
Si la spécification indiquait qu '"une ligne commençant par # est un commentaire", alors cela serait entièrement interopérable. Dans l'état actuel des choses, les commentaires chargent tous deux l'espace de l'analyseur, car ce sont des éléments analysés valides plutôt que des commentaires, et ils peuvent être différents pour chaque fichier .json existant. Alors que si (par exemple) la spécification dit "les lignes commençant par # sont des commentaires", alors les analyseurs pourraient ignorer ces lignes sans analyse (plus rapide) et ne pas charger l'espace de l'analyseur (meilleure utilisation de la mémoire.) Il n'y a aucun avantage du tout à l'absence des commentaires en .json, seuls inconvénients.
fyngyrz
11

Pour couper un élément JSON en parties, j'ajoute des lignes de "commentaire factice":

{

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

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

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

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

}
Chris
la source
15
Vous avez émulé une structure de fichiers INI en JSON. S'il vous plaît, posez votre Golden Hammer.
Artur Czajka
4
RFC dit "Les noms dans un objet DEVRAIENT être uniques". Voir également cette personne qui a une erreur d'analyse JSON comme ci-dessus: stackoverflow.com/questions/4912386/…
William Entriken
Si vous utilisez un schéma pour valider le JSON, il peut échouer en raison des champs supplémentaires.
gregsdennis
1
Si vous êtes vraiment déterminé à ajouter des commentaires à votre JSON, il serait beaucoup plus logique de faire quelque chose comme ceci: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } cela conserve le nom unique et vous permet d'ajouter la valeur de chaîne que vous souhaitez. C'est toujours un coup de foudre, car les commentaires ne doivent pas faire partie de votre JSON. Comme autre alternative, pourquoi ne pas ajouter des commentaires avant ou après votre JSON, mais pas en son sein?
Jazimov