I commenti possono essere utilizzati in JSON?
https://stackoverflow.com/questions/244777
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Posso usare i commenti all'interno di un file JSON? In tal caso, come?
Soluzione
No.
I JSON dovrebbero essere tutti dati, e se includi un commento, anche questi saranno dati.
Potresti avere un elemento di dati designato chiamato " _comment " (o qualcosa del genere) che verrebbe ignorato dalle app che utilizzano i dati JSON.
Probabilmente sarebbe meglio avere il commento nei processi che generano / ricevono il JSON, poiché dovrebbero sapere 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"
}
}
}
}
}
Altri suggerimenti
No , i commenti del modulo //… o / *… * / non sono consentiti in JSON. Questa risposta si basa su:
- http://www.json.org
- RFC 4627 :
Il
application / jsonTipo di supporto per JavaScript Object Notation (JSON) - RFC 7159 Formato di scambio dati JSON (JavaScript Object Notation) - Obsoletes: 4627 , 7158
Includi commenti se lo desideri; eliminali con un minificatore prima di analizzare o trasmettere.
Ho appena rilasciato JSON.minify () che rimuove commenti e spazi bianchi da un blocco di JSON e rende valido JSON 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 in disaccordo con l'idea, quindi ho deciso di scrivere un post sul blog completo sul perché i commenti hanno senso in JSON . Include questo notevole commento del creatore di JSON:
Supponi di utilizzare JSON per conservare i file di configurazione, che desideri annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi reindirizzalo attraverso JSMin prima di passarlo al tuo parser JSON. - Douglas Crockford, 2012
Speriamo che sia utile a coloro che non sono d'accordo con il motivo per cui JSON.minify () potrebbe essere utile.
I commenti sono stati rimossi da JSON in base alla progettazione.
Ho rimosso i commenti da JSON perché ho visto che le persone li stavano usando per tenere direttive di analisi, una pratica che avrebbe distrutto l'interoperabilità. So che la mancanza di commenti rende alcune persone tristi, ma non dovrebbe.
Supponi di utilizzare JSON per conservare i file di configurazione, che desideri annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi instradalo attraverso JSMin prima di passarlo al tuo parser JSON.
ESCLUSIONE DI RESPONSABILITÀ: LA VOSTRA GARANZIA È VUOTA
Come è stato sottolineato, questo trucco sfrutta l'implementazione delle specifiche. Non tutti i parser JSON capiranno questo tipo di JSON. I parser in streaming, in particolare, si strozzeranno.
È una curiosità interessante, ma tu non dovresti davvero usarlo per nulla . Di seguito è la risposta originale.
Ho trovato un piccolo trucco che ti 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 oggetto letterale è possibile specificare due valori con la stessa chiave e l'ultimo ha la precedenza. Che ci crediate o no, si scopre che i parser JSON funzionano allo stesso modo. Quindi possiamo usarlo per creare commenti nel JSON di origine che non saranno presenti in una rappresentazione di oggetto analizzata.
({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 apparire così:
{
"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 oggetto come questo:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": [19,13,53]
}
Il che significa che non ci sono tracce dei commenti e che non avranno strani effetti collaterali.
Happy hacking!
JSON non supporta i commenti. Inoltre, non è mai stato utilizzato per file di configurazione in cui sarebbero necessari commenti.
Hjson è un formato di file di configurazione per l'uomo. Sintassi rilassata, meno errori, più commenti.
Vedi hjson.org per le librerie JavaScript, Java, Python, PHP, Rust, Go, Ruby e C #.
Valuta l'utilizzo di YAML. È quasi un superset di JSON (praticamente tutto JSON valido è YAML valido) e consente commenti.
Non puoi. Almeno questa è la mia esperienza da una rapida occhiata a json.org .
JSON ha la sua sintassi visualizzata su quella pagina. Non ci sono note sui commenti.
Dovresti invece scrivere un schema JSON . Lo schema JSON è attualmente una proposta di bozza di Internet proposta. Oltre alla documentazione, lo schema può anche essere utilizzato per la convalida dei dati JSON.
Esempio:
{
"description":"A person",
"type":"object",
"properties":
{
"name":
{
"type":"string"
},
"age":
{
"type":"integer",
"maximum":125
}
}
}
Puoi fornire documentazione utilizzando l'attributo dello schema descrizione .
Se si utilizza Jackson come parser JSON, è così che si abilita 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 già detto in precedenza) 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 lo convalida. Quindi i commenti sono un'estensione specifica del parser e non standard.
Un altro parser è JSON5 .
Un'alternativa a JSON TOML .
Un'ulteriore alternativa è jsonc .
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 una riga. In tal caso, i file JSON potrebbero essere utilizzati come file di configurazione.
Se si utilizza la libreria Newtonsoft.Json con ASP.NET per leggere / deserializzare, è possibile utilizzare i commenti nel contenuto JSON:
// " name " ;: " string "
// " id " ;: int
o
/ * Questo è un
esempio di commento * /
PS: i commenti a riga singola sono supportati solo con oltre 6 versioni di Newtonsoft Json.
Nota aggiuntiva per le persone che non riescono a pensare fuori dagli schemi: Uso il formato JSON per le impostazioni di base in un'applicazione Web ASP.NET che ho creato. Ho letto il file, lo converto nell'oggetto settings con la libreria Newtonsoft e lo utilizzo quando necessario.
Preferisco scrivere commenti su ogni singola impostazione nel file JSON stesso, e non mi interessa davvero l'integrità del formato JSON purché la libreria che uso sia OK con esso.
Penso che questo sia un modo "più facile da usare / comprendere" rispetto alla creazione di un file separato "settings.README" e alla spiegazione delle impostazioni in esso.
In caso di problemi con questo tipo di utilizzo; scusa, il genio è fuori dalla lampada. Le persone troverebbero altri usi per il formato JSON e non c'è niente che tu possa fare al riguardo.
L'idea alla base di JSON è quella di fornire un semplice scambio di dati tra applicazioni. Questi sono in genere basati sul Web e la lingua è JavaScript.
In realtà non consente commenti in quanto tali, tuttavia, passare un commento in quanto una delle coppie nome / valore nei dati funzionerebbe sicuramente, sebbene quei dati debbano ovviamente essere ignorati o gestiti specificamente dal codice di analisi .
Detto ciò, non è intenzione che il file JSON contenga commenti in senso tradizionale. Dovrebbero essere solo i dati.
Dai un'occhiata al sito web JSON per maggiori dettagli.
L'ho appena riscontrato per i file di configurazione. Non voglio usare XML (dettagliato, graficamente, brutto, difficile da leggere) o "quot" ini " formato (nessuna gerarchia, nessuno standard reale, ecc.) o Java "Proprietà" formato (come .ini).
JSON può fare tutto ciò che può fare, ma è molto meno dettagliato 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 una necessità per documentare "default". configurazioni e simili. Le configurazioni non devono mai essere "documenti completi", ma alberi di dati salvati che possono essere leggibili dall'uomo quando necessario.
Suppongo che si potrebbe usare " # " ;: " comment " , per " valido " JSON.
JSON non supporta i commenti in modo nativo, ma puoi creare il tuo decodificatore o almeno un preprocessore per eliminare i commenti, va benissimo (basta che ignori i commenti e non li usi per guidare come deve essere elaborata la tua domanda i dati JSON).
JSON non ha commenti. Un codificatore JSON NON DEVE generare commenti. Un decodificatore JSON PUO 'accettare e ignorare i commenti.
I commenti non devono mai essere usati per trasmettere qualcosa di significativo. Questo è a cosa serve JSON.
Dipende dalla tua libreria JSON. Json.NET supporta commenti in stile JavaScript, / * commment * / .
JSON ha molto senso per i file di configurazione e altri usi locali perché è onnipresente e perché è molto più semplice di XML.
Se le persone hanno forti ragioni per non avere commenti in JSON quando comunicano dati (validi o meno), allora JSON potrebbe essere diviso in due:
- JSON-COM: JSON sulla rete o regole applicabili durante la comunicazione dei dati JSON.
- JSON-DOC: documento JSON o JSON in file o localmente. Regole che definiscono un documento JSON valido.
JSON-DOC consentirà commenti e potrebbero esistere altre differenze minori come la gestione degli spazi bianchi. I parser possono facilmente convertire da una specifica all'altra.
Per quanto riguarda la osservazione fatta da Douglas Crockford su questi temi (a cui fa riferimento @Artur Czajka)
Supponi di utilizzare JSON per conservare i file di configurazione, che desideri annotare. Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi instradalo attraverso JSMin prima di passarlo al tuo parser JSON.
Stiamo parlando di un problema di file di configurazione generico (cross-language / platform) e sta rispondendo con un'utilità specifica di JS!
Sicuramente un minimify specifico per JSON può essere implementato in qualsiasi lingua, ma standardizzalo in modo che diventi onnipresente tra i parser in tutte le lingue e piattaforme, quindi le persone smettono di sprecare il loro tempo senza la funzione perché hanno buoni casi d'uso per esso, cercano il problema nei forum online e fanno in modo che la gente dica loro che è una cattiva idea o suggerire che è facile implementare i commenti di rimozione dai file di testo.
L'altro problema è l'interoperabilità. Supponiamo di avere una libreria o API o qualsiasi tipo di sottosistema a cui siano associati alcuni file di configurazione o di dati. E questo sottosistema è a cui si può accedere da diverse lingue. Allora vai in giro a dire alla gente: a proposito non dimenticare di eliminare i commenti dai file JSON prima di passarli al parser!
Il toolkit JavaScript Dojo Toolkit (almeno dalla versione 1.4), consente di includere commenti nel proprio JSON. I commenti possono essere nel formato / * * / . Dojo Toolkit utilizza JSON tramite la chiamata dojo.xhrGet () .
Altri toolkit JavaScript potrebbero funzionare in modo simile.
Questo può essere utile quando si sperimenta strutture dati alternative (o persino elenchi di dati) prima di scegliere un'opzione finale.
Se si utilizza JSON5 è possibile includere commenti.
JSON5 è un'estensione proposta a JSON che ha lo scopo di facilitare la scrittura e la manutenzione a mano degli esseri umani. Lo fa aggiungendo alcune funzionalità minime di sintassi direttamente da ECMAScript & nbsp; 5.
JSON non è un protocollo incorniciato . È un formato senza lingua . Quindi il formato di un commento non è definito per JSON.
Come molte persone hanno suggerito, ci sono alcuni trucchi, ad esempio chiavi duplicate o una chiave specifica _comment che puoi usare. Dipende da te.
Puoi puoi avere commenti in JSONP , ma non in puro JSON. Ho appena trascorso un'ora a provare a far funzionare il mio programma con questo esempio tratto da Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Se segui il link, vedrai
?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Dato che avevo un file simile nella mia cartella locale, non c'erano problemi con Stessa origine politica , quindi ho deciso di utilizzare JSON puro ... e, naturalmente, $ .getJSON non funzionava silenziosamente a causa dei commenti.
Alla fine ho appena inviato una richiesta HTTP manuale all'indirizzo sopra e ho capito che il tipo di contenuto era text / javascript poiché, beh, JSONP restituiva puro JavaScript. In questo caso i commenti sono ammessi . Ma la mia applicazione ha restituito application / json di tipo contenuto, quindi ho dovuto rimuovere i commenti.
JSON era solito supportare i commenti, ma venivano abusati e rimossi dallo standard.
Dal creatore di JSON:
Ho rimosso i commenti da JSON perché ho visto che le persone li stavano usando per tenere direttive di analisi, una pratica che avrebbe distrutto l'interoperabilità. So che la mancanza di commenti rende alcune persone tristi, ma non dovrebbe. - Douglas Crockford, 2012
Il sito ufficiale JSON è all'indirizzo JSON.org . JSON è definito come standard da ECMA International. Esiste sempre una procedura di petizione per la revisione degli standard. È improbabile che le annotazioni vengano aggiunte allo standard JSON per diversi motivi.
JSON di progettazione è un'alternativa facilmente XML (parsed umana) all'XML. È semplificato al punto che le annotazioni non sono necessarie. Non è nemmeno un linguaggio di markup. L'obiettivo è la stabilità e l'interoperabilità.
Chiunque capisca il " has-a " la relazione di orientamento dell'oggetto può comprendere qualsiasi struttura JSON - questo è il punto. È solo un grafico aciclico diretto (DAG) con tag di nodo (coppie chiave / valore), che è una struttura di dati quasi universale.
Questa unica annotazione richiesta potrebbe essere " // Questi sono tag DAG " ;. I nomi delle chiavi possono essere tanto informativi quanto richiesto, consentendo un'arità semantica arbitraria.
Qualsiasi piattaforma può analizzare JSON con poche righe di codice. XML richiede librerie OO complesse che non sono praticabili su molte piattaforme.
Le annotazioni renderebbero JSON meno interoperabile. Non c'è nient'altro da aggiungere, a meno che ciò di cui hai veramente bisogno sia un linguaggio di markup (XML), e non ti importa se i tuoi dati persistenti possono essere facilmente analizzati.
Questa è una domanda " puoi " . Ed ecco una " sì " risposta.
No, non dovresti usare membri di oggetti duplicati per inserire i dati del canale laterale in una codifica JSON. (Vedi " I nomi all'interno di un oggetto DOVREBBE essere univoci " nella RFC ).
E sì, potresti inserire commenti in giro il JSON , che potrebbe analizzare.
Ma se vuoi un modo per inserire ed estrarre dati arbitrari sul canale laterale su un JSON valido, ecco una risposta. Sfruttiamo la rappresentazione non univoca dei dati in una codifica JSON. Questo è consentito * nella sezione due della RFC sotto "spazio bianco è consentito prima o dopo uno dei sei caratteri strutturali".
* L'RFC indica solo "gli spazi bianchi è consentito prima o dopo uno dei sei caratteri strutturali", senza menzionare esplicitamente stringhe, numeri, "quotazioni" false "," quotate " e "null". Questa omissione viene ignorata in TUTTE le implementazioni.
Innanzitutto, canonicalizza il tuo JSON minimizzandolo:
$jsonMin = json_encode(json_decode($json));
Quindi codifica il tuo commento in binario:
$hex = unpack('H*', $comment);
$commentBinary = base_convert($hex[1], 16, 2);
Quindi steg il tuo binario:
$steg = str_replace('0', ' ', $commentBinary);
$steg = str_replace('1', "\t", $steg);
Ecco il tuo output:
$jsonWithComment = $steg . $jsonMin;
Stiamo usando strip-json-commenti per il nostro progetto. Supporta qualcosa come:
/*
* Description
*/
{
// rainbows
"unicorn": /* ❤ */ "cake"
}
Semplicemente npm install --save strip-json-commenti per installarlo e usarlo come:
var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake"}';
JSON.parse(strip_json_comments(json));
//=> {unicorn: 'cake'}
Per tagliare un elemento JSON in parti aggiungo " commento fittizio " linee:
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
Esiste una buona soluzione (hack), che è valida JSON. Basta fare la stessa chiave due volte (o più). Ad esempio:
{
"param" : "This is the comment place",
"param" : "This is value place",
}
Quindi JSON lo capirà come:
{
"param" : "This is value place",
}
L'autore di JSON vuole che includiamo i commenti in JSON, ma li rimuoviamo prima di analizzarli (vedi link fornito da Michael Burr). Se JSON dovrebbe avere commenti, perché non standardizzarli e lasciare che il parser JSON faccia il lavoro? Non sono d'accordo con la logica lì, ma, ahimè, questo è lo standard. L'uso di una soluzione YAML come suggerito da altri è buono, ma richiede una dipendenza dalla libreria.
Se vuoi eliminare i commenti, ma non vuoi avere una dipendenza dalla libreria, ecco una soluzione a due righe, che funziona per i commenti in stile C ++, ma può essere adattata ad altri:
var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));
Nota che questa soluzione può essere utilizzata solo nei casi in cui puoi essere sicuro che i dati JSON non contengono l'iniziatore di commenti, ad es. ( '//').
Un altro modo per ottenere l'analisi JSON, lo stripping dei commenti e nessuna libreria aggiuntiva è quello di valutare JSON in un interprete JavaScript. L'avvertenza con questo approccio, ovviamente, è che vorresti solo valutare i dati non contaminati (nessun input dell'utente non attendibile). Ecco un esempio di questo approccio in Node.js - un altro avvertimento, il seguente esempio leggerà i dati solo una volta e poi verranno memorizzati nella cache:
data = require(fs.realpathSync(doctree_fp));
Sigh. Perché non aggiungere semplicemente campi, ad esempio
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
Assicurati solo che il tuo " notex " i nomi non sono in conflitto con nessun campo reale.
