I commenti possono essere usati in JSON?

Posso usare commenti all’interno di un file JSON? Se é cosi, come?

No.

I JSON dovrebbero essere tutti dati e, se includi un commento, saranno anche i dati.

Potresti avere un elemento dati designato chiamato "_comment" (o qualcosa) che verrebbe ignorato dalle app che usano i dati JSON.

Probabilmente sarebbe meglio avere il commento nei processi che genera / riceve il JSON, poiché si suppone che sappiano quali saranno i dati JSON in anticipo o almeno la loro struttura.

Ma se hai deciso di:

 { "_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" } } } } } 

No , i commenti del modulo //… o /*…*/ non sono consentiti in JSON. Questa risposta è basata su:

  • http://www.json.org
  • RFC 4627 : L’ application/json Media Type per JavaScript Object Notation (JSON)
  • RFC 7159 Formato di interscambio dati JSON (JavaScript Object Notation) – Obsoletes: 4627, 7158

Includere i commenti se si sceglie; spogliarli con un minificatore prima di analizzare o trasmettere.

Ho appena rilasciato JSON.minify () che rimuove i commenti e gli spazi bianchi da un blocco di JSON e lo rende JSON valido che può essere analizzato. Quindi, potresti usarlo come:

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

Quando l’ho rilasciato, ho avuto un enorme contraccolpo di persone che non erano d’accordo nemmeno con l’idea, quindi ho deciso di scrivere un post completo sul perché i commenti hanno senso in JSON . Include questo commento notevole del creatore di JSON:

Supponiamo che tu stia usando JSON per mantenere i file di configurazione, che vorresti annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi collegalo a JSMin prima di passarlo al parser JSON. – Douglas Crockford, 2012

Speriamo che questo sia utile a coloro che non sono d’accordo sul perché JSON.minify () potrebbe essere utile.

I commenti sono stati rimossi da JSON in base alla progettazione.

Ho rimosso i commenti da JSON perché vedevo che le persone li utilizzavano per contenere direttive di analisi, una pratica che avrebbe distrutto l’interoperabilità. So che la mancanza di commenti rende alcune persone tristi, ma non dovrebbe.

Supponiamo che tu stia usando JSON per mantenere i file di configurazione, che vorresti annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi collegalo a JSMin prima di passarlo al parser JSON.

Fonte: dichiarazione pubblica di Douglas Crockford su G +

DICHIARAZIONE DI NON RESPONSABILITÀ: LA VOSTRA GARANZIA È ANNULLATA

Come è stato sottolineato, questo hack sfrutta l’implementazione delle specifiche. Non tutti i parser JSON comprenderanno questo tipo di JSON. In particolare i parser di streaming soffocheranno.

È una curiosità interessante, ma non dovresti davvero usarla per niente . Di seguito è la risposta originale.


Ho trovato un piccolo trucco che consente di inserire commenti in un file JSON che non influirà sull’analisi o alterare i dati rappresentati in alcun modo.

Sembra che quando si dichiara un object letterale è ansible specificare due valori con la stessa chiave, e l’ultimo ha la precedenza. Che ci crediate o no, risulta che i parser JSON funzionano allo stesso modo. Quindi possiamo usarlo per creare commenti nel JSON di origine che non sarà presente in una rappresentazione object parsed.

 ({a: 1, a: 2}); // => Object {a: 2} Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; // => 1 

Se applichiamo questa tecnica, il tuo file JSON commentato potrebbe assomigliare a questo:

 { "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] } 

Il codice sopra è JSON valido . Se lo analizzi, otterrai un object come questo:

 { "api_host": "hodorhodor.com", "retry_interval": 10, "auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b", "favorite_numbers": [19,13,53] } 

Il che significa che non c’è traccia dei commenti e che non avranno effetti collaterali strani.

Happy hacking!

JSON non supporta i commenti. Inoltre, non è mai stato concepito per i file di configurazione in cui sarebbero necessari commenti.

Hjson è un formato di file di configurazione per gli esseri umani. Sintassi rilassata, meno errori, più commenti.

Intro Hjson

Vedi hjson.org per le librerie JavaScript, Java, Python, PHP, Rust, Go, Ruby e C #.

Non puoi Almeno questa è la mia esperienza da una rapida occhiata a json.org .

JSON ha la sua syntax visualizzata su quella pagina. Non c’è nessuna nota sui commenti.

Prendi in considerazione l’utilizzo di YAML. È quasi un superset di JSON (praticamente tutto JSON valido è YAML valido) e consente commenti.

Dovresti invece scrivere uno schema JSON . Lo schema JSON è attualmente una proposta di bozza di specifiche Internet. Oltre alla documentazione, lo schema può essere utilizzato anche per convalidare i dati JSON.

Esempio:

 { "description":"A person", "type":"object", "properties": { "name": { "type":"string" }, "age": { "type":"integer", "maximum":125 } } } 

È ansible fornire documentazione utilizzando l’attributo dello schema di descrizione .

Se stai usando Jackson come parser JSON, questo è il modo in cui lo abiliti per consentire i commenti:

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

Quindi puoi avere commenti come questo:

 { key: "value" // comment } 

E puoi anche avere commenti che iniziano con # impostando:

 mapper.configure(Feature.ALLOW_YAML_COMMENTS, true); 

Ma in generale (come risposta prima) la specifica non consente commenti.

I commenti non sono uno standard ufficiale. Sebbene alcuni parser supportino i commenti in stile C. Uno che uso è JsonCpp . Negli esempi c’è questo:

 // 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 non convalida questo. Quindi i commenti sono un’estensione specifica del parser e non standard.

Un altro parser è JSON5 .

Un’alternativa a JSON TOML .

Spiacenti, non possiamo usare commenti in JSON … Vedi il diagramma di syntax per JSON su JSON.org .

Douglas Crockford dice ” perché ha rimosso i commenti in JSON e fornendo un modo alternativo per farlo “:

Ho rimosso i commenti da JSON perché vedevo che le persone li utilizzavano per contenere direttive di analisi, una pratica che avrebbe distrutto l’interoperabilità. So che la mancanza di commenti rende alcune persone tristi, ma non dovrebbe.

Supponiamo che tu stia usando JSON per mantenere i file di configurazione, che vorresti annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi collegalo a JSMin prima di passarlo al parser JSON.

Ecco cosa ho trovato nella documentazione di Google Firebase che ti consente di inserire commenti in 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" } 

Se il tuo file di testo, che è una stringa JSON, verrà letto da qualche programma, quanto sarebbe difficile rimuovere i commenti in stile C o C ++ prima di usarlo?

Risposta: Sarebbe un solo rivestimento. Se lo fai, allora i file JSON potrebbero essere usati come file di configurazione.

Se si utilizza la libreria Newtonsoft.Json con ASP.NET per leggere / deserializzare, è ansible utilizzare i commenti nel contenuto JSON:

// “nome”: “stringa”

// “id”: int

o

/* Questo è un

esempio di commento * /

PS: i commenti a riga singola sono supportati solo con le versioni 6+ di Newtonsoft Json.

Nota aggiuntiva per le persone che non riescono a pensare fuori dagli schemi: utilizzo il formato JSON per le impostazioni di base in un’applicazione Web ASP.NET che ho creato. Ho letto il file, convertito nell’object impostazioni con la libreria Newtonsoft e lo uso quando necessario.

Preferisco scrivere commenti su ogni singola impostazione nel file JSON stesso, e non mi interessa davvero l’integrità del formato JSON finché la libreria che uso è OK con esso.

Penso che questo sia un modo “più facile da usare / capire” rispetto alla creazione di un file separato “settings.README” e che spieghi le impostazioni in esso contenute.

Se hai un problema con questo tipo di utilizzo; scusa, il genio è fuori dalla lampada. Le persone potrebbero trovare altri usi per il formato JSON e non c’è nulla che tu possa fare al riguardo.

L’idea alla base di JSON è quella di fornire un semplice scambio di dati tra le applicazioni. Questi sono in genere basati sul Web e la lingua è JavaScript.

In realtà non consente commenti in quanto tali, tuttavia, il passaggio di un commento come una delle coppie nome / valore nei dati funzionerebbe sicuramente, anche se i dati avrebbero ovviamente bisogno di essere ignorati o gestiti in modo specifico dal codice di analisi.

Detto questo, non è intenzione che il file JSON contenga commenti nel senso tradizionale. Dovrebbero essere solo i dati.

Dai un’occhiata al sito web JSON per maggiori dettagli.

JSON non supporta i commenti in modo nativo, ma è ansible creare il proprio decodificatore o almeno il preprocessore per eliminare i commenti, ciò è perfettamente corretto (basta che ignori i commenti e non li usi per guidare il modo in cui l’applicazione deve elaborare i dati JSON ).

JSON non ha commenti. Un codificatore JSON NON DEVE inviare commenti. Un decodificatore JSON PU MAY accettare e ignorare i commenti.

I commenti non dovrebbero mai essere usati per trasmettere qualcosa di significativo. Ecco a cosa serve JSON.

Cfr: Douglas Crockford, autore di JSON spec .

Ho appena incontrato questo per i file di configurazione. Non voglio usare il formato XML (verboso, graficamente, brutto, difficile da leggere), o “ini” (nessuna gerarchia, nessun vero standard, ecc.) O Java “Proprietà” (come .ini).

JSON può fare tutto ciò che può fare, ma è molto meno prolisso e più leggibile dall’uomo – e i parser sono facili e onnipresenti in molte lingue. È solo un albero di dati. Ma i commenti fuori banda sono spesso necessari per documentare configurazioni “predefinite” e simili. Le configurazioni non devono mai essere “documenti completi”, ma alberi di dati salvati che possono essere leggibili dall’uomo quando necessario.

Immagino che si possa usare "#": "comment" , per “valido” JSON.

Dipende dalla tua libreria JSON. Json.NET supporta i commenti in stile JavaScript, /* commment */ .

Vedi un’altra domanda di overflow dello stack .

JSON ha molto senso per i file di configurazione e altri usi locali perché è onnipresente e perché è molto più semplice di XML.

If people have strong reasons against having comments in JSON when communicating data (whether valid or not), then possibly JSON could be split into two:

  • JSON-COM: JSON on the wire, or rules that apply when communicating JSON data.
  • JSON-DOC: JSON document, or JSON in files or locally. Rules that define a valid JSON document.

JSON-DOC will allow comments, and other minor differences might exist such as handling whitespace. Parsers can easily convert from one spec to the other.

With regards to the remark made by Douglas Crockford on this issues (referenced by @Artur Czajka)

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

We’re talking about a generic config file issue (cross language/platform), and he’s answering with a JS specific utility!

Sure a JSON specific minify can be implemented in any language, but standardize this so it becomes ubiquitous across parsers in all languages and platforms so people stop wasting their time lacking the feature because they have good use-cases for it, looking the issue up in online forums, and getting people telling them it’s a bad idea or suggesting it’s easy to implement stripping comments out of text files.

The other issue is interoperability. Suppose you have a library or API or any kind of subsystem which has some config or data files associated with it. And this subsystem is to be accessed from different languages. Then do you go about telling people: by the way don’t forget to strip out the comments from the JSON files before passing them to the parser!

The Dojo Toolkit JavaScript toolkit (at least as of version 1.4), allows you to include comments in your JSON. The comments can be of /* */ format. Dojo Toolkit consumes the JSON via the dojo.xhrGet() call.

Other JavaScript toolkits may work similarly.

This can be helpful when experimenting with alternate data structures (or even data lists) before choosing a final option.

If you use JSON5 you can include comments.


JSON5 is a proposed extension to JSON that aims to make it easier for humans to write and maintain by hand. It does this by adding some minimal syntax features directly from ECMAScript 5.

You can have comments in JSONP , but not in pure JSON. I’ve just spent an hour trying to make my program work with this example from Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

If you follow the link, you will see

 ?(/* AAPL historical OHLC data from the Google Finance API */ [ /* May 2006 */ [1147651200000,67.79], [1147737600000,64.98], ... [1368057600000,456.77], [1368144000000,452.97] ]); 

Since I had a similar file in my local folder, there were no issues with the Same-origin policy , so I decided to use pure JSON… and, of course, $.getJSON was failing silently because of the comments.

Eventually I just sent a manual HTTP request to the address above and realized that the content-type was text/javascript since, well, JSONP returns pure JavaScript. In this case comments are allowed . But my application returned content-type application/json , so I had to remove the comments.

JSON is not a framed protocol . It is a language free format . So a comment’s format is not defined for JSON.

As many people have suggested, there are some tricks, for example, duplicate keys or a specific key _comment that you can use. It’s up to you.

This is a “can you” question. And here is a “yes” answer.

No, you shouldn’t use duplicative object members to stuff side channel data into a JSON encoding. (See “The names within an object SHOULD be unique” in the RFC ).

And yes, you could insert comments around the JSON , which you could parse out.

But if you want a way of inserting and extracting arbitrary side-channel data to a valid JSON, here is an answer. We take advantage of the non-unique representation of data in a JSON encoding. This is allowed * in section two of the RFC under “whitespace is allowed before or after any of the six structural characters”.

* The RFC only states “whitespace is allowed before or after any of the six structural characters”, not explicitly mentioning strings, numbers, “false”, “true”, and “null”. This omission is ignored in ALL implementations.


First, canonicalize your JSON by minifying it:

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

Then encode your comment in binary:

 $hex = unpack('H*', $comment); $commentBinary = base_convert($hex[1], 16, 2); 

Then steg your binary:

 $steg = str_replace('0', ' ', $commentBinary); $steg = str_replace('1', "\t", $steg); 

Here is your output:

 $jsonWithComment = $steg . $jsonMin; 

We are using strip-json-comments for our project. It supports something like:

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

Simply npm install --save strip-json-comments to install and use it like:

 var strip_json_comments = require('strip-json-comments') var json = '{/*rainbows*/"unicorn":"cake"}'; JSON.parse(strip_json_comments(json)); //=> {unicorn: 'cake'} 

There is a good solution (hack), which is valid JSON. Just make the same key twice (or more). Per esempio:

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

So JSON will understand this as:

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

To cut a JSON item into parts I add “dummy comment” lines:

 { "#############################" : "Part1", "data1" : "value1", "data2" : "value2", "#############################" : "Part2", "data4" : "value3", "data3" : "value4" } 

The author of JSON wants us to include comments in the JSON, but strip them out before parsing them (see link provided by Michael Burr.) If JSON should have comments, why not standardize them, and let the JSON parser do the job? I don’t agree with the logic there, but, alas, that’s the standard. Using YAML solution as suggested by others is good, but requires library dependency.

If you want to strip out comments, but don’t want to have a library dependency, here is a two-line solution, which works for C++-style comments, but can be adapted to others:

 var comments=new RegExp("//.*", 'mg'); data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, '')); 

Note that this solution can only be used in cases where you can be sure that the JSON data does not contain the comment initiator, eg (‘//’).

Another way to achieve JSON parsing, stripping of comments, and no extra library, is to evaluate the JSON in a JS interpreter. The caveat with that approach, of course, is that you would only want to evaluate untainted data (no untrusted user-input.) Here is an example of this approach in node.js — another caveat, following example will only read the data once and then it will be cached:

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

You can use JSON with comments in it, if you load it as a text file, and then remove comments from it.

You can use decomment library for that. Below is a complete example.

Input JSON (file 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); } }); 

Produzione:

 { value: 123 } 

See also: gulp-decomment , grunt-decomment