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

Question

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

Это вопрос "Можете ли вы" . А вот ответ "да" .

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

Answer 5

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

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

{

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

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

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

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

}

Answer 8

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

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

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

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

Answer 9

Автор 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));

Answer 10

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

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

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

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