Czy w JSON można używać komentarzy?

Czy mogę używać komentarzy w pliku JSON? Jeśli tak to jak?

Nie.

JSON powinien być danymi, a jeśli dodasz komentarz, to również będą to dane.

Możesz mieć wyznaczony element danych o nazwie "_comment"(lub coś takiego), który byłby ignorowany przez aplikacje korzystające z danych JSON.

Prawdopodobnie lepiej byłoby mieć komentarz w procesach, które generują / odbierają JSON, ponieważ powinni wiedzieć, jakie będą dane JSON z wyprzedzeniem lub przynajmniej jego struktura.

Ale jeśli zdecydujesz się:

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

Nie , komentarze do formularza //…lub /*…*/są zabronione w JSON. Ta odpowiedź jest oparta na:

• http://www.json.org
• RFC 4627 : Typ application/jsonnośnika dla JavaScript Object Notation (JSON)
• RFC 8259 Format wymiany danych JavaScript Object Notation (JSON) (zastępuje RFC 4627, 7158, 7159)

Dołącz komentarze, jeśli wybierzesz; usuń je za pomocą minifikatora przed parsowaniem lub przesyłaniem.

Właśnie wydałem JSON.minify (), która usuwa komentarze i białe znaki z bloku JSON i sprawia, że ​​jest to poprawny JSON, który można analizować. Możesz więc użyć go w następujący sposób:

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

Kiedy ją wydałem, spotkałem się z ogromną reakcją ludzi, którzy nie zgadzają się nawet z tym pomysłem, więc postanowiłem napisać obszerny post na blogu o tym, dlaczego komentarze mają sens w JSON . Zawiera ten znaczący komentarz twórcy JSON:

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz opatrzyć adnotacjami. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON. - Douglas Crockford, 2012

Mam nadzieję, że jest to pomocne dla tych, którzy nie zgadzają się z tym, dlaczego JSON.minify () może być przydatny.

Komentarze zostały usunięte z JSON zgodnie z projektem.

Usunąłem komentarze z JSON, ponieważ widziałem, jak ludzie używali ich do przechowywania parsujących dyrektyw, co zniszczyłoby interoperacyjność. Wiem, że brak komentarzy wywołuje u niektórych smutek, ale nie powinien.

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz opatrzyć adnotacjami. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON.

Źródło: publiczne oświadczenie Douglasa Crockforda w sprawie G +

WYŁĄCZENIE ODPOWIEDZIALNOŚCI: TWOJA GWARANCJA JEST USUNIĘTA

Jak już wspomniano, ten hack wykorzystuje implementację specyfikacji. Nie wszystkie parsery JSON zrozumieją tego rodzaju JSON. Parsery przesyłania strumieniowego w szczególności będą się dusić.

To ciekawa ciekawość, ale tak naprawdę nie powinieneś jej używać do niczego . Poniżej znajduje się oryginalna odpowiedź.

Znalazłem mały hack, który pozwala umieszczać komentarze w pliku JSON, które nie wpłyną na parsowanie, ani nie będą w żaden sposób zmieniać reprezentowanych danych.

Wygląda na to, że deklarując literał obiektu, możesz podać dwie wartości za pomocą tego samego klucza, a ostatnia ma pierwszeństwo. Wierzcie lub nie, okazuje się, że parsery JSON działają w ten sam sposób. Możemy więc użyć tego do stworzenia komentarzy w źródłowym JSON, które nie będą obecne w reprezentacji parsowanego obiektu.

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

Jeśli zastosujemy tę technikę, skomentowany plik JSON może wyglądać następująco:

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

Powyższy kod jest prawidłowym JSON . Jeśli go przeanalizujesz, otrzymasz taki obiekt:

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

Co oznacza, że ​​nie ma śladu komentarzy i nie będą miały dziwnych skutków ubocznych.

Miłego hakowania!

JSON nie obsługuje komentarzy. Nigdy nie był przeznaczony do użycia w plikach konfiguracyjnych, w których potrzebne byłyby komentarze.

Hjson to format pliku konfiguracyjnego dla ludzi. Zrelaksowana składnia, mniej błędów, więcej komentarzy.

Zobacz hjson.org dla bibliotek JavaScript, Java, Python, PHP, Rust, Go, Ruby i C #.

Rozważ użycie YAML. Jest to prawie nadzbiór JSON (praktycznie wszystkie poprawne JSON to poprawne YAML) i pozwala na komentarze.

Nie możesz Przynajmniej takie jest moje doświadczenie na pierwszy rzut oka na json.org .

JSON ma swoją wizualizację na tej stronie. Nie ma żadnych uwag na temat komentarzy.

Komentarze nie są oficjalnym standardem, chociaż niektóre parsery obsługują komentarze w stylu C ++. Jednym z nich jest JsonCpp . W przykładach jest ten:

// 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 tego nie sprawdza. Tak więc komentarze są rozszerzeniem specyficznym dla parsera, a nie standardem.

Kolejnym parserem jest JSON5 .

Alternatywa dla JSON TOML .

Kolejną alternatywą jest jsonc .

Zamiast tego powinieneś napisać schemat JSON . Schemat JSON jest obecnie proponowaną internetową specyfikacją wersji roboczej. Oprócz dokumentacji schematu można także użyć do sprawdzania poprawności danych JSON.

Przykład:

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

Możesz dostarczyć dokumentację, używając atrybutu schematu opisu .

Jeśli używasz Jacksona jako parsera JSON, włącz tę opcję, aby umożliwić komentarze:

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

Następnie możesz mieć takie komentarze:

{
  key: "value" // Comment
}

Możesz także dodawać komentarze, zaczynając #od:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Ale ogólnie (jak wcześniej odpowiedziano) specyfikacja nie pozwala na komentarze.

Oto, co znalazłem w dokumentacji Google Firebase, która pozwala na umieszczanie komentarzy w 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 wspierał komentarze, ale były one nadużywane i usuwane ze standardu.

Od twórcy JSON:

Usunąłem komentarze z JSON, ponieważ widziałem, jak ludzie używali ich do przechowywania parsujących dyrektyw, co zniszczyłoby interoperacyjność. Wiem, że brak komentarzy wywołuje u niektórych smutek, ale nie powinien. - Douglas Crockford, 2012

Oficjalna strona JSON znajduje się na JSON.org . JSON jest zdefiniowany jako standard przez ECMA International. Zawsze istnieje proces składania petycji w celu zmiany standardów. Jest mało prawdopodobne, że adnotacje zostaną dodane do standardu JSON z kilku powodów.

JSON z założenia jest łatwą do inżynierii wstecznej (analizowaną przez człowieka) alternatywą dla XML. Uproszczono nawet do tego stopnia, że ​​adnotacje są niepotrzebne. To nawet nie jest język znaczników. Celem jest stabilność i interoperacyjność.

Każdy, kto rozumie relację orientacji obiektowej „ma-a”, może zrozumieć każdą strukturę JSON - o to właśnie chodzi. Jest to po prostu ukierunkowany wykres acykliczny (DAG) ze znacznikami węzłów (pary klucz / wartość), który jest prawie uniwersalną strukturą danych.

Wymagana jest tylko adnotacja „// To są tagi DAG”. Kluczowe nazwy mogą być tak pouczające, jak to konieczne, pozwalając na dowolne arant semantyczny.

Każda platforma może analizować JSON za pomocą zaledwie kilku wierszy kodu. XML wymaga złożonych bibliotek OO, które nie są wykonalne na wielu platformach.

Adnotacje sprawią, że JSON sprawi, że będzie mniej interoperacyjny. Po prostu nie ma nic więcej do dodania, chyba że tak naprawdę potrzebujesz języka znaczników (XML) i nie przejmuj się, czy utrwalone dane można łatwo przeanalizować.

ALE, jak zauważył również twórca JSON, zawsze istniało wsparcie potoku JS dla komentarzy:

Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON. - Douglas Crockford, 2012

Jeśli Twój plik tekstowy, który jest łańcuchem JSON, zostanie odczytany przez jakiś program, jak trudno byłoby usunąć komentarze w stylu C lub C ++ przed jego użyciem?

Odpowiedź: Byłby to jeden liniowiec. Jeśli to zrobisz, pliki JSON mogą zostać użyte jako pliki konfiguracyjne.

Jeśli używasz biblioteki Newtonsoft.Json z ASP.NET do odczytu / deserializacji, możesz użyć komentarzy w treści JSON:

// „name”: „string”

// "id": int

lub

/* To jest

przykład komentarza * /

PS: Komentarze jednowierszowe są obsługiwane tylko w ponad 6 wersjach Newtonsoft Json.

Dodatkowa uwaga dla osób, które nie potrafią myśleć nieszablonowo: używam formatu JSON do podstawowych ustawień w aplikacji internetowej ASP.NET, którą stworzyłem. Czytam plik, przekształcam go w obiekt ustawień za pomocą biblioteki Newtonsoft i używam go w razie potrzeby.

Wolę pisać komentarze o poszczególnych ustawieniach w samym pliku JSON i naprawdę nie dbam o integralność formatu JSON, o ile biblioteka, której używam, jest w porządku.

Myślę, że jest to „łatwiejszy w użyciu / zrozumieniu” niż tworzenie osobnego pliku „settings.README” i objaśnianie zawartych w nim ustawień.

Jeśli masz problem z tego rodzaju użytkowaniem; przepraszam, dżin wyszedł z lampy. Ludzie znajdą inne zastosowania dla formatu JSON i nic nie możesz na to poradzić.

Ideą JSON jest zapewnienie prostej wymiany danych między aplikacjami. Zazwyczaj są one oparte na Internecie, a językiem jest JavaScript.

Tak naprawdę nie pozwala na komentarze jako takie, jednak przekazanie komentarza jako jednej z par nazwa / wartość w danych z pewnością zadziałałoby, chociaż te dane oczywiście musiałyby zostać zignorowane lub przetworzone specjalnie przez kod parsujący.

To powiedziawszy, nie jest intencją, aby plik JSON zawierał komentarze w tradycyjnym znaczeniu. To powinny być tylko dane.

Zajrzyj na stronę JSON, aby uzyskać więcej szczegółów.

Właśnie napotkałem to w przypadku plików konfiguracyjnych. Nie chcę używać formatu XML (pełny, graficzny, brzydki, trudny do odczytania) ani formatu „ini” (bez hierarchii, żadnego prawdziwego standardu itp.) Ani formatu Java „Właściwości” (jak .ini).

JSON może zrobić wszystko, co w ich mocy, ale jest to mniej szczegółowe i bardziej czytelne dla ludzi - a parsery są łatwe i wszechobecne w wielu językach. To tylko drzewo danych. Ale komentarze spoza pasma często wymagają udokumentowania „domyślnych” konfiguracji i tym podobnych. Konfiguracje nigdy nie powinny być „pełnymi dokumentami”, ale drzewami zapisanych danych, które w razie potrzeby mogą być czytelne dla człowieka.

Wydaje mi się, że można użyć "#": "comment"do „prawidłowego” JSON.

JSON nie obsługuje komentarzy natywnie, ale możesz stworzyć własny dekoder lub przynajmniej preprocesor do usuwania komentarzy, to jest w porządku (pod warunkiem, że po prostu zignorujesz komentarze i nie użyjesz ich do wskazania, jak aplikacja powinna przetwarzać dane JSON ).

JSON nie ma komentarzy. Koder JSON NIE MOŻE wyprowadzać komentarzy. Dekoder JSON MOŻE akceptować i ignorować komentarze.

Komentarze nigdy nie powinny być wykorzystywane do przekazywania czegokolwiek znaczącego. Po to jest JSON.

Por .: Douglas Crockford, autor specyfikacji JSON .

To zależy od twojej biblioteki JSON. Json.NET obsługuje JavaScript komentarze w stylu, /* commment */.

Zobacz inne pytanie dotyczące przepełnienia stosu .

JSON ma sens w przypadku plików konfiguracyjnych i innych lokalnych zastosowań, ponieważ jest wszechobecny i ponieważ jest znacznie prostszy niż XML.

Jeśli ludzie mają poważne powody, by nie komentować w JSON komentarzy podczas przekazywania danych (bez względu na to, czy są ważne, czy nie), prawdopodobnie JSON można podzielić na dwa:

• JSON-COM: JSON w sieci lub reguły obowiązujące podczas przesyłania danych JSON.
• JSON-DOC: dokument JSON lub JSON w plikach lub lokalnie. Reguły definiujące prawidłowy dokument JSON.

JSON-DOC zezwala na komentarze i mogą występować inne drobne różnice, takie jak obsługa białych znaków. Parsery można łatwo konwertować z jednej specyfikacji na drugą.

W odniesieniu do uwagi Douglasa Crockforda na ten temat (powołanej przez @Artur Czajka)

Załóżmy, że używasz JSON do przechowywania plików konfiguracyjnych, które chcesz opatrzyć adnotacjami. Śmiało i wstaw wszystkie komentarze, które lubisz. Następnie potokuj go przez JSMin przed przekazaniem go do analizatora składni JSON.

Mówimy o ogólnym problemie z plikiem konfiguracyjnym (między językami / platformą), a on odpowiada za pomocą narzędzia JS!

Pewnie, że minify specyficzne dla JSON może być zaimplementowane w dowolnym języku, ale standaryzuj to, aby stało się wszechobecne w parserach we wszystkich językach i platformach, aby ludzie przestali tracić czas na brak tej funkcji, ponieważ mają dobre przypadki użycia, szukając problemu w forach internetowych i zachęcanie ludzi do mówienia, że ​​to zły pomysł lub sugerowanie, że łatwo jest zaimplementować usuwanie komentarzy z plików tekstowych.

Inną kwestią jest interoperacyjność. Załóżmy, że masz bibliotekę, interfejs API lub dowolny podsystem, z którym powiązane są pewne pliki konfiguracyjne lub pliki danych. Dostęp do tego podsystemu można uzyskać z różnych języków. Czy możesz powiedzieć innym: przy okazji nie zapomnij usunąć komentarzy z plików JSON przed przekazaniem ich do parsera!

Jeśli używasz JSON5 , możesz dołączyć komentarze.

JSON5 to proponowane rozszerzenie JSON, którego celem jest ułatwienie ludziom pisania i utrzymywania ręcznie. Robi to poprzez dodanie minimalnych funkcji składniowych bezpośrednio z ECMAScript 5.

Pakiet JavaScript Dojo Toolkit (przynajmniej od wersji 1.4) pozwala na dołączanie komentarzy do JSON. Komentarze mogą mieć /* */format. Dojo Toolkit zużywa JSON za pośrednictwem dojo.xhrGet()połączenia.

Inne zestawy narzędzi JavaScript mogą działać podobnie.

Może to być pomocne podczas eksperymentowania z alternatywnymi strukturami danych (lub nawet listami danych) przed wybraniem ostatecznej opcji.

JSON nie jest protokołem ramkowym . Jest to format bez języka . Dlatego format komentarza nie jest zdefiniowany dla JSON.

Jak wiele osób sugerowało, istnieją pewne sztuczki, na przykład duplikaty kluczy lub określony klucz _comment, którego można użyć. To zależy od Ciebie.

Ty można mieć uwag w jsonp , ale nie w czystej JSON. Właśnie spędziłem godzinę próbując zmusić mój program do pracy z tym przykładem z Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

Jeśli klikniesz ten link, zobaczysz

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

Ponieważ miałem podobny plik w folderze lokalnym, nie było żadnych problemów z polityką tego samego pochodzenia , więc zdecydowałem się użyć czystego JSON ... i oczywiście $.getJSONzawiodłem z powodu komentarzy.

W końcu właśnie wysłałem ręczne żądanie HTTP na powyższy adres i zdałem sobie sprawę, że typ zawartości był, text/javascriptponieważ JSONP zwraca czysty JavaScript. W takim przypadku komentarze są dozwolone . Ale moja aplikacja zwróciła treść application/json, więc musiałem usunąć komentarze.

To jest pytanie „czy możesz” . A oto odpowiedź „tak” .

Nie, nie powinieneś używać duplikatywnych elementów obiektu do umieszczania danych kanału bocznego w kodowaniu JSON. (Patrz „Nazwy w obiekcie POWINNY być unikalne” w RFC ).

I tak, można wstawiać komentarze około JSON , które można przetworzyć na zewnątrz.

Ale jeśli chcesz wprowadzić i wyodrębnić dowolne dane kanału bocznego do prawidłowego JSON, oto odpowiedź. Korzystamy z nieunikalnej reprezentacji danych w kodowaniu JSON. Jest to dozwolone ^* w sekcji drugiej dokumentu RFC w części „białe znaki są dozwolone przed lub po którymkolwiek z sześciu znaków strukturalnych”.

^* RFC stwierdza tylko, że „spacja jest dozwolona przed lub po którymkolwiek z sześciu znaków strukturalnych”, nie mówiąc wprost o ciągach, liczbach, „fałszu”, „prawdzie” i „null”. To pominięcie jest ignorowane we WSZYSTKICH implementacjach.

Najpierw kanonizuj JSON, minimalizując go:

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

Następnie zakoduj swój komentarz w formacie binarnym:

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

Następnie ustal swój plik binarny:

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

Oto twój wynik:

$jsonWithComment = $steg . $jsonMin;

WYŁĄCZENIE ODPOWIEDZIALNOŚCI: TO GŁOS

Istnieje sposób dodawania komentarzy i pozostawania w ramach specyfikacji (nie jest wymagany żaden dodatkowy analizator składni). Nie spowoduje to jednak czytelnych dla człowieka komentarzy bez jakiejkolwiek analizy.

Możesz nadużywać następujących elementów:

Nieznaczne białe znaki są dozwolone przed dowolnym tokenem lub po nim. Biała spacja to dowolna sekwencja jednego lub więcej następujących punktów kodowych: tabulacja znaków (U + 0009), przesunięcie wiersza (U + 000A), powrót karetki (U + 000D) i spacja (U + 0020).

W hacky sposób możesz nadużyć tego, aby dodać komentarz. Na przykład: rozpocznij i zakończ komentarz za pomocą karty. Zakoduj komentarz w base3 i użyj innych białych znaków, aby je przedstawić. Na przykład.

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

( hello base threew ASCII) Zamiast 0 użyj spacji, dla 1 użyj przesunięcia wiersza i dla 2 użyj powrotu karetki.

To po prostu pozostawi wiele nieczytelnych białych znaków (chyba że stworzysz wtyczkę IDE do kodowania / dekodowania w locie).

Nigdy nawet tego nie próbowałem, z oczywistych powodów i ty też nie powinieneś.

Używamy strip-json-commentsdo naszego projektu. Obsługuje coś takiego:

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

Wystarczy npm install --save strip-json-commentszainstalować i używać go w następujący sposób:

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

W moim przypadku potrzebuję użyć komentarzy do celów debugowania, przed wyjściem struktury JSON. Dlatego postanowiłem użyć informacji debugowania w nagłówku HTTP, aby uniknąć uszkodzenia klienta:

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

JSON nie zezwala na komentarze jako takie. Rozumowanie jest całkowicie głupie, ponieważ można użyć samego JSON do tworzenia komentarzy, co całkowicie eliminuje rozumowanie i ładuje przestrzeń danych analizatora składni bez żadnego uzasadnionego powodu dla dokładnie tego samego wyniku i potencjalnych problemów, takich jak: JSON plik z komentarzami.

Jeśli spróbujesz wstawić komentarze ( na przykład przy użyciu //lub /* */lub #), niektóre analizatory składni zakończą się niepowodzeniem, ponieważ nie jest to ściśle zgodne ze specyfikacją JSON. Więc nigdy nie powinieneś tego robić.

Oto na przykład, gdy mój system manipulacji obrazem zapisał notacje obrazu i niektóre podstawowe sformatowane (komentarz) informacje na ich temat (na dole):

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

Aby pociąć element JSON na części, dodaję linie „obojętnego komentarza”:

{

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

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

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

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

}