Можно ли использовать комментарии в формате 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 в настоящее время является предложенным проектом спецификации в Интернете. Помимо документации, схема также может быть использована для проверки ваших данных 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"
}

NO . JSON раньше поддерживал комментарии, но они были оскорблены и удалены из стандарта.

От создателя JSON:

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

Официальный сайт JSON находится на JSON.org . JSON определяется как стандарт ECMA International. Всегда есть ходатайство о пересмотре стандартов. Маловероятно, что аннотации будут добавлены в стандарт JSON по нескольким причинам.

JSON по своему дизайну - это легко модифицируемая (анализируемая человеком) альтернатива XML. Это упрощено даже до такой степени, что аннотации не нужны. Это даже не язык разметки. Цель - стабильность и интероперабельность.

Любой, кто понимает отношение «имеет-a» объектной ориентации, может понять любую структуру JSON - вот и весь смысл. Это просто ориентированный ациклический граф (DAG) с тегами узлов (пары ключ / значение), который является почти универсальной структурой данных.

Эта единственная необходимая аннотация может быть "// Это теги DAG". Имена ключей могут быть настолько информативными, насколько это необходимо, что позволяет использовать произвольную семантическую арность.

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

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

НО, как заметил создатель JSON, всегда была поддержка конвейера JS для комментариев:

Идите вперед и вставьте все комментарии, которые вам нравятся. Затем передайте его через JSMin, прежде чем передать его вашему анализатору JSON. - Дуглас Крокфорд, 2012

Если ваш текстовый файл, представляющий собой строку JSON, будет прочитан какой-либо программой, насколько сложно будет удалить комментарии в стиле C или C ++ перед его использованием?

Ответ: Это был бы один лайнер. Если вы сделаете это, файлы JSON могут быть использованы в качестве файлов конфигурации.

Если вы используете библиотеку Newtonsoft.Json с ASP.NET для чтения / десериализации, вы можете использовать комментарии в содержимом JSON:

// "имя": "строка"

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

Ср .: Дуглас Крокфорд, автор JSON spec .

Это зависит от вашей библиотеки 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 (по крайней мере, начиная с версии 1.4) позволяет включать комментарии в ваш JSON. Комментарии могут быть в /* */формате. Dojo Toolkit использует 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]
]);

Поскольку у меня был аналогичный файл в моей локальной папке, с политикой Same-origin не было проблем , поэтому я решил использовать чистый JSON ... и, конечно, $.getJSONмолча терпел неудачу из-за комментариев.

В конце концов я просто отправил HTTP-запрос вручную по указанному выше адресу и понял, что это тип контента, text/javascriptтак как, ну, JSONP возвращает чистый JavaScript. В этом случае комментарии разрешены . Но мое приложение вернуло content-type 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"

}