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

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

Non.

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

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)

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.

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 +

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!

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.

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

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

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.

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 .

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 .

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.

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

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

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.

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.

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.

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

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 .

Cela dépend de votre bibliothèque JSON. Json.NET soutient les commentaires de style JavaScript, /* commment */.

Voir une autre question Stack Overflow .

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!

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.

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.

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.

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.

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;

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.

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

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

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

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"

}