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

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

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

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

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

В последней версии nlohmann / json есть дополнительная поддержка игнорирования комментариев при синтаксическом анализе.

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

Пример:

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

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

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

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

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

{
  key: "value" // Comment
}

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

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

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

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

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

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

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

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

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

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

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

НО, как заметил и создатель JSON, всегда существовала поддержка конвейера JS для комментариев:

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

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

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

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

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

// id: int

or

/* Это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Думаю, можно использовать "#": "comment" для «действительного» 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, прежде чем передавать их парсеру!

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

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

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

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

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

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

Отказ от ответственности: это глупо

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

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

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

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

Да, новый стандарт JSON5 разрешает комментарии в стиле C ++, среди многих другие расширения:

// A single line comment.

/* A multi-
   line comment. */

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

Уже существует пакет npm, пакет Python, пакет Java и C-библиотека. Он обратно совместим. Я не вижу причин оставаться с официальными ограничениями JSON.

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

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

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

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

header("My-Json-Comment: Yes, I know it's a workaround ;-) ");

JSON сам по себе не допускает комментариев. Рассуждения совершенно глупы, потому что вы можете использовать JSON сам для создания комментариев, что полностью устраняет рассуждения, и загружает пространство данных парсера без всякой уважительной причины для < em> точно тот же результат и потенциальные проблемы, такие как они: файл JSON с комментариями.

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

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

{
    "Notations": [
        {
            "anchorX": 333,
            "anchorY": 265,
            "areaMode": "Ellipse",
            "extentX": 356,
            "extentY": 294,
            "opacity": 0.5,
            "text": "Elliptical area on top",
            "textX": 333,
            "textY": 265,
            "title": "Notation 1"
        },
        {
            "anchorX": 87,
            "anchorY": 385,
            "areaMode": "Rectangle",
            "extentX": 109,
            "extentY": 412,
            "opacity": 0.5,
            "text": "Rect area\non bottom",
            "textX": 98,
            "textY": 385,
            "title": "Notation 2"
        },
        {
            "anchorX": 69,
            "anchorY": 104,
            "areaMode": "Polygon",
            "extentX": 102,
            "extentY": 136,
            "opacity": 0.5,
            "pointList": [
                {
                    "i": 0,
                    "x": 83,
                    "y": 104
                },
                {
                    "i": 1,
                    "x": 69,
                    "y": 136
                },
                {
                    "i": 2,
                    "x": 102,
                    "y": 132
                },
                {
                    "i": 3,
                    "x": 83,
                    "y": 104
                }
            ],
            "text": "Simple polygon",
            "textX": 85,
            "textY": 104,
            "title": "Notation 3"
        }
    ],
    "imageXW": 512,
    "imageYW": 512,
    "imageName": "lena_std.ato",
    "tinyDocs": {
        "c01": "JSON image notation data:",
        "c02": "-------------------------",
        "c03": "",
        "c04": "This data contains image notations and related area",
        "c05": "selection information that provides a means for an",
        "c06": "image gallery to display notations with elliptical,",
        "c07": "rectangular, polygonal or freehand area indications",
        "c08": "over an image displayed to a gallery visitor.",
        "c09": "",
        "c10": "X and Y positions are all in image space. The image",
        "c11": "resolution is given as imageXW and imageYW, which",
        "c12": "you use to scale the notation areas to their proper",
        "c13": "locations and sizes for your display of the image,",
        "c14": "regardless of scale.",
        "c15": "",
        "c16": "For Ellipses, anchor is the  center of the ellipse,",
        "c17": "and the extents are the X and Y radii respectively.",
        "c18": "",
        "c19": "For Rectangles, the anchor is the top left and the",
        "c20": "extents are the bottom right.",
        "c21": "",
        "c22": "For Freehand and Polygon area modes, the pointList",
        "c23": "contains a series of numbered XY points. If the area",
        "c24": "is closed, the last point will be the same as the",
        "c25": "first, so all you have to be concerned with is drawing",
        "c26": "lines between the points in the list. Anchor and extent",
        "c27": "are set to the top left and bottom right of the indicated",
        "c28": "region, and can be used as a simplistic rectangular",
        "c29": "detect for the mouse hover position over these types",
        "c30": "of areas.",
        "c31": "",
        "c32": "The textx and texty positions provide basic positioning",
        "c33": "information to help you locate the text information",
        "c34": "in a reasonable location associated with the area",
        "c35": "indication.",
        "c36": "",
        "c37": "Opacity is a value between 0 and 1, where .5 represents",
        "c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
        "c39": "backdrop. Recommendation is that regions be drawn",
        "c40": "only if the user hovers the pointer over the image,",
        "c41": "and that the text associated with the regions be drawn",
        "c42": "only if the user hovers the pointer over the indicated",
        "c43": "region."
    }
}