Чи можна використовувати коментарі в JSON?

Чи можу я використовувати коментарі у файлі JSON? Якщо так, то як?

Ні.

Усі JSON повинні бути даними, і якщо ви додасте коментар, вони також будуть даними.

У вас може бути призначений елемент даних, званий "_comment"(або щось подібне), який буде ігноруватися програмами, які використовують дані JSON.

Вам, мабуть, буде краще мати коментар у процесах, що генерують / отримують JSON, оскільки вони, як передбачається, повинні знати, якими будуть дані JSON заздалегідь, або принаймні структуру їх.

Але якщо ви вирішили:

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

Ні , коментарі форми //…або /*…*/заборонені в JSON. Ця відповідь заснована на:

• http://www.json.org
• RFC 4627 : application/jsonТип медіа для нотації об'єкта JavaScript (JSON)
• RFC 8259 Формат обміну даними з нотацією об'єкта JavaScript (JSON) (перевершує RFC 4627, 7158, 7159)

Включіть коментарі, якщо захочете; зніміть їх за допомогою мініфікатора перед розбором або передачею.

Щойно я випустив JSON.minify (), який викреслює коментарі та пробіли з блоку JSON та робить його дійсним JSON, який можна розібрати. Отже, ви можете використовувати його так:

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

Коли я випустив це, у мене з'явився величезний зворотний зв'язок людей, які не погоджуються навіть з ідеєю цього, тому я вирішив, що напишу вичерпну публікацію в блозі про те, чому коментарі мають сенс в JSON . Сюди входить цей помітний коментар від творця JSON:

Припустимо, ви використовуєте JSON для збереження файлів конфігурації, які ви хочете зазначити. Вперед і вставляйте всі коментарі, які вам подобаються. Потім передайте його через JSMin, перш ніж передавати його своєму аналізатору JSON. - Дуглас Крокфорд, 2012

Сподіваємось, це корисно тим, хто не погоджується з тим, чому JSON.minify () може бути корисним.

Коментарі були видалені з JSON дизайном.

Я видалив коментарі з JSON, тому що побачив, що люди використовують їх для виконання директив розбору, що може зруйнувати сумісність. Я знаю, що відсутність коментарів деяких людей сумує, але це не повинно.

Припустимо, ви використовуєте JSON для збереження файлів конфігурації, які ви хочете зазначити. Далі вставте всі коментарі, які вам подобаються. Потім передайте його через JSMin, перш ніж передавати його своєму аналізатору JSON.

Джерело: Публічна заява Дугласа Крокфорда на G +

ВІДХОДЖЕННЯ: ВАША ГАРАНТІЯ ВІДМОВА

Як уже зазначалося, цей хак використовує переваги впровадження специфікації. Не всі аналізатори JSON зрозуміють такий тип JSON. Зокрема, потокові аналізатори задушать.

Це цікава цікавість, але вам взагалі нічого не слід використовувати . Нижче оригінальна відповідь.

Я знайшов невеликий хак, який дозволяє розміщувати коментарі у файлі JSON, який не впливатиме на розбір або змінювати будь-які дані, що представляються.

Здається, що при оголошенні об'єкта буквалом ви можете вказати два значення одним і тим же ключем, а останнє має перевагу. Вірите чи ні, виявляється, JSON-аналізатори працюють так само. Таким чином, ми можемо використовувати це для створення коментарів у вихідному JSON, які не будуть представлені в проаналізованому поданні об'єкта.

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

Якщо ми застосуємо цю техніку, ваш коментований файл JSON може виглядати приблизно так:

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

Вищевказаний код є дійсним JSON . Якщо розібрати його, ви отримаєте такий предмет:

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

Це означає, що коментарів немає і слідів, і вони не матимуть дивних побічних ефектів.

Щасливий злом!

JSON не підтримує коментарів. Він також ніколи не використовувався для файлів конфігурації, де необхідні коментарі.

Hjson - це формат файлу конфігурації для людей. Розслаблений синтаксис, менше помилок, більше коментарів.

Дивіться hjson.org для бібліотек JavaScript, Java, Python, PHP, Rust, Go, Ruby та C #.

Подумайте про використання YAML. Це майже суперсет JSON (практично всі дійсні JSON є дійсними YAML), і це дозволяє коментувати.

Ви не можете. Принаймні, це мій досвід із швидкого погляду на json.org .

На цій сторінці синтаксис JSON візуалізується. Зауважень щодо коментарів немає.

Коментарі не є офіційним стандартом, хоча деякі парсери підтримують коментарі у стилі C ++. Я використовую JsonCpp . У прикладах є такий:

// 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 не підтверджує це. Таким чином, коментарі - це розширення для специфічного розбору і не стандартне.

Ще один аналізатор - JSON5 .

Альтернатива JSON TOML .

Наступною альтернативою є jsonc .

Натомість слід написати схему JSON . Наразі схема JSON є запропонованою специфікацією проекту Internet. Крім документації, схему можна також використовувати для перевірки ваших даних JSON.

Приклад:

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

Ви можете надати документацію за допомогою атрибута схеми опису .

Якщо ви використовуєте Джексона як свій аналізатор JSON, саме так ви дозволяєте йому дозволити коментарі:

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

Тоді ви можете мати такі коментарі:

{
  key: "value" // Comment
}

Також ви можете мати коментарі, починаючи з #налаштування:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Але загалом (як відповіли раніше) специфікація не дозволяє коментарі.

Ось що я знайшов у документації Google Firebase, яка дозволяє розміщувати коментарі в 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"
}

НІ . JSON використовував для підтримки коментарів, але їх зловживали та видаляли зі стандарту.

Від творця JSON:

Я видалив коментарі з JSON, тому що побачив, що люди використовують їх для виконання директив розбору, що може знищити сумісність. Я знаю, що відсутність коментарів деяких людей сумує, але це не повинно. - Дуглас Крокфорд, 2012

Офіційний сайт JSON знаходиться на JSON.org . JSON визначається стандартом ECMA International. Завжди існує процес подання петицій, щоб переглядати стандарти. Навряд чи анотації будуть додані до стандарту JSON з кількох причин.

JSON за задумом - це легко реверсивна (людський аналіз) альтернатива XML. Це спрощується навіть до того, що анотації не потрібні. Це навіть не мова розмітки. Мета - стабільність та взаємодія.

Кожен, хто розуміє співвідношення об'єкта "має", може зрозуміти будь-яку структуру JSON - у цьому вся суть. Це просто спрямований ациклічний графік (DAG) з тегами вузлів (пари ключів / значень), який є майже універсальною структурою даних.

Ця необхідна примітка може бути "// Це теги DAG". Назви ключів можуть бути настільки інформативними, наскільки це потрібно, дозволяючи довільну смислову суворість.

Будь-яка платформа може проаналізувати JSON лише за допомогою декількох рядків коду. XML вимагає складних OO-бібліотек, нежиттєздатних на багатьох платформах.

Анотації просто змусять JSON зробити менш взаємозамінними. Додавати більше нічого немає, якщо тільки вам дійсно потрібна мова розмітки (XML), і не важливо, чи зберігаються ваші збережені дані легко розбираються.

Але, як зауважив творець JSON, завжди існувала підтримка JS-конвеєра для коментарів:

Вперед і вставляйте всі коментарі, які вам подобаються. Потім передайте його через JSMin, перш ніж передавати його своєму аналізатору JSON. - Дуглас Крокфорд, 2012

Якщо ваш текстовий файл, що представляє собою рядок JSON, читатиме якась програма, наскільки складно буде викреслити коментарі у стилі C або C ++ перед його використанням?

Відповідь: Це був би один лайнер. Якщо ви це зробите, тоді файли JSON можуть використовуватися як файли конфігурації.

Якщо ви використовуєте бібліотеку Newtonsoft.Json з ASP.NET для читання / десяріалізації, ви можете використовувати коментарі у вмісті JSON:

// "name": "string"

// "id": int

або

/* Це

приклад коментаря * /

PS: Однорядкові коментарі підтримуються лише в 6+ версіях Newtonsoft Json.

Додаткова примітка для людей, які не можуть задуматися: я використовую формат JSON для основних налаштувань веб-програми ASP.NET, яку я створив. Я читаю файл, перетворюю його в об’єкт налаштувань за допомогою бібліотеки Newtonsoft і використовую його при необхідності.

Я вважаю за краще писати коментарі до кожного окремого параметра у самому файлі JSON, і мені дуже не байдуже цілісність формату JSON, доки бібліотека, яку я використовую, у ньому нормально.

Я думаю, що це "простіший у використанні / розумінні" спосіб, ніж створення окремого файлу "settings.README" та пояснення параметрів у ньому.

Якщо у вас є проблеми з таким використанням; вибачте, джин вийшов із лампи. Люди знайдуть інші звички для формату JSON, і ви нічого з цим не можете зробити.

Ідея JSON полягає в тому, щоб забезпечити простий обмін даними між програмами. Зазвичай вони базуються на веб-сторінках, а мова - JavaScript.

Це насправді не дозволяє коментарі як такі, однак передача коментаря як однієї з імен / значень пар у даних, безумовно, спрацює, хоча ці дані, очевидно, повинні бути проігноровані або оброблені спеціально кодом розбору.

Все, що було сказано, це не намір, щоб файл JSON містив коментарі в традиційному розумінні. Це повинні бути просто дані.

Перегляньте веб-сайт JSON для отримання більш детальної інформації.

Я просто стикаюся з цим для файлів конфігурації. Я не хочу використовувати XML (багатослівний, графічно, некрасивий, важко читається) або формат "ini" (немає ієрархії, немає реального стандарту тощо) або формат Java "Властивості" (наприклад, .ini).

JSON може зробити все, що тільки може, але це набагато менш багатослівно і з легкістю читати - а парсери легко і всюди поширені на багатьох мовах. Це просто дерево даних. Але сторонні коментарі часто є необхідністю документувати конфігурації "за замовчуванням" тощо. Конфігурації ніколи не повинні бути "повноцінними документами", а деревами збережених даних, які за потреби можна читати людиною.

Я думаю, що можна було б використовувати "#": "comment"для "дійсного" JSON.

JSON не підтримує коментарі споконвічно, але ви можете зробити свій власний декодер або принаймні препроцесор, щоб викреслити коментарі, це абсолютно добре (доки ви просто ігноруєте коментарі та не використовуєте їх, щоб визначати, як ваша програма повинна обробляти дані JSON ).

JSON не має коментарів. Кодер JSON НЕ МОЖЕ виводити коментарі. Декодер JSON МОЖЕ приймати та ігнорувати коментарі.

Коментарі ніколи не повинні використовуватися для передачі нічого значимого. Саме для цього і JSON.

Cf: Дуглас Крокфорд, автор спец . JSON

Це залежить від вашої бібліотеки JSON. Json.NET підтримує JavaScript коментар стилю, /* commment */.

Дивіться ще одне запитання про переповнення стека .

JSON має багато сенсу для конфігураційних файлів та іншого локального використання, оскільки він є всюдисущим і тому, що це набагато простіше, ніж XML.

Якщо люди мають вагомі причини проти коментарів у JSON під час передачі даних (чи дійсні вони чи ні), можливо, JSON можна розділити на два:

• JSON-COM: JSON на дроті або правила, які застосовуються під час передачі даних JSON.
• JSON-DOC: документ JSON або JSON у файлах або локально. Правила, що визначають дійсний документ JSON.

JSON-DOC дозволить коментувати, і можуть існувати інші незначні відмінності, такі як обробка пробілів. Парсери можуть легко перетворювати з однієї специфікації на іншу.

Що стосується зауваження Дугласа Крокфорда з цього приводу (на яке посилається @Artur Czajka)

Припустимо, ви використовуєте JSON для збереження файлів конфігурації, які ви хочете зазначити. Далі вставте всі коментарі, які вам подобаються. Потім передайте його через JSMin, перш ніж передавати його своєму аналізатору JSON.

Ми говоримо про загальну проблему з конфігураційним файлом (перехресна мова / платформа), і він відповідає за допомогою спеціальної утиліти JS!

Впевнені, що міні-інтерфейс JSON може бути реалізований на будь-якій мові, але стандартизуйте це, щоб він став всюдисущим для парсерів на всіх мовах та платформах, щоб люди перестали витрачати свій час на відсутність функції, оскільки вони мають гарні випадки використання для цього, розглядаючи проблему в Інтернет-форуми, а люди, які говорять їм, що це погана ідея або пропонують легко реалізувати зачистки коментарів із текстових файлів.

Інше питання - сумісність. Припустимо, у вас є бібліотека або API або будь-який тип підсистеми, з якою пов’язані деякі файли конфігурації або даних. І до цієї підсистеми можна отримати доступ з різних мов. Тоді ви хочете сказати людям: до речі не забудьте викреслити коментарі з файлів JSON, перш ніж передавати їх в аналізатор!

Якщо ви використовуєте JSON5, ви можете включати коментарі.

JSON5 - це запропоноване розширення до JSON, яке має на меті полегшити людину писати та підтримувати вручну. Це робиться, додаючи деякі мінімальні функції синтаксису безпосередньо з ECMAScript 5.

Інструментарій JavaScript Dojo Toolkit JavaScript (принаймні, версія 1.4) дозволяє включати коментарі до вашого JSON. Коментарі можуть бути /* */форматними. Інструментарій Dojo споживає JSON через dojo.xhrGet()дзвінок.

Інші набори інструментів JavaScript можуть працювати аналогічно.

Це може бути корисно при експерименті з альтернативними структурами даних (або навіть списками даних) перед вибором остаточного варіанту.

JSON - це не оформлений протокол . Це формат, вільний від мови . Отже, формат коментаря для JSON не визначений.

Як багато хто запропонував, є деякі хитрощі, наприклад, дублюючі ключі або певний ключ, _commentякий ви можете використовувати. Тобі вирішувати.

Ви можете мати коментарі в JSONP , але не в чистому JSON. Я щойно витратив годину, намагаючись змусити свою програму працювати з цим прикладом із Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

Якщо ви перейдете за посиланням, ви побачите

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

Оскільки в моїй локальній папці був подібний файл, проблем із політикою того самого походження не виникало , тому я вирішив використовувати чистий JSON ... і, звичайно, $.getJSONмовчки вийшов з ладу через коментарі.

Врешті-решт я просто надіслав запит HTTP вручну за вказаною вище адресою і зрозумів, що тип вмісту був, text/javascriptоскільки JSONP повертає чистий JavaScript. У цьому випадку коментарі дозволені . Але моя програма повернула тип вмісту application/json, тому мені довелося видалити коментарі.

Це питання "чи можете ви" . І ось відповідь "так" .

Ні, не слід використовувати дублюючі члени об’єктів для введення даних бічних каналів у кодування JSON. (Див. "Імена в об'єкті повинні бути унікальними" в RFC ).

І так, ви можете вставити коментарі навколо JSON , які ви могли б розібрати.

Але якщо ви хочете спосіб вставки та вилучення довільних даних бічного каналу до дійсного JSON, ось відповідь. Ми скористаємося унікальним поданням даних у кодуванні JSON. Це дозволено ^* у другому розділі RFC у розділі "пробіл дозволений до або після будь-якого з шести структурних символів".

^* RFC заявляє лише, що "пробіл дозволений до або після будь-якого з шести структурних символів", не чітко згадуючи рядки, числа, "false", "true" та "null". Цей упущення ігнорується у ВСІХ реалізаціях.

По-перше, канонізуйте свій JSON, мінімізуючи його:

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

Потім кодуйте свій коментар у двійковій формі:

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

Тоді налаштуйте свій двійковий файл:

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

Ось ваш результат:

$jsonWithComment = $steg . $jsonMin;

ВІДМОВА ВІДПОВІДАЛЬНІСТЬ: Це СУМЧО

Насправді є спосіб додавати коментарі та залишатися в межах специфікації (не потрібен додатковий синтаксичний аналіз). Це не призведе до читабельних для людини коментарів без будь-якого аналізу.

Ви можете зловживати наступним:

Незначний пробіл дозволений до або після будь-якого маркера. Пробіл - це будь-яка послідовність одного або декількох з наступних кодів: табуляція символів (U + 0009), подача рядків (U + 000A), повернення каретки (U + 000D) та пробіл (U + 0020).

Гакітним способом ви можете зловживати цим, щоб додати коментар. Наприклад: запустіть і закінчіть коментар на вкладці. Кодуйте коментар у base3 та використовуйте інші символи пробілу для їх представлення. Наприклад.

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

( hello base threeв ASCII) Але замість 0 використовувати простір, для 1 каналу рядка та 2 повернення каретки.

Це просто залишить вам багато нечитабельних пробілів (якщо ви не зробите плагін IDE, щоб кодувати / декодувати його на льоту).

Я ніколи навіть цього не пробував, з очевидних причин, і ні з вами.

Ми використовуємо strip-json-commentsдля нашого проекту. Він підтримує щось на кшталт:

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

Просто npm install --save strip-json-commentsвстановити та використовувати його так:

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

У моєму випадку мені потрібно використовувати коментарі для цілей налагодження до виходу структури JSON. Тому я вирішив використовувати інформацію про налагодження у заголовку HTTP, щоб не зламати клієнта:

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

JSON сама по собі не дозволяє коментувати. Міркування є абсолютно нерозумними, оскільки ви можете використовувати сам JSON для створення коментарів, що цілком ухиляється від міркувань, і завантажує простір даних аналізатора взагалі без поважних причин для абсолютно такого ж результату та потенційних проблем, таких як вони: JSON файл із коментарями.

Якщо ви спробуєте поставити коментарі в ( з використанням //або /* */або #, наприклад), то деякі парсери зазнає невдачі , тому що це не строго в межах специфікації JSON. Тож ніколи цього не слід робити.

Ось, наприклад, де моя система обробки зображень зберегла нотації зображень та деяку основну відформатовану інформацію (коментар), що стосується них (внизу):

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

Щоб вирізати елемент JSON на частини, я додаю рядки "фіктивний коментар":

{

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

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

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

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

}