I commenti possono essere utilizzati in JSON?

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

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, in quanto 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"
            }
         }
      }
   }
}

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 8259 Formato di interscambio di dati JSON (JavaScript Object Notation) (sostituisce gli RFC 4627, 7158, 7159)

Includi commenti se lo desideri; rimuoverli 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 rende valido JSON che può essere analizzato. Quindi, potresti usarlo come:

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

Quando l'ho pubblicato, 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 abbiano un senso in JSON . Include questo notevole commento del creatore di JSON:

Supponiamo che tu stia utilizzando 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.

Supponiamo che tu stia utilizzando 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.

Fonte: dichiarazione pubblica di Douglas Crockford su G +

DISCLAIMER: LA TUA GARANZIA È NULLA

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, soffocano.

È una curiosità interessante, ma non dovresti davvero usarlo per niente . 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]
}

Ciò 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 progettato per essere utilizzato per i 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 #.

Prendi in considerazione 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.

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 .

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

Esempio:

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

È possibile fornire documentazione utilizzando l' attributo dello schema di descrizione .

Se stai usando Jackson come parser JSON, ecco come abilitarlo 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 #impostando:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Ma in generale (come già detto in precedenza) la specifica non consente commenti.

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

NO . 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 è su 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 la relazione "has-a" dell'orientamento agli oggetti 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 istruttivi 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 importa se i tuoi dati persistenti possono essere facilmente analizzati.

MA come ha osservato anche il creatore di JSON, c'è sempre stato il supporto della pipeline JS per i commenti:

Vai avanti e inserisci tutti i commenti che ti piacciono. Quindi reindirizzalo attraverso JSMin prima di passarlo al tuo parser JSON. - Douglas Crockford, 2012

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 fodera. 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: utilizzo 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" piuttosto che creare un file "settings.README" separato e spiegare le impostazioni in esso.

Se hai un problema 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 i 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 in modo specifico dal codice di analisi.

Detto questo, 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.

Ho appena riscontrato questo per i file di configurazione. Non voglio usare il formato XML (dettagliato, graficamente, brutto, difficile da leggere) o "ini" (nessuna gerarchia, nessuno standard reale, ecc.) O il formato "Proprietà" Java (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 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 JSON "valido".

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 la tua applicazione dovrebbe elaborare 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. Ecco a cosa serve JSON.

Cf: Douglas Crockford, autore delle specifiche JSON .

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

Vedi un'altra domanda Stack Overflow .

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 validi motivi per non avere commenti in JSON durante la comunicazione dei dati (validi o meno), probabilmente JSON potrebbe essere diviso in due:

• JSON-COM: JSON sul cavo o regole applicabili quando si comunicano 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 l' osservazione fatta da Douglas Crockford su questi temi (a cui fa riferimento @Artur Czajka)

Supponiamo che tu stia utilizzando 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.

Stiamo parlando di un problema di file di configurazione generico (cross-language / platform) e sta rispondendo con un'utilità specifica di JS!

Sicuramente un minify specifico per JSON può essere implementato in qualsiasi lingua, ma standardizzalo in modo che diventi onnipresente tra parser in tutte le lingue e piattaforme in modo che le persone smettano di perdere tempo senza la funzione perché hanno buoni casi d'uso per esso, cercando il problema in forum online e convincere le persone a dire loro che è una cattiva idea o che suggerisce che è facile implementare i commenti eliminando i 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 è accessibile da diverse lingue. Poi vai a dire alle persone: a proposito, non dimenticare di eliminare i commenti dai file JSON prima di passarli al parser!

Se si utilizza JSON5 è possibile includere commenti.

JSON5 è un'estensione proposta a JSON che mira a rendere più semplice la scrittura e la manutenzione da parte degli esseri umani. Lo fa aggiungendo alcune funzionalità minime di sintassi direttamente da ECMAScript 5.

Il toolkit JavaScript Dojo Toolkit (almeno dalla versione 1.4), consente di includere commenti nel proprio JSON. I commenti possono essere di /* */formato. Dojo Toolkit utilizza JSON tramite la dojo.xhrGet()chiamata.

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.

JSON non è un protocollo con frame . È 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 _commentche è possibile utilizzare. Tocca a voi.

È possibile 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 ci sono stati problemi con la politica della stessa origine , quindi ho deciso di utilizzare JSON puro ... e, naturalmente, $.getJSONnon riuscivo silenziosamente a causa dei commenti.

Alla fine ho appena inviato una richiesta HTTP manuale all'indirizzo sopra e mi sono reso conto che il tipo di contenuto era text/javascriptpoiché, beh, JSONP restituiva JavaScript puro. In questo caso sono ammessi commenti . Ma la mia applicazione ha restituito un tipo di contenuto application/json, quindi ho dovuto rimuovere i commenti.

Questa è una domanda "puoi" . Ed ecco una risposta "si" .

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 DOVREBBERO essere univoci" nell'RFC ).

E sì, è possibile inserire commenti intorno a JSON , che è possibile 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 "Gli spazi bianchi sono consentiti prima o dopo uno dei sei caratteri strutturali".

^* L'RFC afferma solo "gli spazi bianchi sono consentiti prima o dopo uno dei sei caratteri strutturali", senza menzionare esplicitamente stringhe, numeri, "false", "true" 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 metti il ​​tuo binario:

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

Ecco il tuo output:

$jsonWithComment = $steg . $jsonMin;

DISCLAIMER: QUESTO È SILLY

Esiste effettivamente un modo per aggiungere commenti e rimanere all'interno delle specifiche (non è necessario alcun parser aggiuntivo). Non si tradurrà in commenti leggibili dall'uomo senza alcun tipo di analisi.

Potresti abusare di quanto segue:

Gli spazi bianchi insignificanti sono consentiti prima o dopo qualsiasi token. Lo spazio bianco è una sequenza di uno o più dei seguenti punti di codice: tabulazione dei caratteri (U + 0009), avanzamento riga (U + 000A), ritorno a capo (U + 000D) e spazio (U + 0020).

In un modo confuso, puoi abusare di questo per aggiungere un commento. Ad esempio: inizia e termina il tuo commento con una scheda. Codifica il commento in base3 e usa gli altri spazi bianchi per rappresentarli. Per esempio.

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

( hello base threein ASCII) Ma invece di 0 usa lo spazio, per 1 usa l'avanzamento di riga e per 2 usa il ritorno a capo.

Questo ti lascerà con molto spazio bianco illeggibile (a meno che tu non abbia creato un plug-in IDE per codificarlo / decodificarlo al volo).

Non l'ho mai provato, per ovvi motivi e nemmeno tu.

Stiamo usando strip-json-commentsper il nostro progetto. Supporta qualcosa di simile:

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

Basta npm install --save strip-json-commentsinstallarlo e usarlo come:

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

Nel mio caso, ho bisogno di usare i commenti per scopi di debug, prima dell'output della struttura JSON. Quindi ho deciso di utilizzare le informazioni di debug nell'intestazione HTTP, per evitare di interrompere il client:

header("My-Json-Comment: Yes, I know it's a workaround ;-) ");

JSON non consente commenti di per sé. Il ragionamento è assolutamente folle, perché è possibile utilizzare JSON stesso per creare commenti, il che elimina completamente il ragionamento e carica lo spazio dati del parser senza una buona ragione per esattamente lo stesso risultato e potenziali problemi, come ad esempio: un JSON file con commenti.

Se si tenta di inserire commenti (usando //o /* */o #per esempio), alcuni parser falliranno perché ciò non rientra strettamente nelle specifiche JSON. Quindi non dovresti mai farlo.

Ecco un esempio, in cui il mio sistema di manipolazione delle immagini ha salvato le notazioni delle immagini e alcune informazioni di base (commenti) relative ad esse (in basso):

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

Per tagliare un elemento JSON in parti aggiungo le righe "commento fittizio":

{

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

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

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

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

}