Как сделать комментарий в json файле

Обновлено: 06.07.2024

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

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

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

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

но если вы решили:

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

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

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

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

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

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

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

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

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: ВАША ГАРАНТИЯ НЕДЕЙСТВИТЕЛЬНА

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

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

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

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

Если мы применяем эту технику, ваш прокомментированный JSON файл может выглядеть так:

вышеуказанный код действительный JSON. Если вы проанализируете его, вы получите такой объект:

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

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

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

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

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

вы можете предоставить документацию с помощью описание атрибутов схемы.

если вы используете Джексон как ваш парсер JSON, то вот как вы позволяете ему разрешать комментарии:

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

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

комментарии не являются официальным стандартом. Хотя некоторые анализаторы поддерживает комментарии в стиле C++. Один, который я использую, это JsonCpp. В примерах есть такой:

jsonlint не проверять это. Таким образом, комментарии являются конкретным расширением парсера, а не стандартным.

вот что я нашел в документация Google Firebase это позволяет вам помещать комментарии в JSON:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

если вы перейдете по ссылке, вы увидите

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

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

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

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

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

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

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

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

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

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

Однако есть и обходной путь. И эта статья посвящена именно ему.

Добавляйте данные в виде комментариев

Чтобы обойти проблему комментариев, добавьте в свой файл JSON данные, которые функционируют как комментарии.

Давайте рассмотрим это на примере. Начнем с файла JSON, в котором содержится следующая информация:

Теперь давайте добавим еще одну пару ключ-значение, чтобы она служила для нас комментарием — как вы можете видеть в первой строке кода ниже:

Вот еще один пример. На этот раз мы используем два подчеркивания — в начале и в конце ключа:

Подчеркивание помогает отличить комментарий от остальных данных в файле.

Небольшое предостережение

Есть одна важная деталь, которую нужно иметь в виду.

Комментарии, которые мы добавили в файл JSON, включены в объект JSON. Другими словами, комментарии рассматриваются как данные.

Вот что имеется в виду.

Теперь мы собираемся прочитать эти данные из файла read_comments.py :

Результат включает в себя наш комментарий:

Мы даже можем извлечь значение комментария из объекта JSON: this is my comment :

Имейте в виду, что такой комментарий является комментарием только в глазах разработчика, а не компьютера.

Другой тип комментария

Эта практика комментирования JSON отличается от комментариев в языках программирования, таких как Python, которые обычно игнорируются при запуске программы.

Когда мы запускаем программу Python, приведенную выше, мы получаем буквы в слове “house”. Но мы не видим комментария. Он был проигнорирован.

Варианты комментирования

JSMin — это еще один вариант, стоящий рассмотрения.

Это инструмент, который удаляет лишние пробелы и комментарии из файлов JavaScript. Но он также работает и с файлами JSON. JSMin удаляет комментарии из файлов JSON до того, как они будут обработаны.

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

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

Однако есть и обходной путь. И эта статья посвящена именно ему.

Добавляйте данные в виде комментариев

Чтобы обойти проблему комментариев, добавьте в свой файл JSON данные, которые функционируют как комментарии.

Давайте рассмотрим это на примере. Начнем с файла JSON, в котором содержится следующая информация:

Вот еще один пример. На этот раз мы используем два подчеркивания — в начале и в конце ключа:

" comment2 ": "здесь другой комментарий",

Подчеркивание помогает отличить комментарий от остальных данных в файле.

Небольшое предостережение

Есть одна важная деталь, которую нужно иметь в виду.

Вот что имеется в виду.

Теперь мы собираемся прочитать эти данные из файла read_comments.py:

Результат включает в себя наш комментарий:

Мы даже можем извлечь значение комментария из объекта JSON: this is my comment:

Имейте в виду, что такой комментарий является комментарием только в глазах разработчика, а не компьютера.

Другой тип комментария

Эта практика комментирования JSON отличается от комментариев в языках программирования, таких как Python, которые обычно игнорируются при запуске программы

Варианты комментирования

JSMin — это еще один вариант, стоящий рассмотрения.

Однако есть и обходной путь. И эта статья посвящена именно ему.

Добавляйте данные в виде комментариев

Чтобы обойти проблему комментариев, добавьте в свой файл JSON данные, которые функционируют как комментарии.

Давайте рассмотрим это на примере. Начнем с файла JSON, в котором содержится следующая информация:

Вот еще один пример. На этот раз мы используем два подчеркивания — в начале и в конце ключа:

Подчеркивание помогает отличить комментарий от остальных данных в файле.

Небольшое предостережение

Есть одна важная деталь, которую нужно иметь в виду.

Вот что имеется в виду.

Теперь мы собираемся прочитать эти данные из файла read_comments.py :

Результат включает в себя наш комментарий:

Мы даже можем извлечь значение комментария из объекта JSON: this is my comment :

Имейте в виду, что такой комментарий является комментарием только в глазах разработчика, а не компьютера.

Другой тип комментария

Варианты комментирования

JSMin — это еще один вариант, стоящий рассмотрения.

Читайте также: