Вопрос:

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

json comments

1824190 просмотра

30 ответа

39028 Репутация автора

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

Автор: Michael Gundlach Источник Размещён: 28.10.2008 08:39

Ответы (30)


101 плюса

13047 Репутация автора

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

Синтаксис JSON представлен на этой странице. Нет комментариев о комментариях.

Автор: Cheery Размещён: 28.10.2008 08:42

4788 плюса

62745 Репутация автора

Решение

Нет.

Все 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"
            }
         }
      }
   }
}
Автор: Eli Размещён: 28.10.2008 09:01

30 плюса

705 Репутация автора

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

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

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

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

Автор: Neil Albrock Размещён: 28.10.2008 11:05

38 плюса

445 Репутация автора

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

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

Автор: John T. Vonachen Размещён: 09.04.2010 10:30

748 плюса

12062 Репутация автора

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

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

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

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

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

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

Автор: Kyle Simpson Размещён: 23.06.2010 06:20

65 плюса

1053 Репутация автора

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

Пример:

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

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

Автор: raffel Размещён: 28.07.2010 06:38

1694 плюса

65635 Репутация автора

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

  • http://www.json.org
  • RFC 4627 : application/jsonтип носителя для нотации объектов JavaScript (JSON)
  • RFC 7159 Формат обмена данными нотации объектов JavaScript (JSON) - устарело: 4627, 7158
Автор: stakx Размещён: 15.11.2010 09:32

22 плюса

1273 Репутация автора

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

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

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

Автор: David Размещён: 18.01.2011 09:57

29 плюса

2596 Репутация автора

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

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

Я думаю, что можно использовать "#": "comment"для «действительного» JSON.

Автор: peterk Размещён: 22.06.2011 01:09

104 плюса

4296 Репутация автора

Подумайте об использовании YAML. Это почти расширенный набор JSON (практически весь действительный JSON является действительным YAML), и он допускает комментарии.

Автор: Marnen Laibow-Koser Размещён: 31.08.2011 02:24

56 плюса

5954 Репутация автора

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

Автор: schoetbi Размещён: 26.10.2011 09:46

405 плюса

11965 Репутация автора

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

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

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

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

Автор: Artur Czajka Размещён: 11.06.2012 08:52

28 плюса

4423 Репутация автора

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

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

Автор: AZ. Размещён: 04.08.2012 12:56

25 плюса

3691 Репутация автора

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

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

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

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

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

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

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

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

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

Автор: Basel Shishani Размещён: 11.12.2012 01:37

28 плюса

8593 Репутация автора

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

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

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

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

Автор: gaborous Размещён: 25.06.2013 02:48

200 плюса

4847 Репутация автора

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Ваша гарантия аннулирована

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

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

Удачного взлома!

Автор: p3drosola Размещён: 02.08.2013 01:46

18 плюса

4729 Репутация автора

Вы можете иметь комментарии в 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. В этом случае комментарии разрешены . Но мое приложение вернуло тип содержимого application/json, поэтому мне пришлось удалить комментарии.

Автор: osa Размещён: 07.10.2013 08:37

12 плюса

824 Репутация автора

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

{

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

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

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

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

}
Автор: Chris Размещён: 29.10.2013 10:30

9 плюса

176 Репутация автора

Вздох. Почему бы просто не добавить поля, например

{
    "note1" : "This demonstrates the provision of annotations within a JSON file",
    "field1" : 12,
    "field2" : "some text",

    "note2" : "Add more annotations as necessary"
}

Просто убедитесь, что ваши имена "notex" не конфликтуют с какими-либо реальными полями.

Автор: Steve Thomas Размещён: 28.11.2013 01:48

10 плюса

1020 Репутация автора

Автор JSON хочет, чтобы мы включили комментарии в JSON, но удалили их перед анализом (см. Ссылку, предоставленную Michael Burr). Если в JSON должны быть комментарии, почему бы не стандартизировать их и позволить анализатору JSON выполнить эту работу? Я не согласен с логикой, но, увы, это стандарт. Использование решения YAML, предложенного другими, хорошо, но требует зависимости от библиотеки.

Если вы хотите удалить комментарии, но не хотите иметь зависимость от библиотеки, вот решение с двумя строками, которое работает для комментариев в стиле C ++, но может быть адаптировано для других:

var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));

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

Еще один способ добиться анализа JSON, удаления комментариев и лишней библиотеки - это оценить JSON в интерпретаторе JavaScript. Разумеется, такой подход заключается в том, что вам нужно только оценивать незапятнанные данные (без ненадежного пользовательского ввода). Вот пример такого подхода в Node.js - еще одна оговорка, в следующем примере данные будут считываться только один раз, а затем они будут кэшироваться:

data = require(fs.realpathSync(doctree_fp));
Автор: Joshua Richardson Размещён: 06.12.2013 09:46

11 плюса

501 Репутация автора

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

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

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

{
  "param" : "This is value place",
}
Автор: Aurimas Размещён: 28.01.2014 03:04

59 плюса

20259 Репутация автора

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

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

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

{
  key: "value" // Comment
}

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

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

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

Автор: Andrejs Размещён: 06.02.2014 08:44

155 плюса

27501 Репутация автора

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

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

Hjson intro

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

Автор: laktak Размещён: 20.03.2014 03:26

17 плюса

21283 Репутация автора

Это вопрос «можете ли вы» . И вот ответ «да» .

Нет, вы не должны использовать дублирующие члены объекта для помещения данных побочного канала в кодировку 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;
Автор: William Entriken Размещён: 24.04.2014 05:23

34 плюса

3989 Репутация автора

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

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

// "id": int

или же

/* Это

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

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

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

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

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

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

Автор: dvdmn Размещён: 25.07.2014 01:43

12 плюса

7131 Репутация автора

Мы используем 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'}
Автор: Joy Размещён: 27.11.2014 11:39

19 плюса

19646 Репутация автора

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

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

Автор: Manish Shrivastava Размещён: 20.07.2015 09:26

22 плюса

762 Репутация автора

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


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

Автор: Smit Johnth Размещён: 24.11.2015 04:34

19 плюса

1653 Репутация автора

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

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

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

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

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

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

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

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

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

Автор: Dominic Cerisano Размещён: 27.11.2015 07:35

46 плюса

4042 Репутация автора

Вот что я нашел в документации по 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"
}
Автор: mana Размещён: 22.06.2017 12:58
Вопросы из категории :
32x32