Можно ли использовать комментарии в JSON?
https://stackoverflow.com/questions/244777
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Могу ли я использовать комментарии внутри файла 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 7159 Формат обмена данными JavaScript Object Notation (JSON) — устарел:4627, 7158
Включайте комментарии, если хотите; перед анализом или передачей удалите их с помощью минификатора.
Я только что выпустил JSON.minify () . комментарии и пробелы из блока JSON и делает его действительным JSON, который может быть проанализирован. Таким образом, вы можете использовать его следующим образом:
JSON.parse(JSON.minify(my_str));
Когда я выпустил его, я получил огромное количество людей, не согласных даже с его идеей, поэтому я решил написать исчерпывающее сообщение в блоге о том, почему комментарии имеют смысл в JSON . Он включает в себя этот заметный комментарий от создателя JSON:
Предположим, вы используете JSON для хранения файлов конфигурации, которые вы хотите аннотировать. Идите вперед и вставьте все комментарии, которые вам нравятся. Затем передайте его через JSMin, прежде чем передать его вашему анализатору JSON. - Дуглас Крокфорд, 2012
Надеюсь, это полезно для тех, кто не согласен с тем, почему JSON.minify () может быть полезным.
Комментарии были удалены из JSON по замыслу.
Я удалил комментарии из JSON, потому что видел, что люди использовали их для хранения директив синтаксического анализа, что привело к разрушению совместимости. Я знаю, что отсутствие комментариев делает некоторых людей грустными, но это не должно.
Предположим, вы используете JSON для хранения файлов конфигурации, которые вы хотите аннотировать. Идите вперед и вставьте все комментарии, которые вам нравятся. Затем передайте его через JSMin, прежде чем передать его в свой анализатор JSON.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: ВАША ГАРАНТИЯ АННУЛИРОВАНА
Как уже указывалось, этот хак использует преимущества реализации спецификации. Не все анализаторы 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 представлен на этой странице. Нет комментариев о комментариях.
Вам следует написать Схема 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 TOML .
Еще одна альтернатива - jsonc .
Вот что я нашел в документации 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, будет прочитан какой-либо программой, насколько сложно будет удалить комментарии в стиле C или C ++ перед его использованием?
Ответ. Это будет один вкладыш. Если вы сделаете это, файлы JSON могут быть использованы в качестве файлов конфигурации.
Если вы используете библиотеку Newtonsoft.Json с ASP.NET для чтения/десериализации, вы можете использовать комментарии в содержимом JSON:
//"имя":"нить"
//"идентификатор":интервал
или
/* Это
пример комментария */
ПС: Однострочные комментарии поддерживаются только версиями Newtonsoft Json 6+.
Дополнительное примечание для людей, которые не умеют мыслить нестандартно: Я использую формат JSON для основных настроек в созданном мной веб-приложении ASP.NET.Я читаю файл, конвертирую его в объект настроек с помощью библиотеки Newtonsoft и использую при необходимости.
Я предпочитаю писать комментарии к каждому отдельному параметру в самом файле JSON, и меня действительно не волнует целостность формата JSON, если используемая мной библиотека с ним в порядке.
Я думаю, что это «более простой в использовании/понимании» способ, чем создание отдельного файла «settings.README» и объяснение настроек в нем.
Если у вас возникли проблемы с таким использованием;извините, джинн вышел из лампы.Люди найдут другое применение формату JSON, и с этим ничего не поделаешь.
Идея JSON - обеспечить простой обмен данными между приложениями. Обычно это веб-интерфейс, а язык - JavaScript.
Это на самом деле не допускает комментариев как таковых, однако передача комментария в качестве одной из пар имя / значение в данных, безусловно, будет работать, хотя эти данные, очевидно, должны игнорироваться или обрабатываться определенным образом кодом синтаксического анализа. .
Все это говорит о том, что файл JSON не должен содержать комментарии в традиционном смысле. Это должны быть только данные.
Подробнее об этом можно узнать на веб-сайте JSON .
Я только что столкнулся с этим для файлов конфигурации. Я не хочу использовать XML (многословно, графически, некрасиво, трудно читаемо) или " ini " формат (без иерархии, без реального стандарта и т. д.) или Java " Свойства " формат (как .ini).
JSON может делать все, что может, но это гораздо менее многословно и более читабельно, а синтаксические анализаторы просты и повсеместно распространены во многих языках. Это просто дерево данных. Но внеплановые комментарии часто необходимы для документирования " default " конфигурации и тому подобное. Конфигурации никогда не должны быть «полными документами», а деревьями сохраненных данных, которые могут быть удобочитаемыми при необходимости.
Полагаю, можно использовать " # " ;: " комментарий " для " действительного " JSON.
JSON изначально не поддерживает комментарии, но вы можете сделать свой собственный декодер или, по крайней мере, препроцессор для удаления комментариев, это прекрасно (если вы просто игнорируете комментарии и не используете их для руководства обработкой вашего приложения) данные JSON).
JSON не имеет комментариев. Кодер JSON НЕ ДОЛЖЕН выводить комментарии. Декодер JSON МОЖЕТ принимать и игнорировать комментарии.
Комментарии никогда не должны использоваться для передачи чего-либо значимого. То есть для чего нужен 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-файлов перед передачей их парсеру!
JavaScript-инструментарий Dojo Toolkit (по крайней мере, начиная с версии 1.4) позволяет включать комментарии в JSON. Комментарии могут быть в формате / * * / . Dojo Toolkit использует JSON через вызов dojo.xhrGet () .
Другие наборы инструментов JavaScript могут работать аналогично.
Это может быть полезно при экспериментировании с альтернативными структурами данных (или даже списками данных) перед выбором окончательного варианта.
Если вы используете JSON5 , вы можете добавлять комментарии.
<Ч>JSON5 - это предлагаемое расширение JSON , целью которого является облегчение для людей написания и поддержки вручную. Это достигается путем добавления некоторых минимальных синтаксических функций непосредственно из ECMAScript & nbsp; 5.
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 раньше поддерживал комментарии, но они были нарушены и удалены из стандарта.
От создателя JSON:
Я удалил комментарии из JSON, потому что видел, что люди использовали их для хранения директив синтаксического анализа, что привело к разрушению совместимости. Я знаю, что отсутствие комментариев делает некоторых людей грустными, но это не должно. - Дуглас Крокфорд, 2012
Официальный сайт JSON находится по адресу JSON.org . JSON определяется как стандарт ECMA International как . Всегда есть ходатайство о пересмотре стандартов. Маловероятно, что аннотации будут добавлены в стандарт JSON по нескольким причинам.
JSON по своему замыслу - это легко модифицируемая (анализируемая человеком) альтернатива XML. Это упрощено даже до такой степени, что аннотации не нужны. Это даже не язык разметки. Цель - стабильность и интероперабельность.
Любой, кто понимает «имеет-а» Отношение объектной ориентации может понять любая структура JSON - вот и весь смысл. Это просто ориентированный ациклический граф (DAG) с тегами узлов (пары ключ / значение), который является почти универсальной структурой данных.
Единственной необходимой аннотацией может быть " // Это теги DAG " ;. Имена ключей могут быть настолько информативными, насколько это необходимо, что допускает произвольную семантическую арность.
Любая платформа может анализировать JSON всего за несколько строк кода. XML требует сложных OO-библиотек, которые нежизнеспособны на многих платформах.
Аннотации просто сделают JSON менее совместимым. Просто добавить больше нечего, если только вам действительно не нужен язык разметки (XML), и вам не важно, легко ли анализируются ваши сохраненные данные.
Это " вы можете " вопрос. А вот ответ " да " .
Нет, вы не должны использовать дублирующие члены объекта для помещения данных побочных каналов в кодировку JSON. (См. & Quot; имена в объекте ДОЛЖНЫ быть уникальными в 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;
Мы используем 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"
}
Есть хорошее решение (хак), которое является допустимым JSON. Просто сделайте один и тот же ключ дважды (или больше). Например:
{
"param" : "This is the comment place",
"param" : "This is value place",
}
Так что JSON поймет это как:
{
"param" : "This is value place",
}
Автор JSON хочет, чтобы мы включали комментарии в JSON, но удаляли их перед анализом (см. связь предоставлено Майклом Берром).Если в 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));
Вздох.Почему бы просто не добавить поля, например.
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
Просто убедитесь, что ваши имена «notex» не конфликтуют с реальными полями.
