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

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

• http://www.json.org
• RFC 4627: The application/json тип носителя для обозначения объектов JavaScript (JSON)
• RFC 7159 формат обмена данными JavaScript Object Notation (JSON) - Obsoletes: 4627, 7158

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

Я только что выпустил в формате 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#.

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

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

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

вы должны написать в 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);    

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

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

вот что я нашел в документация 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 on JSON.org.

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

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

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

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

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

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

/ / "name": "string"

/ / "id": int

или

/* Это

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

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

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

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

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

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

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

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

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

посмотреть сайт JSON подробнее.

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

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

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

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

JSON не имеет комментариев. Кодировщик JSON не должен выводить комментарии. Декодер JSON может принимать и игнорировать комментарии.

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

Cf:Дуглас Крокфорд, автор 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!

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

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

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

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

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

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

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

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

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

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

это "можно" вопрос. И вот "да" ответ.

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

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

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

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

во-первых, канонизируйте свой JSON, уменьшив его:

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

затем Закодируйте свой комментарий в двоичном формате:

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

затем steg ваш двоичный файл:

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

вот ваш вывод:

$jsonWithComment = $steg . $jsonMin;

мы используем 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 на части, я добавляю строки "фиктивный комментарий":

{

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

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

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

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

}

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

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

таким образом, JSON поймет это как:

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

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

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

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

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

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

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

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

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

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

data = require(fs.realpathSync(doctree_fp));