Могут ли комментарии использоваться в JSON?

Можно ли использовать комментарии в файле JSON? Если да, то как?

Ответ 1

Нет.

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

Ответ 2

Нет, комментарии в форме //… или /*…*/ не допускаются в JSON. Этот ответ основан на:

http://www.json.org
RFC 4627: application/json Тип носителя для нотации объектов JavaScript (JSON)
RFC 8259 Формат обмена данными нотации объектов JavaScript (JSON) (заменяет RFC 4627, 7158, 7159)

Ответ 3

Включить комментарии, если вы выберете; выставьте их с помощью minifier перед синтаксическим разбором или передачей.

Я только что выпустил JSON.minify(), который удаляет комментарии и пробелы из блока JSON и делает это действительный JSON, который может быть проанализирован. Итак, вы можете использовать его как:

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

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

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

Надеюсь, что это полезно для тех, кто не согласен с тем, почему JSON.minify() может быть полезным.

Ответ 4

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

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

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

Источник: Публичное выражение Дугласа Крокфорда о G +

Ответ 5

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: ВАША ГАРАНТИЯ ГОЛОСОВАЛА

Как уже отмечалось, этот хак использует преимущества спецификации. Не все парнеры 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]
}

Это означает, что комментариев нет, и у них не будет странных побочных эффектов.

Счастливый взлом!

Ответ 6

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

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

Смотрите hjson.org для библиотек JavaScript, Java, Python, PHP, Rust, Go, Ruby и С#.

Ответ 7

Рассмотрим использование YAML. Это почти надмножество JSON (фактически все действительные JSON действительны YAML), и он позволяет комментировать.

Ответ 8

Вы не можете. По крайней мере, мой опыт от быстрого взгляда на json.org.

JSON имеет синтаксис, отображаемый на этой странице. Нет комментариев о комментариях.

Ответ 9

Вместо этого вы должны написать схему JSON. Схема JSON в настоящее время является предлагаемой спецификацией проекта Интернета. Помимо документации, схема также может использоваться для проверки ваших данных JSON.

Пример:

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

Вы можете предоставить документацию, используя атрибут описание.

Ответ 10

Если вы используете Джексона в качестве парсера JSON, вы можете разрешить комментарии следующим образом:

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

Тогда вы можете иметь такие комментарии:

{
  key: "value" // Comment
}

И вы также можете иметь комментарии, начиная с #, установив:

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

Но в целом (как ответили ранее) спецификация не допускает комментариев.

Ответ 11

Комментарии не являются официальным стандартом. Хотя некоторые парсеры поддерживают комментарии в стиле 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.

Ответ 12

Вот что я нашел в документации Google Firebase, которая позволяет добавлять комментарии в JSON:

{
  "//": "Some browsers will use this to enable push notifications.",
  "//": "It is the same for all projects, this is not your project sender ID",
  "gcm_sender_id": "1234567890"
}

Ответ 13

Извините, мы не можем использовать комментарии в JSON... См. Диаграмму синтаксиса для JSON на JSON.org.

Дуглас Крокфорд говорит: " Почему он удалил комментарии в JSON и предоставил альтернативный способ сделать это ":

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

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

Ответ 14

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

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

Ответ 15

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

// "name": "string"

// "id": int

или

/* Это
Пример комментария
*/

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

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

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

Я думаю, что это "проще использовать/понимать", чем создавать отдельный файл settings.README и объяснять настройки в нем.

Если у вас есть проблемы с этим видом использования; извините, джина вне лампы. Люди могли бы найти другие способы использования формата JSON, и вы ничего не можете с этим поделать.

Ответ 16

Идея JSON заключается в обеспечении простого обмена данными между приложениями. Они, как правило, основаны на Интернете, а язык - JavaScript.

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

Все, что сказало, это не намерение, что файл JSON должен содержать комментарии в традиционном смысле. Это должны быть только данные.

Посмотрите на сайт JSON для более подробной информации.

Ответ 17

Я просто сталкиваюсь с этим для файлов конфигурации. Я не хочу использовать XML (подробный, графически, уродливый, трудно читаемый) или "ini" (без иерархии, без реального стандарта и т.д.) Или в формате Java "Свойства" ( например .ini).

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

Я думаю, можно использовать "#": "comment", для "valid" JSON.

Ответ 18

Это зависит от вашей библиотеки JSON. Json.NET поддерживает комментарии в стиле JavaScript, /* commment */.

См. Другой вопрос о переполнении стека.

Ответ 19

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

У JSON нет комментариев. Кодер JSON НЕ ДОЛЖЕН выводить комментарии. Декодер JSON МОЖЕТ принимать и игнорировать комментарии.

Комментарии никогда не должны использоваться для передачи каких-либо значимых замечаний. То есть для чего JSON.

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

Ответ 20

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

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

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

JSON-DOC позволит комментировать, и могут существовать другие незначительные отличия, такие как обработка пробелов. Парсеры могут легко конвертировать из одной спецификации в другую.

Что касается замечания , сделанного Дугласом Крокфордом по этим вопросам (ссылка на @Artur Czajka)

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

Мы говорим об общей проблеме с конфигурационным файлом (кросс-язык/платформа), и он отвечает с помощью специальной утилиты JS!

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

Другая проблема - совместимость. Предположим, у вас есть библиотека или API или любая подсистема, в которой есть некоторые файлы конфигурации или данных, связанные с ней. И эта подсистема для доступа с разных языков. Тогда вы рассказываете людям: кстати не забудьте вычеркнуть комментарии из файлов JSON, прежде чем передавать их в парсер!

Ответ 21

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

Другие инструментальные средства JavaScript могут работать аналогичным образом.

Это может быть полезно при экспериментировании с альтернативными структурами данных (или даже списками данных) перед выбором окончательной опции.

Ответ 22

Если вы используете JSON5, вы можете включать комментарии.

JSON5 - это предлагаемое расширение для JSON, целью которого является упрощение для людей записи и поддержки вручную. Он делает это, добавляя некоторые минимальные синтаксические особенности непосредственно из ECMAScript 5.

Ответ 23

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

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

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

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

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

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

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

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

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

Ответ 24

JSON не является файловым протоколом. Это свободный от языка формат. Поэтому формат комментария для JSON не определен.

Как и многие люди, есть некоторые трюки, например дублирующие ключи или определенный ключ _comment, который вы можете использовать. Это зависит от вас.

Ответ 25

Вы можете иметь комментарии в 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 молча $.getJSON неудачу из-за комментариев.

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

Ответ 26

Это вопрос "вы можете. И вот ответ " да".

Нет, вы не должны использовать дублирующих членов объекта для заполнения данных бокового канала в кодировке JSON. (См. "Имена внутри объекта ДОЛЖНЫ быть уникальными" в RFC).

И да, вы могли бы вставить комментарии вокруг JSON, которые вы могли бы разобрать.

Но если вы хотите способ вставки и извлечения произвольных данных бокового канала в действительный JSON, вот ответ. Мы используем уникальное представление данных в кодировке JSON. Это разрешено ^* во втором разделе RFC в разделе "Пробелы разрешены до или после любого из шести структурных символов".

^* RFC утверждает, что "пробелы разрешены до или после любого из шести структурных символов", не указывая явно строки, числа, "ложь", "истина" и "ноль". Это упущение игнорируется во всех реализациях.

Сначала канонизируйте свой 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;

Ответ 27

Мы используем 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'}

Ответ 28

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Это глупо

На самом деле есть способ добавлять комментарии и оставаться в пределах спецификации (дополнительный анализатор не требуется). Это не приведет к удобочитаемым комментариям без какого-либо анализа.

Вы можете злоупотреблять следующим:

Незначительные пробелы разрешены до или после любого токена. Пробел - это любая последовательность из одной или нескольких следующих кодовых точек: табуляция символов (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 для кодирования/декодирования его на лету).

Я никогда не пробовал этого по понятным причинам, и вы не должны.

Ответ 29

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

{

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

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

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

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

}

Ответ 30

Есть хорошее решение (взломать), которое действительно JSON, НО ЭТО НЕ БУДЕТ РАБОТАТЬ ВО ВСЕХ СЛУЧАЯХ (см. комментарии ниже). Просто сделайте один и тот же ключ дважды (или больше). Например:

{
  "param" : "This is the comment place",
  "param" : "This is value place",
}

Так что JSON будет понимать это как:

{
  "param" : "This is value place",
}