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

7614

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

Майкл Гундлах
источник
153
@StingyJack: Объяснить то, что может быть неочевидным, или что-либо еще, что можно сделать с комментариями. У меня часто есть комментарии в файлах данных. XML, INI-файлы и многие другие форматы содержат положения для комментариев.
Майкл Берр
24
Если вам, как и мне, было интересно, //commentsвсе ли в порядке для конкретного варианта использования файла конфигурации Sublime Text, ответ - да (по состоянию на версию 2). Sublime Text не будет жаловаться на это, по крайней мере, тогда как будет жаловаться {"__comment": ...}в консоли, потому что это неожиданное поле.
Driftcatcher
8
и, возможно, это одна из причин, почему TOML был создан ..
Алекс Nolasco
10
Немного нудистский, но я также попытался использовать // для комментариев в JSON. Теперь я понимаю, что он строго используется для обмена / обмена. Вздох! Я больше не могу комментировать :(. Жизнь обречена !.
Сид
12
JSON5 поддерживает комментарии: stackoverflow.com/a/7901053/108238
schoetbi

Ответы:

5597

Нет.

Все 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"
            }
         }
      }
   }
}
Eli
источник
233
Возможно, стоит иметь какой-то префикс для реального комментария в случае, если когда-нибудь будет действительное поле с именем comment:"__comment":"comment text goes here...",
Rob Fonseca-Ensor
19
Кстати, в библиотеке json для Java google-gson есть поддержка комментариев.
centic
11
А что , если я хотел отдельный комментарий на Accronymи Abbrevсвойства? Я использовал этот шаблон раньше, но остановился, так как он не позволяет мне это сделать. Это взломать Может быть, если я добавлю имя свойства __comment__вместо. Это «__comment__Abbrev», все еще взломанный, но позвольте мне прокомментировать все свойства
Хуан Мендес,
41
Вы также можете использовать «//»: это выглядит более
нативно
4
Когда JSON используется для пользовательских конфигурационных файлов, они должны быть аннотированы, чтобы люди лучше понимали. Аннотированный, такой файл больше не является допустимым JSON, но есть решения. Например, Google GYP поддерживает комментарии в стиле #. JSON.Minify поможет вам отбросить комментарии в стиле C / C ++ из вашего входного файла.
Петър Петров
1842

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

  • http://www.json.org
  • RFC 4627 : application/jsonтип носителя для нотации объектов JavaScript (JSON)
  • RFC 8259 Формат обмена данными нотации объектов JavaScript (JSON) (заменяет RFC 4627, 7158, 7159)
Stakx - больше не помогает
источник
67
Если вы хотите аннотировать ваш JSON комментариями (что делает его недействительным JSON), то сверните его перед анализом или передачей. Сам Крокфорд признал это в 2012 году в контексте файлов конфигурации.
toolbear
25
@alkuzad: Когда дело доходит до формальных грамматик, там должно быть что - то , что явно говорит , что они будут разрешены, а не наоборот. Например, возьмите выбранный вами язык программирования: просто потому, что какая-то желаемая (но отсутствующая) функция явно не запрещена, это не означает, что ваш компилятор ее волшебным образом распознает.
stakx - больше не вносит вклад
5
Да. Формат JSON имеет много мертвого пространства между элементами и нечувствителен к пространству в этих регионах, поэтому нет причин, по которым у вас не может быть однострочных или многострочных комментариев. Многие парсеры и минификаторы также поддерживают комментарии JSON, поэтому просто убедитесь, что ваш парсер поддерживает их. JSON широко используется для данных приложения и настроек конфигурации, поэтому комментарии необходимы сейчас. «Официальная спецификация» - хорошая идея, но она недостаточна и устарела, так что это очень плохо. Сократите свой JSON, если вы беспокоитесь о размере или производительности полезной нагрузки.
Трийнко
58
Хотя ваш ответ абсолютно верен, следует сказать, что это BS. Поскольку так много конечных пользователей сталкиваются с необходимостью настройки JSON, комментарии чрезвычайно полезны. То, что некоторые шляпы из оловянной фольги решили, что JSON является и всегда должен быть машиночитаемым, игнорируя тот факт, что люди должны читать его, - это просто пародия на малозаметность.
cmroanirgo
18
@cmroanirgo: Вы, очевидно, не первый, кто жаловался на это ограничение JSON ... поэтому у нас есть парсеры, которые молча допускают комментарии и другие форматы, такие как YAML и JSON5. Однако это не меняет того факта, что JSON является тем, чем он является. Скорее, мне интересно, что люди начали использовать JSON для целей, в которых его явно было недостаточно, учитывая данное ограничение. Не вините формат JSON; вините себя в том, что вы настаивали на том, чтобы использовать его там, где это не очень хорошо подходит
stakx - больше не участвует
802

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

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

JSON.parse(JSON.minify(my_str));

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

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

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

Кайл Симпсон
источник
153
Единственная проблема, которую я имею с JSON.minify (), заключается в том, что он действительно очень медленный. Поэтому я сделал свою собственную реализацию, которая делает то же самое: gist.github.com/1170297 . На некоторых больших тестовых файлах ваша реализация занимает 74 секунды, а мои 0,06 секунды.
WizKid
56
было бы здорово, если бы вы могли представить предложенный альтернативный алгоритм в репозиторий github для JSON.minify (), чтобы его можно было перенести на все поддерживаемые языки: github.com/getify/json.minify
Кайл Симпсон,
16
@MiniGod Я уже много раз слышал мысли Дуга на эту тему. Я обращался к ним давно в своем блоге: blog.getify.com/json-comments
Кайл Симпсон
18
@ MarnenLaibow-Koser, есть все еще допустимые применения для комментариев даже для использования потока данных (или даже пакета): включение диагностических метаданных, таких как время создания или источники, является обычным использованием в XML, и также очень удобно для данных JSON. Аргументы против комментариев поверхностны, и любой текстовый формат данных должен допускать комментарии, независимо от предполагаемого предполагаемого использования (ничто не говорит о том, что JSON нельзя использовать где-либо еще, fwiw)
StaxMan,
18
Если JSON должен иметь универсальное признание (что он в основном делает), то он должен иметь универсальное применение. Пример: JSON может служить файлом конфигурации приложения. Это приложение будет иметь комментарии.
eggmatters
441

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

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

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

Источник: Публичное заявление Дугласа Крокфорда на G +

Артур Цайка
источник
198
Я думал, что JSON должен был быть более читабельным, чем, скажем, XML? Комментарии для удобства чтения.
intrepidis
25
В любом случае, вы можете быть непослушными и добавить директивы синтаксического анализа в JSON: {"__directives": {"# n #": "DateTime.Now"}, "validdate": "# n #"} ... Это похоже на YAML тогда путь вперед ...
intrepidis
73
Личное мнение: не разрешать комментировать это хромает. У меня не было другого выбора, кроме как создать нестандартный анализатор JSON, который игнорирует комментарии, для декодирования моих файлов конфигурации.
caiosm1005
17
@ArturCzajka Мне все еще не нравится тот факт, что JSON не поддерживает комментарии, но я дал INI попытку, и должен признать, что гораздо разумнее использовать их через JSON для конфигурационных файлов. Спасибо за ответ и, надеюсь, больше людей передумают, когда будут читать этот разговор. (в любом случае создание парсера было скорее упражнением :)
caiosm1005
77
Это все равно что требовать, чтобы у всех велосипедов были тренировочные колеса, потому что некоторые люди не могут ездить на велосипедах. Удаление важной функции, потому что глупые люди ругают это плохой дизайн. Формат данных должен отдавать предпочтение удобству использования, а не защищать от идиотов.
Фил Гетц
205

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Ваша гарантия аннулирована

Как уже указывалось, этот хак использует преимущества реализации спецификации. Не все анализаторы 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]
}

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

Счастливого взлома!

p3drosola
источник
150
Из спецификации : Имена внутри объекта ДОЛЖНЫ быть уникальными.
Квентин
113
«Все реализации обрабатывают это одинаково» - это трудно доказать.
Квентин
91
Порядок элементов в JSON не гарантируется. Это означает, что «последний» элемент может измениться!
Sep332
66
Это явно нарушает спецификацию (см. Комментарии выше), не делайте этого. ietf.org/rfc/rfc4627.txt?number=4627
voidlogic
334
НЕТ - что, если парсер потоковый? Что если парсер считывает его в словарь, в котором порядок ключей не определен? убить это огнем .
Дин Уомбурн
184

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

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

Hjson intro

См. Hjson.org для библиотек JavaScript, Java, Python, PHP, Rust, Go, Ruby и C #.

laktak
источник
13
Upvoted. Это, очевидно, хорошая вариация, когда открытые консервативные люди просто хотели бы ненавидеть. Я надеюсь, что ваша реализация станет известна дальше - и, возможно, даже станет более популярной, чем оригинал;) Я надеюсь, что кто-то также сможет реализовать ее с Ruby. @adelphus Язык, который четко определен, - это ваша собственная точка зрения или мнение. Быть консервативным «разработчиком», если вы один, не доказывает, что вы лучше, и вы могли бы быть еще хуже, если бы вы были заперты в ограниченном пространстве. Не поймите людей, как ужасных разработчиков, легко.
konsolebox
7
К сожалению об этом, @konsolebox. Возможно, вы могли бы пересмотреть свое мнение «четко определенный JSON - ваше мнение» после прочтения ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf Это настоящий стандарт, и разработчики реализуют свои собственные «специальные» версии. приводит к фрагментации, растерянности и много потерянного времени. Посмотрите на беспорядок, который оставляют веб-разработчики при написании кода только потому, что каждый браузер реализует несколько разные версии стандартов. Язык JSON может быть не идеальным, но фрагментация хуже. И да, это просто мнение, и вы можете не согласиться.
adelphus
22
Я восхищаюсь вашим мнением, но вы как будто заново изобретаете YAML. Если вам нужна большая гибкость и удобочитаемость, используйте YAML (на самом деле не: stackoverflow.com/questions/450399/… ) или придерживайтесь мошенничества, но однозначного JSON.
toolbear
4
Я считаю, что наиболее удобный формат конфигурации по-прежнему INI. Это просто и не очень тяжелый синтаксис. Это делает его менее пугающим для пользователей, просто опускающих пальцы в пруд конфигурации.
Мэтт
14
Всякий раз , когда вам нужно , как JSON конфигурации (где комментарии являются необходимо) - имя файла «.js» вместо «.json» .. JS может конечно обрабатывать любой действительный объект JSON и дополнительно может обрабатывать комментарии .. Вот причина , почему "webpack.config.js", а не "webpack.config.json" (ну, есть и много других причин для этого в веб-пакете: P)
Джебби
122

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

Марнен Лайбоу-Козер
источник
12
@ g33kz0r Правильно, отсюда и мое описание YAML как почти супернабора JSON.
Марнен Лайбоу-Козер
12
@NateS Многие люди уже указали, что ответ был отрицательным. Я предложил лучший способ достижения цели ОП. Это ответ.
Марнен Лайбоу-Козер
5
Недостаток: yamlбиблиотека не поставляется с Python.
Кровоточащие пальцы
6
@ marnen-laibow-koser: да, должно быть, было некомпетентно использовать доступные библиотеки YAML для Java и Perl и ожидать, что созданный каждым YAML будет использован другим без ошибок. То, что взаимодействие с YAML было проблемой, но взаимодействие с JSON не было, полностью объясняется моим недостатком знаний.
toolbear
3
@ marnen-laibow-koser, формат, который выполняет то же самое с более простой спецификацией, тем лучше. Прагматичный формат с идеальными реализациями лучше, чем идеальный формат с несовершенными реализациями. Не вся вина за неисправные библиотеки лежит на плечах разработчиков; спецификация YAML длинная, плотная и тупая. Его статья в Википедии приводит два примера неясностей; если нужно поместить излучатель между человеком и форматом, чтобы защитить его от двусмысленностей, формат теряет свою дружественную для человека претензию. JSON требует меньше и в основном добивается успеха там, где YAML требует больше и терпит неудачу.
toolbear
108

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

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

бодрый
источник
67

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

schoetbi
источник
Groovy имеет несколько встроенных классов для обработки JSON . JsonSlurper может обрабатывать комментарии. Конечно, комментарии не допускаются в официальной спецификации, поэтому такое поведение в любом парсере нестандартно и непереносимо.
Изрик
Newtonsoft Json.NET также поддерживает комментарии в стиле C без проблем
Макс
66

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

Пример:

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

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

Raffel
источник
5
Схема JSON жива? Он существует, но поддерживается ли он какой-либо известной библиотекой?
Munhitsu
1
да, группа json-schema google довольно активна, и я бы порекомендовал JSV для хорошей реализации JavaScript для валидатора JSON Schema.
Раффель
5
Это помогает только со структурированной документацией, а не со специальной документацией
Хуан Мендес
Если вы используете clojure (и я уверен, что вы этого не сделаете), здесь есть разумно представленный синтаксический анализатор JSON-схемы с открытым исходным кодом: github.com/bigmlcom/closchema
charleslparker
@Munhitsu Manatee.Json (.Net) широко поддерживает схему JSON.
gregsdennis
64

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

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

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

{
  key: "value" // Comment
}

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

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

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

Андрейс
источник
50

Вот что я нашел в документации по 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"
}
мана
источник
К вашему сведению, база данных Firebase Realtime не позволяет использовать «/» в ключе. так что это может быть хорошим соглашением для вашего собственного использования, но вы не можете сделать это в Firebase
gutte
5
Этот метод ломает некоторые библиотеки, которые требуют, чтобы ключ был уникальным. Я работаю над этой проблемой путем нумерации комментариев.
MovGP0
хороший комментарий, я нашел этот вопрос на SO ... эта часть, кажется, не охвачена спецификацией stackoverflow.com/questions/21832701/…
мана
4
В настоящее время я использую его следующим образом: {"// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} Вы можете использовать массив для нескольких комментариев: {"// foo": ["foo comment 1", "foo comment 2"], "foo comment:" 'foo value "}
MovGP0
47

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

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

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

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

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

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

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

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

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

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

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

Доминик Черизано
источник
37

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

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

Джон Т. Воначен
источник
1
Вероятно, лучшее предложение на данный момент, хотя все еще остается проблема сохранения файлов в качестве формата обмена, так как они требуют предварительной обработки перед использованием.
Orbling
Я согласен и написал анализатор JSON на Java, доступный по адресу www.SoftwareMonkey.org, который делает именно это.
Лоуренс Дол
2
Несмотря на то, что я думаю, расширять JSON (не называя его другим форматом обмена) не очень хорошая идея: обязательно игнорируйте «комментарии» в строках. {"foo": "/ * Это не комментарий. * /"}
stofl
27
"... было бы одним слоем" ммм, нет, на самом деле, JSON не является регулярной грамматикой, где регулярное выражение может просто найти совпадающие пары / *. Вы должны проанализировать файл, чтобы найти, появляется ли / * внутри строки (и игнорировать ее), или если он экранирован (и игнорировать его), и т. Д. Кроме того, ваш ответ бесполезен, потому что вы просто размышляете (неправильно), а не предоставляете любое решение.
Кайл Симпсон
1
Что сказал @ Кайл-Симпсон. Кроме того, он слишком скромен, чтобы направлять читателей к своему собственному ответу об использовании JSON.minify в качестве альтернативы специальным регулярным выражениям. Делай это, а не это.
toolbear
36

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

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

// "id": int

или

/* Это

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

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

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

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

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

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

dvdmn
источник
Трудно понять, почему у кого-то возникают проблемы с констатацией факта.
dvdmn
Я предположил бы, что кто-то взял исключение, потому что вышеупомянутое больше не является JSON или является недействительным JSON. Возможно, добавление короткого заявления об ограничении ответственности могло бы удовлетворить.
toolbear
5
Я полностью согласен с вами, и тем не менее до сих пор существует 883 возражений за отсутствие ответа, в котором говорится только об очевидном. Идеологическая чистота ценится выше полезной информации, это так для вас.
Джон
Дело в том, что файл с комментариями не является JSON и не сможет быть проанализирован многими библиотеками JSON. Не стесняйтесь делать все, что вы хотите в вашей собственной программе, но файл с комментариями не является JSON. Если вы утверждаете, что это так, то люди попытаются проанализировать его по своему выбору языка / библиотеки, и это не получится. Это все равно что спросить, можете ли вы использовать квадратные скобки вместо угловых скобок в XML. Вы можете делать все, что хотите, но это больше не будет XML.
Ган
32

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

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

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

Загляните на сайт JSON для более подробной информации.

Нил Альброк
источник
17
Это правда, что формат JSON не имеет комментариев. Лично я считаю, что это существенная ошибка - возможность иметь комментарии в виде метаданных (не данных) - очень полезная вещь в xml. Более ранние версии спецификации JSON содержали комментарии, но по какой-то причине они были отброшены. : - /
StaxMan
4
@StaxMan они были отброшены именно потому, что люди начали использовать их в качестве метаданных. Крокфорд сказал, что это нарушило совместимость формата, и я согласен: если вам нужны метаданные, почему бы не включить их в качестве фактических данных? Еще проще разобрать таким образом.
Камило Мартин
6
Метаданные принадлежат конструкциям метаданных (например, тегам HTML <meta>), а не комментариям. Злоупотребление комментариями для метаданных - это просто хак, используемый, когда не существует истинной конструкции метаданных.
Марнен Лайбоу-Козер
Именно поэтому он был отброшен: комментарии, используемые в качестве метаданных, нарушали бы совместимость. Вы должны просто хранить свои метаданные как JSON.
Габорист
1
Этот ответ является избыточным с лучше написанными ответами с более высоким голосом, которые говорят по существу то же самое, хотя это, возможно, было написано ранее. Такова жизнь.
toolbear
29

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

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

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

peterk
источник
4
Для конфигурационных файлов я бы предложил YAML, а не JSON. Это (почти) более мощный расширенный набор JSON, но также поддерживает более удобочитаемые конструкции, включая комментарии.
Марнен Лайбоу-Козер
1
Как вы думаете, сколько языков поддерживает YAML из коробки по сравнению с json?
ммм
@Hamidam Более десятка языков поддерживают yaml: yaml.org - но вы правильно спросите, у скольких из них есть встроенная поддержка без необходимости сторонней зависимости от библиотеки. Похоже, Ruby 1.9.2 делает. Кто-нибудь знает других? А какие языки поставляют поддержку json по умолчанию?
nealmcb
5
Взаимодействие YAML - ложь: stackoverflow.com/questions/450399/… . Если ваш инстинкт заключается в использовании JSON для файлов конфигурации, следуйте ему.
toolbear
Это старый, но я считаю, что использование # не очень хорошая идея. Json близок к синтаксису букв Javascript. Javascript поддерживает 2 типа комментариев: // и / * ... * / На вашем месте я бы придерживался одного или обоих этих типов комментариев.
Паскаль Ганай,
28

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

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

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

Ср .: Дуглас Крокфорд, автор JSON spec .

gaborous
источник
4
Позже Крокфорд продолжал писать: «Предположим, вы используете JSON для хранения файлов конфигурации, которые вы хотели бы аннотировать. Продолжайте и вставьте все комментарии, которые вам нравятся. Затем передайте их через JSMin, прежде чем передать их в свой анализатор JSON». См. Ответ @ kyle-simpson о JSON.minify для получения дополнительной информации.
toolbear
28

Это зависит от вашей библиотеки JSON. Json.NET поддерживает комментарии в стиле JavaScript /* commment */.

Смотрите другой вопрос переполнения стека .

AZ.
источник
И я считаю, что именно поэтому я вижу комментарий на скриншоте на этой странице предварительного просмотра ASP.NET vNext (в package.json): blogs.msdn.com/b/webdev/archive/2014/06/03/… хотя у меня и нет Пока ничего не нашел в спецификации.
webXL
27

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

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

  • JSON-COM: JSON в сети или правила, которые применяются при передаче данных JSON.
  • JSON-DOC: документ JSON или JSON в файлах или локально. Правила, которые определяют действительный документ JSON.

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

Относительно замечания, сделанного Дугласом Крокфордом по этому вопросу (ссылка @Artur Czajka)

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

Мы говорим о типовой проблеме в конфигурационном файле (на разных языках / платформах), и он отвечает специальной утилитой JS!

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

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

Базель Шишани
источник
Нет необходимости фрагментировать JSON. JSON с комментариями больше не является JSON. Но вполне допустимо аннотировать ваш JSON комментариями, если вы обязательно удалите их перед анализом или передачей. Это никогда не должно быть обязанностью получателя сделать это.
toolbear
json5.org - это решение для json-doc
Майкл Фрейдгейм
24

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


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

Смит Джонт
источник
5
Не могли бы вы добавить пример? Тогда вам могут понадобиться эти дополнительные символы.
dgilperez
6
Это требуется руководящими принципами SO, чтобы обеспечить фактический ответ. Ответы только на ссылки не желательны. Вы можете ознакомиться с инструкциями stackoverflow.com/help/how-to-answer
dgilperez
2
SO модерируется его пользователями. Это означает, что я могу дать ответ, если он у меня есть, точно так же, как я могу прокомментировать ваш, если он не следует указаниям. Вот так SO становится отличным ресурсом.
dgilperez
22

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

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

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

Дэвид
источник
4
Нет, не это У JSON нет комментариев. Если вы решили аннотировать ваш JSON комментариями, уменьшите его перед анализом или передачей. Это не должно быть ответственностью получателя.
toolbear
2
Я не говорил, что у JSON есть комментарии. Я также не имел в виду, что целесообразно включать их в ваш JSON, особенно в производственную систему. Я сказал, что инструментарий Dojo позволяет вам добавлять их, что на самом деле (или, по крайней мере, было) действительно верно. Есть очень полезные сценарии использования для этого на этапе тестирования.
Дэвид
1
Плохо вуду подавать комментарии, и, следовательно, недействительный JSON, который dojo.xhrGet()неявно поощряет принятие.
toolbear
Я все еще голосую за обновление спецификации JSON, чтобы разрешить комментарии. Я полностью за то, что минимизирую и разбираю комментарии перед передачей JSON, но не имею возможности комментировать ваш JSON любым стандартным способом без необходимости передавать его через отдельную утилиту перед анализом, это просто глупо. Я также делаю невозможным использование редактора JSON для ваших файлов конфигурации JSON, потому что ваши файлы не являются допустимыми JSON.
Крейг,
20

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

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

Маниш Шривастава
источник
18

Вы можете иметь комментарии в 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]
]);

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

В конце концов я просто отправил HTTP-запрос вручную по указанному выше адресу и понял, что это тип контента, text/javascriptтак как, ну, JSONP возвращает чистый JavaScript. В этом случае комментарии разрешены . Но мое приложение вернуло content-type application/json, поэтому мне пришлось удалить комментарии.

OSA
источник
17

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

Нет, вы не должны использовать дублирующие члены объекта для помещения данных побочного канала в кодировку 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;
Уильям Энтрикен
источник
1
RFC только заявляет, что «пробел разрешен до или после любого из шести структурных символов», без явного упоминания строк, чисел, «false», «true», «null». Это упущение игнорируется во ВСЕХ реализациях.
Уильям Энтрикен,
1
Для большей плотности комментариев, не могли бы вы закодировать свой комментарий в тройной форме и использовать пробел, табуляцию и символ новой строки для его добавления?
Клэр Нильсен
НЕ ДОЛЖЕН. См. Явно включенный RFC 2119: ДОЛЖЕН: Это слово или термины «ОБЯЗАТЕЛЬНО» или «ДОЛЖНО» означают, что определение является абсолютным требованием спецификации. ... ДОЛЖНО: Это слово или прилагательное "РЕКОМЕНДУЕТСЯ" означают, что могут существовать веские причины в определенных обстоятельствах игнорировать конкретный элемент, но все значения должны быть поняты и тщательно взвешены, прежде чем выбрать другой курс.
Джефф К
Хорошая ссылка. Лучшим аргументом против использования дублированных ключей является цитата стандарта: «Когда имена внутри объекта не являются уникальными, поведение программного обеспечения, получающего такой объект, непредсказуемо». Также теперь я понимаю, почему стандарт не был «ДОЛЖЕН быть уникальным», это упрощает валидатор, ему нужно только отслеживать [и {, ему не нужно знать, какие ключи уже использовались.
Уильям Энтрикен
16

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Это глупо

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

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

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

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

Рой Принс
источник
12

Мы используем 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больше не является допустимым JSON, когда он включает в себя эти комментарии.
Рой Принс
12

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

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

Введите описание изображения здесь

WilliamK
источник
12

JSON сам по себе не позволяет комментировать. Рассуждения совершенно глупы, потому что вы можете использовать сам JSON для создания комментариев, который полностью устраняет рассуждения и загружает пространство данных анализатора без какой-либо веской причины для абсолютно одинакового результата и потенциальных проблем, таких как они: 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."
    }
}
fyngyrz
источник
Ссылка «аргументация» не работает. Есть ли шанс найти текущую ссылку на него?
Дон Хэтч
Дон, к сожалению, Google убил систему социальных сетей, в которой содержался пост; Я понятия не имею, откуда взялся оригинальный плакат, если угодно. Я убью ссылку в приведенной выше информации, однако, чтобы устранить двусмысленность. Спасибо.
fyngyrz
Рассуждения не глупы, а ты только что это доказал. Реализация комментариев в виде тегов сохраняет совместимость . Это именно то, почему Крокфорд хотел комментарии анализируемого как теги. Теперь все это просто тег и разбирается так же .
Доминик Черизано
Если в спецификации указано, что «строка, начинающаяся с #, является комментарием», то это будет полностью совместимо. Как таковые, комментарии оба загружают пространство анализатора, поскольку они являются действительными разобранными элементами, а не являются комментариями, и они могут отличаться для каждого существующего файла .json. Принимая во внимание, что если (например) спецификация говорит «строки, начинающиеся с #, являются комментариями», то парсеры могут пропускать эти строки без разбора (быстрее) и не загружать пространство синтаксического анализатора (лучшее использование памяти.) Из-за недостатка нет никакой выгоды. комментариев в .json, только минусы.
fyngyrz
11

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

{

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

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

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

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

}
Крис
источник
15
Вы эмулировали файловую структуру INI в JSON. Пожалуйста, опусти свой Золотой Молот.
Артур Цайка
4
RFC говорит: «Имена внутри объекта ДОЛЖНЫ быть уникальными». Также посмотрите на этого человека, который имеет ошибку при синтаксическом анализе JSON, как указано выше: stackoverflow.com/questions/4912386/…
William Entriken
Если вы используете схему для проверки JSON, она может потерпеть неудачу из-за дополнительных полей.
gregsdennis
1
Если вы действительно полны решимости добавить комментарии к вашему JSON, было бы гораздо разумнее сделать что-то вроде этого: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } Это сохраняет имя уникальным и позволяет вам добавлять любое строковое значение, которое вам нравится. Это все еще клочок, потому что комментарии не должны быть частью вашего JSON. В качестве другой альтернативы, почему бы не добавить комментарии до или после вашего JSON, но не внутри него?
Джазимов