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

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

@StingyJack: Чтобы объяснить вещи, которые могут быть неочевидными, или что еще можно сделать с комментариями. У меня, например, часто есть комментарии в файлах данных. XML, файлы ini и многие другие форматы содержат положения для комментариев.

Michael Burr 28.10.2008 23:51

Если вам, как и мне, интересно, подходит ли //comments для конкретного варианта использования файла конфигурации Sublime Text, ответ - да (начиная с версии 2). Sublime Text не будет жаловаться на это, по крайней мере, тогда как он будет жаловаться на {"__comment": ...} в консоли, потому что это неожиданное поле.

driftcatcher 01.02.2013 19:12

и, возможно, это одна из причин, по которой был создан TOML ..

Alex Nolasco 01.05.2013 09:22

Немного глупо, но я также пробовал использовать // для комментариев в JSON. Теперь я понимаю, что он используется строго для обмена / обмена. Вздох! Больше не могу комментировать :(. Жизнь обречена !.

Sid 25.09.2013 15:29

Проверить highcharts.com/samples/data/…? и вы увидите комментарии. Но это JSONP, а не чистый JSON. См. Мой ответ ниже.

Sergey Orshanskiy 08.10.2013 00:39

JSON5 поддерживает комментарии: stackoverflow.com/a/7901053/108238

schoetbi 02.02.2015 14:13

Парсер json в Ruby - еще один пример парсера, поддерживающего комментарии.

Ben Crowell 20.06.2016 20:21

Если вам нужен язык для конфигурации с комментариями, см. TOML

schoetbi 12.09.2016 16:20

Комментарии не разрешены, потому что уже слишком поздно поддерживать комментарии. Главный надзор. Как ни странно, YAML поддерживает комментарии.

bvj 02.08.2017 10:08
oreilly.com/learning/adding-comments-in-json имеет 2 способа добавить функцию комментария к вашему файлу JSON.
Flotolk 08.01.2018 22:32

вот симпатичный трюк gist.github.com/MoOx/5271067

osama yaccoub 04.04.2018 18:48

Вот почему YAML лучше.

Chloe 17.07.2018 20:07

Посмотрите RFC 4627 и связанные с ним.

MikeW 29.10.2018 13:29

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

hktegner 31.03.2019 14:08

Файлы jsonc должны работать, отсюда и определение: JSON с Comments.

mekb 21.07.2019 06:19

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

Dominic Cerisano 20.11.2019 18:45

если файл .json не поддерживает комментарии, возможно, должен быть параллельный файл с расширением (например, .jsondoc), чтобы содержать описания данных / комментарии для файла .json с тем же именем.

RufusVS 12.02.2020 20:28

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

Mike Rosoft 03.03.2020 14:08

@schoetbi, JSON5 неофициальный. Это не «пятая версия JSON», несмотря на то, во что хотели бы вы поверить ее создатели. См. github.com/json5/json5-spec/issues/15

HullCityFan852 20.04.2020 03:51

Чтобы добавить к комментарию @ HullCityFan852: JSON широко поддерживается несколькими организациями по стандартизации, как можно увидеть в его статье в википедии. JSON5 - один из многих нестандартных парсеров; 5 кажется попыткой извлечь выгоду из популярности HTML5. ИМХО, несмотря на возможно похвальные цели автора (ов), это имя вводит в заблуждение, поэтому неприемлемо.

ToolmakerSteve 01.05.2020 02:40

Как ответственный разработчик, вы должны задать себе вопрос: "Мне действительно нужно взломать это решение только потому, что я могу?" JSON - это довольно старый формат обмена данными, не зависящий от языка. Если бы действительно была необходимость в «комментариях», то изменение спецификации уже было бы внесено. Эта потребность в комментариях возникает, когда разработчики хотят использовать JSON для представления конфигурации приложения или что-то подобное. В этот момент следует ли вам действительно использовать JSON для выполнения этой работы?

nabster 19.05.2020 19:16
manifest.json поддерживает // comments. На всякий случай, если кто-то придет сюда по этому особому случаю, как я делал это раньше.
Thomas 17.09.2020 09:48

YAML может быть более подходящим, если данные должны быть удобочитаемыми.

Mudream 23.09.2020 13:41

Представьте изобретателя молотка. Вероятно, он хотел разбивать камни на частицы, которые можно было использовать для изготовления ножей и топоров. Мы все еще были бы в каменном веке, если бы он настаивал на том, что его инструмент нельзя использовать ни для чего другого, например, для того, чтобы ударить людей, нападающих на вас, или превратить пшеницу в муку, или забить гвозди. Это верх высокомерия - предполагать, что это МОЙ способ или ничего. Пренебрежение комментариями - отличный пример предположения, что этот инструмент никогда не будет иметь другого применения, кроме обмена данными между машинами / программами. Стыдно за такое отсутствие предвидения.

SMBiggs 20.11.2020 23:44

JSONObject Android поддерживает комментарии в стиле C в своем парсере.

Pointer Null 08.01.2021 13:38
Формы c голосовым вводом в React с помощью Speechly
Формы c голосовым вводом в React с помощью Speechly
Пытались ли вы когда-нибудь заполнить веб-форму в области электронной коммерции, которая требует много кликов и выбора? Вас попросят заполнить дату,...
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Стилизация и валидация html-формы без использования JavaScript (только HTML/CSS)
Будучи разработчиком веб-приложений, легко впасть в заблуждение, считая, что приложение без JavaScript не имеет права на жизнь. Нам становится удобно...
Flatpickr: простой модуль календаря для вашего приложения на React
Flatpickr: простой модуль календаря для вашего приложения на React
Если вы ищете пакет для быстрой интеграции календаря с выбором даты в ваше приложения, то библиотека Flatpickr отлично справится с этой задачей....
В чем разница между Promise и Observable?
В чем разница между Promise и Observable?
Разберитесь в этом вопросе, и вы значительно повысите уровень своей компетенции.
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Что такое cURL в PHP? Встроенные функции и пример GET запроса
Клиент для URL-адресов, cURL, позволяет взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.
Четыре эффективных способа центрирования блочных элементов в CSS
Четыре эффективных способа центрирования блочных элементов в CSS
У каждого из нас бывали случаи, когда нам нужно отцентрировать блочный элемент, но мы не знаем, как это сделать. Даже если мы реализуем какой-то...
8 169
25
2 625 034
55
Перейти к ответу Данный вопрос помечен как решенный

Ответы 55

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

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

Ответ принят как подходящий

Нет.

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

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

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

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

{
   "_comment": "comment text goes here...",
   "glossary": {
      "title": "example glossary",
      "GlossDiv": {
         "title": "S",
         "GlossList": {
            "GlossEntry": {
               "ID": "SGML",
               "SortAs": "SGML",
               "GlossTerm": "Standard Generalized Markup Language",
               "Acronym": "SGML",
               "Abbrev": "ISO 8879:1986",
               "GlossDef": {
                  "para": "A meta-markup language, used to create markup languages such as DocBook.",
                  "GlossSeeAlso": ["GML", "XML"]
               },
               "GlossSee": "markup"
            }
         }
      }
   }
}

Было бы неплохо иметь какой-то префикс в фактическом комментарии на случай, если когда-либо будет действительное поле с именем comment: "__comment":"comment text goes here...",

Rob Fonseca-Ensor 03.02.2010 14:41

Кстати, библиотека json для Java google-gson поддерживает комментарии.

centic 01.10.2012 16:21

Как насчет того, чтобы я хотел отдельно прокомментировать свойства Accronym и Abbrev? Я использовал этот шаблон раньше, но остановился, поскольку он не позволяет мне этого делать. Это взлом. Может быть, если вместо этого я добавлю к имени свойства __comment__. Это «__comment__Abbrev», все еще хакерский, но он позволяет мне комментировать все возможности.

Juan Mendes 11.08.2014 16:58

@JuanMendes: вам разрешено использовать один и тот же ключ несколько раз.

mike3996 17.12.2014 10:03

Для этого мы можем выбрать более уникальный формат ключей комментариев. Что-то вроде {"<!-- glossary -->": "Comment text"} выглядит нормально. "/* glossary */" тоже.

vp_arth 19.12.2014 07:21

Почему GlossList не является массивом (GlossList: [ { .. }, { .. } ])?

Luca Steeb 12.05.2015 15:58

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

gregsdennis 26.06.2015 03:31

вы также можете использовать "//": это выглядит более естественным и по-прежнему повторяется в том же родителе

smnbbrv 28.08.2015 12:59

@JuanMendes Возможно, уже слишком поздно, чтобы помочь, но для многострочных комментариев сделайте значение элемента комментария массивом строк: [ "line 1", <CRLF> "line 2", <CRLF> "line 3" ].

TripeHound 09.10.2015 17:11

Дело в том, что он меняет семантику JSON, например. изменение длины массива.

Qian Chen 21.12.2015 15:21

Когда JSON используется для файлов конфигурации, предназначенных для человека, они должны быть аннотированы, чтобы люди могли лучше понять. Аннотировано, такой файл больше не является допустимым JSON, но есть решения. Например, Google GYP поддерживает комментарии в стиле #. JSON.Minify поможет вам удалить комментарии в стиле C / C++ из входного файла.

Петър Петров 27.02.2016 16:59

Есть JSON5 (5 относится к ECMAScript 5 (и позже)).

Peter Mortensen 19.01.2017 21:42

Существует ряд библиотек и фреймворков, которые теперь поддерживают комментарии в файлах JSON. В области C# их поддерживает Newtonsoft JSON.Net, и в результате вы увидите комментарии, используемые в различных JSON в файлах конфигурации .Net Core.

Ken Mason 14.08.2017 21:48

Если вы возвращаете json через api, тогда клиент должен использовать команду HTTP Options для чтения описаний / комментариев json.

MIKE 07.09.2017 20:41

Да вы можете попробовать использовать {"//": "Your comment"}

danger89 20.03.2018 22:12

Но будь осторожен! Некоторым полностью анализирующим движкам нужно что-то вроде аннотации @JsonIgnoreProperties, иначе они увидят неизвестное поле как ошибку.

Gangnus 15.05.2018 08:08

Просто скопируйте соответствующий отрывок из первой ссылки, предоставленной @MichaelBurr (вторая, по-видимому, безвозвратная): «Предположим, вы используете JSON для хранения файлов конфигурации, которые вы хотите аннотировать. Продолжайте и вставьте все комментарии, которые вам нравятся. Затем пропустите его через JSMin, прежде чем передать его парсеру JSON », - Дуглас Крокфорд

chb 17.09.2018 03:45

Одна из ссылок в моем комментарии от июня 2012 года больше не работает. Другой читатель (@douglasgross) предоставил эту текущую ссылку: groups.yahoo.com/neo/groups/json/conversations/topics/156

Michael Burr 28.09.2018 01:20

Спасибо за ответ! Когда я писал сценарии JSON, я подумал о добавлении обычного комментария (//), Jslint VSCode сразу же выделил комментарий красной линией, сказав: «Комментарии не разрешены в JSON».

Imran Rafiq Rather 29.10.2018 10:07

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

Pranav A. 25.11.2018 01:44
_comment также является официальным обходным путем в composer.json, как это было сделано композитором и автором Селдэком в 98b0af1.
noobish 02.02.2019 03:12

@ RobFonseca-Ensor, а что, если у нас будет поле под названием __comment? Нам понадобится новое поле ___comment.

Charlie 08.03.2019 20:27

Ах! ... Кто бы ни разработал спецификацию, они никогда не предполагали, что она когда-либо будет использоваться для файлов конфигурации, где комментарии действительно могут оказаться очень полезными. Некоторые вещи, такие как Microsoft.Extensions.Configuration.Json, по-видимому, выдерживают // бла-комментарии, тогда как другие, такие как Powershell ConvertFrom-Json, нет. Так что будьте осторожны с добавлением комментариев.

andrew pate 25.09.2019 16:35

Я не могу не чувствовать, что должно быть решение с открытым исходным кодом, чтобы решить эту проблему, охватывающую большинство популярных языков, таких как: powershell, bash и python, java и C#.

andrew pate 25.09.2019 16:43

@centic Именно поэтому Кроуфорд удалил комментарии из официального стандарта. Комментарии GSON нарушат работу любого стандартного парсера JSON, сделав GSON несовместимым. GSON - это не JSON.

Dominic Cerisano 02.11.2019 22:36

К сожалению, моя бабушка скулит по Error: Unknown option: _comment.

Thielicious 25.06.2020 01:31

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

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

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

Взгляните на Сайт JSON для более подробной информации.

Это правда, что в формате JSON нет комментариев. Лично я считаю, что это серьезная ошибка - возможность иметь комментарии как метаданные (а не данные) - очень полезная вещь с xml. Более ранние черновые версии спецификации JSON действительно включали комментарии, но по какой-то причине они были опущены. : - /

StaxMan 01.09.2009 22:20

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

Camilo Martin 11.12.2010 12:03

Метаданные относятся к конструкциям метаданных (например, тегам HTML <meta>), а не к комментариям. Злоупотребление комментариями к метаданным - это всего лишь уловка, используемая там, где не существует истинной конструкции метаданных.

Marnen Laibow-Koser 06.09.2011 08:55

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

gaborous 25.06.2013 18:50

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

toolbear 07.08.2014 23:35

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

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

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

Orbling 25.02.2011 14:04

Я согласен и написал парсер JSON на Java, доступный на www.SoftwareMonkey.org, который делает именно это.

Lawrence Dol 28.07.2012 05:51

Несмотря на это, я считаю, что расширять JSON (не называя его другим форматом обмена) - не лучшая идея: обязательно игнорируйте «комментарии» в строках. {"foo": "/ * Это не комментарий. * /"}

stofl 27.07.2013 16:09

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

Kyle Simpson 09.12.2013 01:55

Что сказал @ kyle-simpson. Кроме того, он слишком скромен, чтобы направлять читателей к своему собственному ответу об использовании JSON.minify в качестве альтернативы специальным регулярным выражениям. Делай это, а не это.

toolbear 07.08.2014 23:32

Однострочное JS-совместимое регулярное выражение: myJson.replace(/("\/\/.*"|"\/\*(?:.|\n)*?")|(\/\/.*|\/\*(?:.‌​|\n)*?\*\/)/g, "$1")regexr.com/3p39p

Maxim Paperno 08.05.2018 07:34

@MaximPaperno Нет, ничего хорошего: regexr.com/5fvda

JLRishe 10.11.2020 20:48

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

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

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

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

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. - Douglas Crockford, 2012

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

Единственная проблема, с которой я столкнулся с JSON.minify (), заключается в том, что он действительно очень медленный. Итак, я сделал свою собственную реализацию, которая делает то же самое: gist.github.com/1170297. На некоторых больших тестовых файлах ваша реализация занимает 74 секунды, а моя - 0,06 секунды.

WizKid 25.08.2011 13:16

было бы здорово, если бы вы могли отправить предложенный альтернативный алгоритм в репозиторий github для JSON.minify (), чтобы его можно было портировать на все поддерживаемые языки: github.com/getify/json.minify

Kyle Simpson 30.08.2011 21:20

JSON Perl поддерживает # комментариев.

Johannes Ernst 14.11.2011 21:36

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

Marnen Laibow-Koser 15.12.2011 19:34

@Viktor Зачем нужны комментарии в пакете данных? Это пустая трата места. Если в дидактических целях, просто поместите их в другом месте или признайте, что вы нарушаете формат. В реальном приложении в них не должно быть необходимости.

Marnen Laibow-Koser 07.03.2012 04:07

Возможно, вам будет интересно услышать от автора JSON, почему комментарии были исключены из спецификации: youtu.be/-C-JoyNuQJs?t=48m53s

MiniGod 31.01.2013 07:29

@MiniGod Я уже много раз слышал мысли Дуга на эту тему. Я обратился к ним давно в своем блоге: blog.getify.com/json-comments

Kyle Simpson 27.02.2013 03:21

@ MarnenLaibow-Koser по-прежнему существуют допустимые варианты использования комментариев даже для использования потока данных (или даже пакетов): включение диагностических метаданных, таких как время создания или источники, является обычным использованием с XML и совершенно разумно для данных JSON. Аргументы против комментариев неглубокие, и любой текстовый формат данных должен разрешать комментарии, независимо от предполагаемого предполагаемого использования (ничто не указывает на то, что JSON нельзя использовать где-либо еще, fwiw)

StaxMan 29.03.2014 02:09

@StaxMan Нет. Комментарии в потоке данных - это просто потраченные впустую байты. Если метаданные, такие как время создания, не могут быть выведены из самого потока, то почему бы не сделать их актуальным, анализируемым контентом в потоке? Аргументы для комментарии мелкие: если что-то стоит включить, то стоит включить как данные.

Marnen Laibow-Koser 01.04.2014 20:38

@StaxMan Я считаю, что подкрепляю все, что говорю, фактами, так как нет, чтобы сделать это просто моим личным мнением. Если есть что-то, что я не сделал в достаточной мере, дайте мне знать. «Ваше заявление о том, что все метаданные должны быть данными, - просто чушь». Нет, здесь вы явно ошибаетесь. Я думаю, единственная причина для включения метаданных в том, чтобы их можно было проанализировать. Если он будет анализироваться, просто сделайте это настоящими данными, а не комментариями. Есть ли у вас вариант использования, для которого это не сработает?

Marnen Laibow-Koser 09.04.2014 07:14

@StaxMan «большинство других текстовых форматов распознают это (XML и YAML имеют комментарии)» XML и YAML предназначены для файлов; JSON был просто извлечен из JavaScript, и я думаю, что это делает ужасный синтаксис файла (YAML и даже XML в этом случае работают лучше). Верно, что файлы JSON могут иногда нуждаться в комментариях, но файлы JSON сами по себе плохая идея, когда YAML выполняет ту же работу лучше. :)

Marnen Laibow-Koser 09.04.2014 07:16

Мой канонический вариант использования - это файлы журналов, которые передаются для агрегирования или хранения; Таким образом, различие между потоками и файлами является виртуальным и временным. Что касается пропуска: все свойства видны, и есть два основных способа справиться с этим - (а) классический, вы должны знать, что все такое (по крайней мере, в той степени, в которой вы можете его пропустить), или (б) " все идет ", т.е. просто используйте то, что знаете. В последнем случае просто пропустить метаданные. Но я вижу, что вы не можете представить себе простое понятие «только диагностические комментарии» - здесь нет смысла спорить друг с другом.

StaxMan 09.04.2014 23:41

@StaxMan "Мой канонический вариант использования - файлы журнала" - проблема сама по себе; JSON - не лучший формат для ведения журнала (слишком много знаков препинания по сравнению с YAML или XML). «В последнем случае просто пропустить метаданные». Это веский аргумент в пользу отказа от «классического» метода (в общем, его слишком легко сломать). «Но я вижу, что вы не можете представить себе простое понятие комментариев только для диагностики» - Что вы подразумеваете под комментариями только для диагностики? Я не могу этого представить, если вы не объясните это. :)

Marnen Laibow-Koser 15.05.2014 09:50

В JSON слишком много знаков препинания по сравнению с XML? Вы можете уточнить, что вы здесь имеете в виду? Вот пример JSON для загрузки фикстур в Django: [{"model": "foo.bar", "pk": 1, "fields": {"name": "foo", "customer_number": 12345}}] То же самое в XML выглядит примерно так: <? Xml version = "1.0" encoding = "utf-8"?> <Django-objects version = "1.0"> <object pk = "1" model = "foo.bar "> <field type =" TextField "name =" name "> foo </field> <field type =" IntegerField "name =" customer_number "> 12345 </field> </object> </ django-object‌ s>

ManicDee 16.06.2014 09:28

@ManicDee Вы правы насчет пунктуации в XML; Я пытался быть кратким и в итоге оказался неточным в этом отношении. Пересмотренное утверждение: в JSON слишком много знаков препинания по сравнению с YAML, и у него плохой файловый синтаксис по сравнению с YAML или XML. (Для записи я бы выбрал JSON для потоков, YAML для файлов и XML для ничего каждый раз, если только нет особой внешней потребности в XML.)

Marnen Laibow-Koser 09.07.2014 19:38

Проблема с этим ответом заключается в том, что JSON - это формат сериализации, поэтому для каждого языка должен быть написан минификатор (или встроенный минификатор для каждого парсера). Как мне теперь найти json-минификатор для c?

Blake 10.09.2014 20:45

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

eggmatters 27.01.2016 22:31

@KyleSimpson 404 по ссылке в вашем блоге, обновите ссылку если у вас новая копия

Srinath Ganesh 24.05.2016 14:42

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

Remember Monica 01.05.2017 19:22

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

JayJay123 30.05.2017 20:56

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

Abion47 12.11.2018 23:20

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

Пример:

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

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

Схема JSON жива? Он существует, но поддерживается ли он какой-либо известной библиотекой?

Munhitsu 29.10.2012 18:31

да, json-schema группа Google довольно активен, и я бы порекомендовал JSV для хорошей реализации JavaScript валидатора схемы JSON.

raffel 27.11.2012 15:34

Это помогает только со структурированной документацией, а не специальной документацией.

Juan Mendes 04.04.2013 21:47

Если вы используете clojure (а я уверен, что вы этого не делаете), здесь есть достаточно функциональный парсер схемы JSON с открытым исходным кодом: github.com/bigmlcom/closchema

charleslparker 15.04.2013 17:50

@Munhitsu Manatee.Json (.Net) широко поддерживает схему JSON.

gregsdennis 26.06.2015 03:26

Это актуально не для всех ситуаций. У меня есть один, в котором у меня есть вручную настроенный JSON для анализа другим (менеджером пакетов), имеющим собственную схему. В этом случае мне нужен комментарий, например / * Лучше использовать X из другого диспетчера пакетов, однако этот диспетчер еще не предоставляет X. * /.

jgmjgm 08.12.2017 14:22

Может быть, пришло время обновить? Например. насколько широко это принято и т. д.

Peter Mortensen 08.10.2020 19:34

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

  • https://www.json.org
  • RFC 4627: Тип носителя application/json для нотации объектов JavaScript (JSON)
  • RFC 8259 Формат обмена данными JavaScript Object Notation (JSON) (заменяет RFC 4627, 7158, 7159)

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

toolbear 07.08.2014 23:26

@alkuzad: Когда дело доходит до формальных грамматик, должно быть что-то, что явно говорит о том, что они разрешены являются, а не наоборот. Например, возьмите язык программирования по своему выбору: просто потому, что какая-то желаемая (но отсутствующая) функция не запрещена явно, не означает, что ваш компилятор волшебным образом распознает ее.

stakx - no longer contributing 28.09.2015 10:01

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

Triynko 31.10.2017 20:36

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

cmroanirgo 21.01.2018 03:29

@cmroanirgo: Очевидно, вы не первый, кто жаловался на это ограничение JSON ... вот почему у нас есть парсеры, которые молча разрешают комментарии, и другие форматы, такие как YAML и JSON5. Однако это не меняет того факта, что JSON - это то, чем он является. Скорее, мне интересно, что люди начали использовать JSON в тех целях, где этого явно было недостаточно, учитывая рассматриваемое ограничение. Не вините формат JSON; винить себя в том, что настаиваем на использовании его там, где он не особенно подходит.

stakx - no longer contributing 21.01.2018 10:48

@stakx, я не согласен. Это все равно, что сказать: «Автомобили изначально не были с ремнями безопасности, поэтому нам не следовало их добавлять. Если вам нужен ремень безопасности, значит, вы неправильно используете автомобиль». Если добавление комментариев к JSON сделало бы его более полезным (что, безусловно, было бы), мы должны просто добавить их. Вместо того чтобы признать, что JSON просто «такой, какой он есть», давайте сделаем его таким, каким он должен быть.

d512 18.06.2019 23:29

@ d512: Если вы твердо уверены в том, что такое формат JSON должно быть (по сравнению с тем, что он является сегодня), возможно, обсудите это с IETF, чтобы изменить спецификацию формата JSON RFC 8259.

stakx - no longer contributing 02.07.2019 19:00

@ d512, чтобы придерживаться вашего примера: JSON - это велосипед, а другие форматы, которые разрешают комментарии, - автомобили. Вы можете добавить ремень безопасности на велосипед (или добавить комментарии к JSON), но это не предназначено. Кроме того, вы можете просто добавить поле _comment, как указано в принятом ответе.

PixelMaster 10.07.2019 17:38

@PixelMaster, тогда пришло время обновить JSON до статуса автомобиля. Никто не стал бы, за исключением объявления строковой переменной _comment в своем коде, поэтому давайте не будем прибегать к этим типам взломов в JSON.

d512 10.07.2019 21:33

@ d512, однако, вы не собираете машину из велосипеда - вместо этого вы получаете совершенно другой автомобиль, новую машину (^ = формат данных). В то же время наличие автомобилей не делает велосипеды устаревшими.

PixelMaster 10.07.2019 22:51

@PixelMaster Итак, переместите всю отрасль на новый формат данных, который поддерживает комментарии, а не просто добавляет их в JSON? Нам не нужно полностью менять формат. Это не аналог превращения велосипеда в автомобиль. Нам просто нужна одна общая черта, здравый смысл.

d512 24.07.2019 21:58

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

PixelMaster 25.07.2019 00:30

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

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

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

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

toolbear 07.08.2014 23:31

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

David 08.08.2014 03:37

Подавать закомментированный и, следовательно, недействительный JSON - это плохое вуду, что dojo.xhrGet() неявно поощряет, принимая.

toolbear 09.08.2014 00:21

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

Craig 15.09.2014 11:03

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

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

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

Для файлов конфигурации я бы предложил YAML, а не JSON. Это (почти) более мощный набор JSON, но он также поддерживает более читаемые конструкции, включая комментарии.

Marnen Laibow-Koser 20.10.2011 01:35

Как вы думаете, сколько языков поддерживает YAML из коробки по сравнению с json?

mmm 13.01.2012 17:26

@Hamidam Более дюжины языков поддерживают yaml: yaml.org - но вы правы, спрашивая, сколько из них имеют встроенную поддержку, без необходимости в зависимости от сторонней библиотеки. Похоже на Ruby 1.9.2. Кто-нибудь знает других? И какие языки по умолчанию поддерживают json?

nealmcb 21.03.2012 19:53

Взаимодействие YAML - ложь: stackoverflow.com/questions/450399/…. Если вы инстинктивно хотите использовать JSON для файлов конфигурации, следуйте ему.

toolbear 07.08.2014 23:10

Это старый вариант, но я считаю, что использовать # - не лучшая идея. Json близок к синтаксису литерального Javascript. Javascript поддерживает 2 типа комментариев: // и / * ... * / На вашем месте я бы придерживался одного или обоих этих типов комментариев.

Pascal Ganaye 02.12.2015 21:24

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

Обратите внимание, что обратное неверно (действительный YAML! => Действительный JSON)

g33kz0r 11.09.2012 08:01

@ g33kz0r Правильно, поэтому я описываю YAML как почти надмножество JSON.

Marnen Laibow-Koser 12.09.2012 18:58

@NateS Многие люди уже указали, что ответ отрицательный. Я предложил лучший способ достичь цели ОП. Это ответ.

Marnen Laibow-Koser 28.03.2014 16:57

Оборотная сторона: библиотека yaml не поставляется с Python.

Bleeding Fingers 15.04.2014 14:06

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

Marnen Laibow-Koser 13.08.2014 23:25

@ marnen-laibow-koser: да, должно быть, было некомпетентно использовать доступные библиотеки YAML для Java и Perl и ожидать, что YAML, созданный каждым из них, будет использоваться другим без ошибок. Это взаимодействие YAML было проблемой, а взаимодействие JSON - нет, полностью объясняется моим отсутствием знаний.

toolbear 18.08.2014 03:32

@toolbear Похоже, виноваты плохо написанные библиотеки; не вините в этом формат. И да, ваше заявление о двусмысленности цитирования предполагает недостаток знаний, хотя мне было бы интересно рассмотреть конкретный случай, если он у вас есть. Однако недостаток знаний может быть со стороны разработчика синтаксического анализатора, не обязательно со стороны вас.

Marnen Laibow-Koser 19.08.2014 00:38

@ marnen-laibow-koser, формат, который выполняет то же самое с более простой спецификацией, лучше. Прагматичный формат с идеальной реализацией лучше идеального формата с несовершенной реализацией. Не вся вина за неисправные библиотеки ложится на плечи разработчиков; спецификация YAML длинная, плотная и тупая. Его статья в Википедии приводит два примера двусмысленности; если нужно поместить эмиттер между человеком и форматом, чтобы защитить их от двусмысленностей, формат теряет свои дружественные к человеку притязания. JSON требует меньше и в основном преуспевает там, где YAML требует больше и терпит неудачу.

toolbear 25.08.2014 15:45

@ marnen-laibow-koser, я опроверг ваши предположения о моей собственной некомпетентности, подкрепил свои утверждения конкретными деталями и немного подробно остановился на моих предпочтениях / предубеждениях, которые определяют мою критику YAML. Дальнейшие мои комментарии, вероятно, имеют убывающую отдачу. Я уверен в способности будущих читателей сделать осознанный выбор. Спасибо за беседу, не считая того, что плинтус находится рядом с атакой ad hominem. Если вы пожелаете, последнее слово за вами.

toolbear 25.08.2014 15:56

@toolbear Никакой атаки ad hominem не планировалось. «Прагматичный формат с идеальной реализацией лучше, чем идеальный формат с несовершенной реализацией» - не уверен, что согласен. Если формат идеален (и реализуем), то всегда можно использовать делать как хорошую реализацию. Если формат не идеален, то даже идеальная реализация не будет хорошей. :) «спецификация YAML длинная, плотная и тупая» - это не совсем то, что означает «тупой», но спецификация YAML довольно ясна. Я не вижу двусмысленностей, упомянутых в Википедии; пожалуйста, цитируйте конкретные разделы статьи, если я что-то упустил.

Marnen Laibow-Koser 13.09.2014 04:58

yaml >> json. И у python есть хорошая библиотека yaml. Мне нужно попробовать свои силы в Scala, но оно того стоит.

StephenBoesch 02.10.2016 08:35

Этот ответ действителен при добавлении комментариев к json. Это больше не стандартный json. Но это все еще json. Комментарии + Json + Yaml Loader = верное решение. Некоторые фреймворки / языки требуют установки json. Он устанавливается по умолчанию - плохой повод не использовать yaml. Но время загрузки и размер библиотеки - веские причины избегать этого. Может подойти, а может и нет. Правильный ответ.

TamusJRoyce 26.12.2018 20:22

@TamusJRoyce Я бы не назвал это правильным решением. Если вы собираетесь использовать загрузчик YAML, тогда идите ва-банк и используйте YAML. Если вам действительно нужно использовать JSON (который в любом случае является ужасным форматом файла), придерживайтесь стандарта и не используйте комментарии.

Marnen Laibow-Koser 28.12.2018 00:58

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

TamusJRoyce 28.12.2018 01:44

@TamusJRoyce Но этот не будет работает во всех случаях, и он хакерский и вообще ужасный. По крайней мере, таково мое мнение. :)

Marnen Laibow-Koser 12.02.2019 20:27

В свое время я построил парсер файла конфигурации, используя yaml. Он мог использовать .ini, xml, yaml и json. И выплюнуть чистый json. Если вы хотите превратить что-то уродливое в нечто чистое, нет ничего плохого в использовании такой тяжелой библиотеки, как yaml. yaml совсем не хакерский или ужасный. Относитесь к нему как к инструменту ETL или ремонту json. Супер полезно и полезно. Или даже инструмент сборки, который удаляет комментарии. На ум приходит Webpack.

TamusJRoyce 14.02.2019 03:58

@TamusJRoyce Да, я люблю YAML. То, против чего я возражал как хакерского, - это синтаксический анализ комментариев JSON +, как если бы это был YAML, вместо того, чтобы идти ва-банк со стандартным YAML или стандартным JSON.

Marnen Laibow-Koser 14.02.2019 04:00

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

В Groovy есть встроенные классы для обработки JSON. JsonSlurper может обрабатывать комментарии. Конечно, в официальной спецификации комментарии не допускаются, поэтому такое поведение в любом парсере нестандартно и непереносимо.

izrik 07.11.2015 00:47

Newtonsoft Json.NET также без проблем поддерживает комментарии в стиле C

Max 17.04.2020 04:19

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

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

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

Я думал, что JSON должен быть более читабельным, чем, скажем, XML? Комментарии предназначены для удобства чтения.

intrepidis 14.10.2012 17:00

В любом случае, вы могли бы пошалить и добавить директивы синтаксического анализа в JSON: {"__directives": {"# n #": "DateTime.Now"}, "validdate": "# n #"} ... Похоже на YAML тогда путь вперед ...

intrepidis 14.10.2012 17:04

Удаление комментариев /* */ также сделало JSON лучшим подмножеством YAML.

Schwern 29.11.2012 11:47

@Schwern Но YAML допускает комментарии #, так что ваша точка зрения вроде муут

Juan Mendes 04.04.2013 21:50

@JuanMendes Я не понимаю, почему это делает мою точку о тоо совместимости JSON / YAML. Как вы думаете, в чем заключалась моя точка зрения?

Schwern 04.04.2013 22:28

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

Juan Mendes 05.04.2013 03:22

@JuanMendes Не столько «не следует», сколько просто польза от изменения (лично я нахожу это болью, которую я не могу комментировать в файлах JSON). Имейте в виду, что JSON также является подмножеством Javascript, а YAML и Javascript имеют взаимно несовместимый синтаксис комментариев. YAML использует #, но Javascript использует // и /* */. JSON не может использовать # в качестве комментария, не становясь несовместимым с Javascript. JSON не может быть подмножеством YAML и Javascript и иметь комментарии.

Schwern 05.04.2013 06:26

Как сказала бы Лиз Лаймон ... "нарушитель сделки, дамы"! Господи… итак, чтобы что-то протестировать со строкой «пропущено», иначе «прокомментировано» (в обычной вселенной) .. вы должны УДАЛИТЬ строку? Нет, спасибо! Дай мне в любой день какой-нибудь старый добрый и непослушный XML!

Alex Gray 17.05.2013 02:16

@ChrisNash Это не было предназначено для чтения лучше, чем XML, просто легко читается людьми. json.org И JSON является легко читается людьми. Комментарии добавляют дополнительную информацию, но не делают ее более или менее удобной для чтения людьми.

Oscar Godson 02.08.2013 22:18

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

caiosm1005 23.09.2013 06:28

@ caiosm1005 Написание собственного синтаксического анализатора для четко определенного формата всегда несовершенно. Я обнаружил, что для файлов конфигурации гораздо больше подходят такие форматы, как свойства Java или простой старый INI. Java, C++, Python и nodejs имеют встроенную или библиотечную поддержку того или другого. Я особенно предпочитаю файлы INI. Либо так, либо всегда дополняйте конфигурации надежным файлом readme.

Artur Czajka 24.09.2013 16:22

@ArturCzajka Мне все еще не нравится тот факт, что JSON не поддерживает комментарии, но я попробовал INI и должен признать, что гораздо разумнее использовать их вместо JSON для файлов конфигурации. Спасибо за ответ, и, надеюсь, еще больше людей передумают, прочитав этот разговор. (в любом случае создание парсера было большим упражнением :)

caiosm1005 04.10.2013 06:42

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

rakehell 29.05.2014 21:52

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

adelphus 12.06.2014 18:22

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

toolbear 07.08.2014 23:24

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

Craig 15.09.2014 10:48

Честно; никто никогда не использовал комментарии в XML для своих собственных директив обработки? Это разрушило совместимость XML? Существовал ли когда-либо другой язык или формат данных, позволяющий добавлять комментарии в файл?

Craig 15.09.2014 10:54

Не иметь комментариев в JSON - это неправильно. Форматирование (пробелы, перевод строки) являются разрешено в JSON, и нет принципиальной разницы между форматированием и комментариями.

Johannes Overmann 29.01.2015 12:55

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

Phil Goetz 14.05.2015 20:24

@PhilGoetz Но у этой конкретной модели есть обучающие колеса. Аналогия лучше работает с трехколесным велосипедом. Если вам это не нравится, используйте другой, например YAML, или файл свойств. Не все должно быть разработано таким образом, чтобы охватить все возможные функции, о которых вы только можете подумать.

Winter 11.08.2017 15:37

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

Peter Flynn 31.08.2017 16:27

Удаление комментариев - это «ПЛОХАЯ ИДЕЯ». Поскольку комментарий также является данными для человека, который его читает, удаление их, потому что они не являются данными, - плохой аргумент. Кроме того, можно утверждать, что все комментарии на любом языке, в файле спецификации, файле конфигурации и т. д. Являются данными. Тот факт, что он не предназначен для машины, не означает, что это не данные.

Mac 24.08.2018 18:41

Я предполагаю, что JSMin относится к минификатору JavaScript на сайте Крокфорда по адресу crockford.com/jsmin.html, это правильно?

cowlinator 20.11.2019 00:02

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

См. еще один вопрос Stack Overflow.

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

webXL 18.09.2014 01:54

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

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

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

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

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

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

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

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

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

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

toolbear 07.08.2014 23:19

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

JSON does not have comments. A JSON encoder MUST NOT output comments. A JSON decoder MAY accept and ignore comments.

Comments should never be used to transmit anything meaningful. That is what JSON is for.

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

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

toolbear 07.08.2014 23:14

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

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

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

Удачного взлома!

Из спецификация: Имена внутри объекта ДОЛЖНЫ быть уникальными.

Quentin 02.08.2013 17:50

Верно, но это не синтаксическая ошибка, и все реализации обрабатывают ее одинаково. Так что я думаю, что пользоваться им довольно безопасно. Не философски, а практически.

p3drosola 02.08.2013 17:57

«все реализации обрабатывают это одинаково» - это сложно доказать.

Quentin 02.08.2013 18:20

Порядок элементов в JSON не гарантируется. Значит, "последний" предмет может измениться!

sep332 02.08.2013 18:33

@ sep332 они есть в случае отредактированного вручную файла json / config.

Tracker1 02.08.2013 18:36

@Quentin из rfc2119: "3. ДОЛЖНО. Это слово или прилагательное" РЕКОМЕНДУЕТСЯ "означать, что в определенных обстоятельствах могут существовать веские причины игнорировать конкретный элемент, но все последствия должны быть поняты и тщательно взвешены, прежде чем выбирать другой курс."

erdeszt 02.08.2013 18:37

@ Tracker1 - порядок не гарантируется, потому что важен синтаксический анализатор, а не человек, пишущий файл. Спецификация JSON не описывает, что должно произойти, если есть повторяющиеся ключи (в ней говорится, что вы ДОЛЖНЫ сделать их уникальными), поэтому одни парсеры могут использовать первый, а другие - последний, а другие - нет.

Quentin 02.08.2013 18:39

Это явно нарушает спецификацию (см. Комментарии выше), не делайте этого. ietf.org/rfc/rfc4627.txt?number=4627

voidlogic 02.08.2013 18:39

@erdeszt - Да, все последствия надо понимать. Невозможно понять их, не тестируя каждый парсер JSON (и поскольку люди будут продолжать писать новые…).

Quentin 02.08.2013 18:39

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

Gipsy King 02.08.2013 18:44

В настоящее время на json.org представлено более сотни различных реализаций. Бьюсь об заклад, по крайней мере, один из них не справляется с этим так же.

nemetroid 02.08.2013 18:44

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

opyh 02.08.2013 18:47

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

pdw 02.08.2013 18:53
НЕТ - а если парсер стриминг? Что, если парсер прочитает его в словарь, где порядок ключей не определен? убить это огнем.
deanWombourne 02.08.2013 18:55

@Quentin Я просто говорю, что в спецификации неясно, как обращаться с этим случаем, и это умный хакер, который «законен», но, конечно, не рекомендуется.

erdeszt 02.08.2013 18:58

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

Brad Choate 02.08.2013 20:04

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

nmaier 02.08.2013 20:19

Это неправильно на многих уровнях, я даже не знаю, с чего начать. Я просто поставлю это здесь - pragprog.com/the-pragmatic-programmer/extracts/coincidence - и постараюсь забыть то, что я только что видел.

Geoffrey Bachelet 02.08.2013 22:13

См. Этот вопрос для случая ошибки: stackoverflow.com/questions/4912386/…

Paul Tyng 02.08.2013 22:33

Плохая идея - приводит к путанице, противоречит спецификации, а не будущим требованиям, а JSLint дисквалифицирует JSON.

Praveen Vijayan 03.08.2013 09:37

Это отличный прием в сегодняшнем контексте. Анализ JSON упрощен как на стороне сервера, так и на стороне браузера. Все браузеры после IE8 включительно поддерживают JSON.parse. Так что действительно всем следует использовать встроенный анализатор JSON. Вы будете использовать собственный синтаксический анализатор только по устаревшим причинам. И очень маловероятно, что встроенный парсер JSON изменит свое поведение и нарушит обратную совместимость.

Santosh 03.08.2013 10:13

... продолжение моего комментария выше. Единственное, что нам нужно сделать сейчас, - это стандартизировать его, чтобы он не сбивал пользователя с толку. Например, мы можем указать, что это комментарий, сделав что-то вроде «** это комментарий **».

Santosh 03.08.2013 10:21

Поскольку мы работали над RFC 4627bis в IETF в рабочей группе JSON (присоединяйтесь к нам и помогите! datatracker.ietf.org/wg/json), мы обнаружили четыре различных подхода, которые разработчики использовали для дублирования имен в объекте: используйте первый; используйте последнее; сообщить обо всех из них и позволить звонящему выбрать один; вернуть ошибку и прекратить разбор. Если ваши данные не выдерживают всех этих подходов, они не будут взаимодействовать на практике.

Joe Hildebrand 04.08.2013 02:03

Плохой взлом. Это вопрос парсера JSON. По крайней мере, файл политики IAM (AWS) не принимает повторяющийся ключ JSON. microsofttranslator.com/bv.aspx?from=&to=en&a=http://…

kyanny 04.08.2013 07:06

Это один из худших ответов, которые я когда-либо видел в stackoverflow. Он может сломаться в любой момент, и это не так умно, поскольку не делает его особенно читаемым, как обычные комментарии. Всегда можно задаться вопросом, есть ли у нас элемент, который является комментарием или реальным фрагментом данных. JSMin кажется гораздо более чистым (и более читаемым) решением. Тем не менее, ИТ-индустрия все равно должна благодарить вас за шутку.

Jeremyfa 04.08.2013 21:28

Solr использует несколько ключей. Это несовместимо с основным поисковым сервером с открытым исходным кодом !!!

fulmicoton 05.08.2013 02:57

объедините это с Ответ Эли и вставьте повторяющиеся ключи "_comment" повсюду, тогда вы получите лучшее из обоих миров.

depoulo 05.08.2013 11:47

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

Jose Sutilo 05.08.2013 15:43

Это рак. Мой разработчик. ребята сделали то же самое, не читая комментариев. Теперь мы сжигаем себя во время потоковой передачи контента с RPC-сервера.

asyncwait 01.11.2013 14:13

"все реализации обрабатывают это одинаково" - Чжу имеет возможность использовать эти jsons

alex 04.01.2014 04:26

Это сообщение самый противоречивый на SO.

bjb568 11.04.2014 22:45

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

gnasher729 16.10.2014 15:48

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

Akshay Khandelwal 16.09.2015 06:45

@AkshayKhandelwal: Очевидно, вы не смогли понять этот комментарий. Вкратце: существуют различные стратегии четыре, которые парсеры выбирают, когда сталкиваются с неуникальными именами в объекте. Кроме того, спецификация не дает никаких гарантий относительно сохранения какого-либо порядка, поэтому "последний" в любом случае не имеет смысла. Прекратите распространять желаемое за действительное, как если бы оно было фактически правильным.

IInspectable 17.04.2017 19:49

Вы вступаете в область зависимости реализации.

Derek 朕會功夫 17.08.2017 23:47

Синтаксический анализатор jsondecode из Matlab создаст поля api_host и api_host_1 и т. д.

user3240484 29.10.2018 14:57

@Quentin: Вы можете доказать, что это неправильно, написав два совместимых со стандартами парсера JSON, которые используют разные стратегии. Я помню, что разные стратегии парсеров JSON вызывали огромную проблему безопасности. Кто-то принял загрузку файлов JSON, проверил безопасность содержимого с помощью синтаксического анализатора A и, если это было принято, использовал содержимое небезопасным образом с синтаксическим анализатором B. Если вы использовали один и тот же ключ несколько раз, один синтаксический анализатор использовал первую, другой - последнюю запись, и файлы конфигурации IIRC JSON, созданные с учетом этого, были вектором атаки для враждебного захвата их сервера.

Alexander 21.10.2019 13:23

У вас может есть комментарии в JSONP, но не в чистом JSON. Я только что потратил час, пытаясь заставить мою программу работать с этим примером из Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

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

?(/* AAPL historical OHLC data from the Google Finance API */
[
/* May 2006 */
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);

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

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

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

{

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

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

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

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

}

Вы эмулировали файловую структуру INI в JSON. Пожалуйста, положи свой Золотой Молоток.

Artur Czajka 18.11.2013 20:53

RFC говорит: «Имена внутри объекта ДОЛЖНЫ быть уникальными». Также посмотрите этого человека, у которого возникла ошибка при синтаксическом анализе JSON, как показано выше: stackoverflow.com/questions/4912386/…

William Entriken 10.06.2014 19:58

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

gregsdennis 26.06.2015 03:32

Если вы действительно полны решимости добавить комментарии к вашему JSON, было бы гораздо разумнее сделать что-то вроде этого: { "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } Это сохраняет имя уникальным и позволяет вам добавлять любое строковое значение, которое вам нравится. Это все еще путаница, потому что комментарии не должны быть частью вашего JSON. В качестве другой альтернативы, почему бы не добавить комментарии до или после вашего JSON, но не внутри него?

Jazimov 05.09.2015 01:51

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

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

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

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

Just make sure your "notex" names don't conflict with any real fields. - это проблема. Это не произвольное решение.
William Entriken 14.05.2014 18:42

Это также представляет проблему, заключающуюся в том, что комментарии не могут быть удалены утилитой минификации перед передачей, что неизбежно приводит к передаче больших объемов данных, которые не служат никакой цели на другом конце передачи. Я действительно считаю, что исключать поддержку комментариев из спецификации JSON - это прискорбно. В частности, потому, что люди СОБИРАЮТСЯ вместе взламывать решения. Исключение поддержки из спецификации - это попытка поведенческого контроля, которая просто потерпит неудачу и приведет к еще большей несовместимости в будущем из-за распространения взаимно несовместимых обходных путей.

Craig 15.09.2014 11:07

в файлах конфигурации я использую {"/* ---- my section ----*/":0}. Это действительный JSON, поскольку JSON принимает любой символ в ключевой строке. Он не будет конфликтовать с другими свойствами, и никого не волнует или его переупорядочивают. Тем не менее, 2 комментария не должны совпадать.

olivr 08.04.2015 06:46

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

gregsdennis 26.06.2015 03:30

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

slim 20.10.2016 12:28

Чем это отличается от предыдущих ответов?

Peter Mortensen 08.10.2020 19:59

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

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

Kyle Simpson 09.12.2013 01:58

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

Joshua Richardson 12.12.2013 03:52

+1 за ссылку! На самом деле я думаю, что это хорошо, что комментарии не поддерживаются, потому что при отправке данных между клиентом и сервером комментарии совершенно бесполезны и дарят большую полосу пропускания. Это как если бы кто-то попросил оставить комментарии в структуре MP3 или блоке данных JPEG ...

Alexis Wilke 26.06.2014 12:45

Спасибо за +1! Вы должны помнить, что JSON используется не только для связи между сервером и клиентом. Кроме того, в зависимости от размера ваших данных и размера пакета отправка комментариев может вообще не увеличить вашу пропускную способность, и для вашего клиента может быть полезно иметь доступ к дополнительному контексту, и вы всегда можете попросить сервер удалить комментарии, если вы не хотел отправлять их по сети.

Joshua Richardson 27.06.2014 07:13

Что сказал @ kyle-simpson. Кроме того, он слишком скромен, чтобы направлять читателей к своему собственному ответу об использовании JSON.minify в качестве альтернативы специальным регулярным выражениям. Делай это, а не это.

toolbear 07.08.2014 23:06

@AlexisWilke, «комментарии абсолютно бесполезны и даром увеличивают пропускную способность» - именно поэтому комментарии должны поддерживаться в спецификации. Просто посмотрите на количество предлагаемых обходных путей, которые включают в себя множество разных, но похожих способов вложения комментариев в JSON в качестве данных, гарантируя, что инструмент минификации не может удалить комментарии, гарантируя, что они передаются по сети, и заставляя удаленный синтаксический анализатор бороться с ними с разной степенью успеха. Вы пытаетесь идеологически принудить людей, а они находят способы обойти вас. Так оно и есть ...

Craig 15.09.2014 11:11

@Craig, почему бы не использовать C / C++ подобные комментарии на своей стороне и использовать cpp для их удаления? (с cpp от gcc вы хотите использовать -P (заглавная P), чтобы избежать записей # <line#> ....) Я думаю, это достаточно просто.

Alexis Wilke 16.09.2014 01:48

@AlexisWilke, все в порядке, за исключением того, что это не стандарт JSON, и вы не можете просто предположить, что я работаю над Linux и могу распределять и передавать свои файлы через cpp - я не Поэтому я добавил в свою программу код, чтобы исключить комментарии C / C++. На самом деле я хочу сказать, что люди все равно найдут способ добавлять комментарии, но теперь они будут добавлять их как данные JSON в миллионе немного разных форматов, которые ни один автоматический инструмент не может обнаружить и удалить из потока данных, поэтому попытка удаление комментариев приведет к извращенному гарантия существованию комментариев в JSON и увеличению объемов передачи данных.

Craig 16.09.2014 18:39

@Craig, в качестве примечания, cpp доступен под MS-Windows. Хотя, откровенно говоря, написать свой собственный небольшой инструмент, вероятно, так же просто, чем возиться с cygwin или MinGW ... Теперь я согласен, что это не совсем JSON, но похоже, что многие интерпретаторы понимают подобное расширение (комментарии C / C++.)

Alexis Wilke 17.09.2014 01:25

@AlexisWilke в какой-то момент, однако, разве все это не похоже на героические попытки просто добавить комментарий в ваш файл JSON? В моем случае мне просто нужен немного кода (а не весь компилятор C / C++, работающий в дополнительной библиотеке времени выполнения, не менее, если он работает под Cygwin / Ming), чтобы удалить комментарии, прежде чем я смогу передать свои файлы конфигурации через парсер JSON. Я также обнаруживаю, когда файлы конфигурации меняются, и динамически их перезагружаю, и т. д. Как это отстой, что я не могу просто помещать комментарии в файлы и не беспокоиться об этом? Это супер хромает. Вот сколько. ;-)

Craig 17.09.2014 03:45

Ваше решение интерпретатора JS - это подход Нэнси Пелоси к синтаксическому анализу JSON: вы должны передать его, чтобы узнать, что в нем. Конечно, могут быть непреднамеренные побочные эффекты.

William Entriken 20.08.2015 17:54

Обратите внимание, что регулярное выражение не работает с URL-адресами: "url": "http: // ... (ой!). Вам определенно понадобится настоящий парсер" JSON + comments "для удаления комментариев.

Florian F 03.07.2016 14:13

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

Dominic Cerisano 05.11.2018 05:55

@KyleSimpson Меня удивило ваше утверждение: «JSON - это не обычная грамматика, поэтому регулярных выражений недостаточно». Вы уверены, что регулярных выражений недостаточно? Тот факт, что JSON не является обычным языком, не обязательно означает это. Указанные вами тонкости (независимо от того, экранирован ли / * или находится внутри строкового литерала), безусловно, могут быть обработаны с помощью регулярного выражения.

Don Hatch 23.04.2019 20:14

@DonHatch Я уверен, что регулярные выражения не могут точно анализировать нерегулярные языки. Это своего рода определение терминов: регулярное выражение анализирует регулярные языки. Этот вопрос похож на часто обсуждаемый: «Можно ли разобрать HTML с помощью регулярного выражения?» В конкретном случае однозначный ответ - несомненно, но в общем случае - нет. Регулярные выражения, которые были расширены обратными ссылками и рекурсией, могут анализировать более сложные языки, но не все нерегулярные языки.

Kyle Simpson 24.04.2019 21:32

@KyleSimpson Я понимаю, что регулярное выражение не может полностью анализировать язык, но это не обязательно означает ваше более сильное утверждение, что никакое регулярное выражение не может идентифицировать и удалять комментарии на этом языке. С точки зрения lex / yacc, я подозреваю, что идентификация / удаление комментариев может быть выполнена с помощью lex (токенизатора, который понимает только обычный язык), в то время как yacc потребуется для полного анализа языка.

Don Hatch 24.04.2019 22:23

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

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

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

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

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

user2073253 13.02.2014 00:24

RFC говорит: «Имена внутри объекта ДОЛЖНЫ быть уникальными». См. Сообщение об этой ошибке по адресу: stackoverflow.com/questions/4912386/…

William Entriken 10.06.2014 19:59

Это приглашение к созданию JSON, которое внезапно обрушится на вас в будущем.

toolbear 07.08.2014 23:00

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

Mark Lakata 27.05.2015 01:26

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

gnasher729 06.10.2017 21:24

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

Christian Hujer 01.01.2018 10:12

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

ggb667 16.01.2018 19:44

@toolbear JSON не «взрывается». Парсер делает. Сомнительное решение. Но не хуже, чем добавление "_comment". Может лучше, чем ничего.

Rolf 14.02.2018 05:30

json не упорядочен, поэтому он будет взорваться примерно в 50% случаев (по крайней мере, в Go, где, если порядок не определен, он рандомизируется)

Darshan Chaudhary 16.05.2018 13:35

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

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

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

{
  key: "value" // Comment
}

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

mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);

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

это обратимо? что, если вы загрузите файл и запишете его обратно?

R. Du 19.11.2020 21:11

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

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

Hjson intro

См. hjson.github.io для библиотек JavaScript, Java, Python, PHP, Rust, Go, Ruby, C++ и C#.

если вы посмотрите на спецификацию, вы увидите, что это надмножество json. вы можете конвертировать из / в json.

laktak 12.06.2014 18:53

Проголосовали. Очевидно, что это хороший вариант, который непокрытым консерваторам просто хотелось бы ненавидеть. Я надеюсь, что ваша реализация станет известна дальше - и, возможно, даже станет более популярной, чем оригинал;) Я надеюсь, что кто-то сможет реализовать ее и с Ruby. @adelphus Четкое определение языка - это ваша собственная точка зрения или мнение. Если вы консервативный «разработчик», это еще не доказывает, что вы лучше, и вам может быть еще хуже, если вы заперты в ограниченном пространстве. Не осуждайте людей как ужасных разработчиков.

konsolebox 30.06.2014 23:20

Извини, @konsolebox. Возможно, вы могли бы пересмотреть свою точку зрения «четко определенный JSON - ваше мнение» после прочтения ecma-international.org/publications/files/ECMA-ST/ECMA-404.p‌ df. Это настоящий стандарт, и разработчики, внедряющие свои собственные «специальные» версии, приводят к фрагментации, путанице и потере времени. Посмотрите, какой беспорядок остается у веб-разработчиков при написании кода только потому, что каждый браузер реализует несколько разные версии стандартов. Язык JSON может быть несовершенным, но фрагментация еще хуже. И да, это всего лишь мнение, и вы можете не согласиться.

adelphus 09.07.2014 20:02

Я восхищаюсь вашей смекалкой, но вы как бы заново изобретаете YAML. Если вам нужна большая гибкость и удобочитаемость, используйте YAML (на самом деле не stackoverflow.com/questions/450399/…) или придерживайтесь скупого, но однозначного JSON.

toolbear 07.08.2014 22:25

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

Matt 10.02.2015 18:15

Всякий раз, когда вам нужен json в качестве конфигурации (где нужны комментарии являются) - назовите свой файл «.js» вместо «.json» .. js, конечно, может обрабатывать любой допустимый объект json и, кроме того, может обрабатывать комментарии .. Вот почему это "webpack.config.js", а не "webpack.config.json" (ну, в webpack есть еще много причин для этого: P)

jebbie 06.04.2016 17:20

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

RobG 03.01.2019 03:32

Сообщите об этом разработчикам Шутка (например, конфигурационный файл package.json).

Peter Mortensen 08.10.2020 20: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;

RFC только заявляет, что «пробелы разрешены до или после любого из шести структурных символов», без явного упоминания строк, чисел, «false», «true», «null». Это упущение игнорируется во ВСЕХ реализациях.

William Entriken 24.09.2014 22:15

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

Claire Nielsen 26.09.2018 22:44

ДОЛЖЕН НЕ ОБЯЗАТЕЛЬНО. См. Явно включенный RFC 2119: MUST: это слово или термины «ТРЕБУЕТСЯ» или «ДОЛЖЕН» означают, что определение является абсолютным требованием спецификации. ... СЛЕДУЕТ: это слово или прилагательное «РЕКОМЕНДУЕТСЯ» означает, что в определенных обстоятельствах могут существовать веские причины для игнорирования конкретного пункта, но все последствия должны быть поняты и тщательно взвешены, прежде чем выбирать другой курс.

Jeff K 23.09.2019 21:04

Хорошая ссылка. Лучшим аргументом против использования дублированных ключей является стандартная цитата: «Когда имена внутри объекта не уникальны, поведение программного обеспечения, которое получает такой объект, непредсказуемо». Также теперь я понимаю, почему стандарт не был «ДОЛЖЕН быть уникальным», это упрощает валидатор, ему нужно только отслеживать [и {, ему не нужно знать, какие ключи уже использовались.

William Entriken 26.09.2019 23:22

Я только что нашел "grunt-strip-json-comments".

“Strip comments from JSON. It lets you use comments in your JSON files!”

{
    // Rainbows
    "unicorn": /* ❤ */ "cake"
}

Можно также уменьшить этот JSON, пока вы на нем. См. Ответ @ kyle-simpson о JSON.minify.

toolbear 07.08.2014 22:54

Да, вы можете, но ваш синтаксический анализ, вероятно, не удастся (стандарта нет).

Чтобы разобрать его, вы должны удалить эти комментарии вручную или с помощью регулярного выражения:

Он заменяет любые комментарии, например:

/****
 * Hey
 */

/\/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*\/+/

Он заменяет любые комментарии, например:

// Hey

/\/\/.*/

В JavaScript вы можете сделать что-то вроде этого:

jsonString = jsonString.replace(/\/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*\/+/, "").replace(/\/\/.*/,"")
var object = JSON.parse(jsonString);

Ваше регулярное выражение удалит такие вещи, как /*hey*/, даже из внутренних строк.

6502 03.08.2014 10:09

Хороший улов! Так что просто измените кое-что в регулярном выражении.

Maurício Giordano 05.08.2014 22:10

Регулярные выражения для структурированных языков, как известно, сложно сделать правильно. Ознакомьтесь с ответом @kyle-simpson о JSON.minify как альтернативе специальным регулярным выражениям.

toolbear 07.08.2014 22:57

Что касается "(нет стандарта)", то, безусловно, существует стандарт является, который точно определяет, что такое JSON, и он появился задолго до того, как был написан этот ответ.

meagar 05.09.2018 16:07

@meagar Я так и не ответил на ваш комментарий. Я имел в виду стандартную ссылку на комментарии, пожалуйста, дайте мне знать, если вы можете найти здесь что-нибудь связанное с этим json.org/json-en.html

Maurício Giordano 01.06.2020 23:36

@ MaurícioGiordano Нет, там ничего нет, потому что JSON не поддерживает комментарии. Конечно, в стандарте не требуется явно указывать это, равно как и явно указывать, что у него нет классов.

meagar 02.06.2020 03:36

Это регулярное выражение по-прежнему не работает для допустимого ввода. Например, "\"/*foo*/\". Как уже отмечалось ранее, использование регулярного выражения - действительно плохая идея.

meagar 02.06.2020 03:38

Если ваш контекст - конфигурация Node.js, вы можете рассмотреть JavaScript через module.exports в качестве альтернативы JSON:

module.exports = {
    "key": "value",

    // And with comments!
    "key2": "value2"
};

Синтаксис require останется прежним. Поскольку это JavaScript, расширение файла должно быть .js.

Я действительно думал, что нет смысла переходить на вторую страницу ответов на этот вопрос, но это ИМЕННО то, что я искал, и работает безупречно! благодаря.

rob 01.06.2017 17:04

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

//"name": "string"

//"id": int

или же

/* This is a

comment example */

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

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

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

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

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

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

dvdmn 29.07.2014 18:17

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

toolbear 07.08.2014 22:12

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

John 20.08.2014 20:48

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

gman 06.06.2019 06:35

Мы используем 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, если он включает эти комментарии о приличиях.

Roy Prins 31.07.2019 15:12

В каком контексте запускается strip-json-comments? Node.js?

Peter Mortensen 08.10.2020 20:06

@PeterMortensen, я пробовал использовать node.js. вы можете попробовать, работает ли на стороне клиента js.

Joy 09.10.2020 02:44

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

Одним из ярких примеров является "Hashcorp Language" (HCL) ". Это написано теми же людьми, которые создали Бродягу, упаковщика, консула и хранилище.

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

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

Как уже отмечалось во многих ответах, JSON изначально не имеет комментариев. Конечно, иногда они все равно нужны. Для Python это можно сделать двумя способами: commentjson (# и // только для Python 2) или json_tricks (# или // для Python 2 и Python 3), который имеет несколько других функций. Отказ от ответственности: я сделал json_tricks.

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


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

Не могли бы вы добавить пример? Тогда вам действительно могут понадобиться эти дополнительные символы.

dgilperez 17.12.2015 03:15

Руководящие принципы SO требуют предоставления фактического ответа. Ответы только по ссылкам нежелательны. Вы можете проверить рекомендации stackoverflow.com/help/how-to-answer

dgilperez 29.12.2015 23:06

SO модерируется пользователями. Это означает, что я могу дать ответ, если он у меня есть, так же, как я могу прокомментировать ваш, если он не соответствует рекомендациям. Вот как SO становится отличным ресурсом.

dgilperez 30.12.2015 14:21

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

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

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. - Douglas Crockford, 2012

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

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

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

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

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

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

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

Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. - Douglas Crockford, 2012

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

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

Входной JSON (файл input.js):

/*
* multi-line comments
**/
{
    "value": 123 // one-line comment
}

Тестовое приложение:

var decomment = require('decomment');
var fs = require('fs');

fs.readFile('input.js', 'utf8', function (err, data) {
    if (err) {
        console.log(err);
    } else {
        var text = decomment(data); // removing comments
        var json = JSON.parse(text); // parsing JSON
        console.log(json);
    }
});

Выход:

{ value: 123 }

См. Также: глоток-разложение, хрюканье

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

meagar 05.09.2018 15:41

@meagar Была спецификация JSON5, которая, помимо прочего, поддерживала комментарии. Но в итоге это так и не стало стандартом.

vitaly-t 05.09.2018 15:45

Вы можете использовать JSON-LD и тип schema.org комментарий для правильного написания комментариев:

{
    "https://schema.org/comment": "this is a comment"
}

Если вы используете PHP, вы можете использовать эту функцию для поиска и удаления комментариев // / * типа из строки JSON перед ее синтаксическим анализом в объект / массив:

function json_clean_decode($json, $assoc = true, $depth = 512, $options = 0) {
       // search and remove comments like /* */ and //
       $json = preg_replace("#(/\*([^*]|[\r\n]|(\*+([^*/]|[\r\n])))*\*+/)|([\s\t]//.*)|(^//.*)#", '', $json);

       if(version_compare(phpversion(), '5.4.0', '>=')) {
           $json = json_decode($json, $assoc, $depth, $options);
       }
       elseif(version_compare(phpversion(), '5.3.0', '>=')) {
           $json = json_decode($json, $assoc, $depth);
       }
       else {
           $json = json_decode($json, $assoc);
       }

       return $json;
   }

Надеюсь это поможет!

категория решения == 'преобразовать через предварительную обработку'

dreftymac 04.12.2016 15:59

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

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

Enter image description here

Да, вы можете оставлять комментарии. Но я не буду рекомендовать какую-либо причину, упомянутую выше.

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

Note: tested on Node.js only ;-)

var oldParse = JSON.parse;
JSON.parse = parse;
function parse(json){
    json = json.replace(/\/\*.+\*\//, function(comment){
        console.log("comment:", comment);
        return "";
    });
    return oldParse(json)
}

Файл JSON:

{
  "test": 1
  /* Hello, babe */
}
{ what_if: "I happen to have /* slashes and asterisks */ in my data?" }
DSimon 22.12.2016 17:24

Я имею в виду, что для большинства языков вам не нужно беспокоиться о последовательностях комментариев внутри строк. Даже в реализации JSON, которая поддерживает комментарии, я ожидал бы, что анализ моего примера приведет к объекту с ключом "what_if" и значением "I happen to have /* slashes and asterisks */ in my data?", а не "I happen to have in my data".

DSimon 22.12.2016 18:01

Используя регулярное выражение, вы можете избежать преобразования данных в формат. Насколько я понимаю, так быть не должно. JSON используется как данные, а не как язык. Так что избегайте мусора или комментариев в данных. :-D Большую часть языка вы пишете код, который компилируется в каком-то другом формате. Здесь, в JS, это динамическое связывание. Такой компиляции не бывает. V8 делает некоторую оптимизацию, но это также метод проталкивания и отказа.

xdeepakv 22.12.2016 18:56

@DSimon Я согласен ... во многих случаях это работает: json.replace(/("\/\/.*"|"\/\*(?:.|\n)*?")|(\/\/.*|\/\*(?:.|\‌​n)*?\*\/)/g, "$1")regexr.com/3p39p

Maxim Paperno 08.05.2018 07:36

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

function json_decode_commented ($data, $objectsAsArrays = false, $maxDepth = 512, $opts = 0) {
  $data = preg_replace('~
    (" (?:[^"\\\\] | \\\\\\\\ | \\\\")*+ ") | \# [^\v]*+ | // [^\v]*+ | /\* .*? \*/
  ~xs', '$1', $data);

  return json_decode($data, $objectsAsArrays, $maxDepth, $opts);
}

Он поддерживает все комментарии в стиле PHP: / *, #, //. Строковые литералы сохраняются как есть.

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

Этот метод нарушает работу некоторых библиотек, которые требуют, чтобы ключ был уникальным. Я работаю над этой проблемой, нумеруя комментарии.

MovGP0 19.01.2018 14:45

хороший комментарий, я нашел этот вопрос на SO ... эта часть, похоже, не покрывается спецификацией stackoverflow.com/questions/21832701/…

mana 20.01.2018 22:36

Сейчас я обычно использую это так: {"// foo": "foo comment", "foo": "foo value", "// bar": "bar comment", "bar": "bar value"} Вы можете использовать массив для нескольких комментариев: {"// foo": ["foo comment 1", "foo comment 2"], "foo": '' foo value "}

MovGP0 09.03.2018 19:29

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

If you try to put comments in (using // or /* */ or # for instance), then some parsers will fail because this is strictly not within the JSON specification. So you should never do that.

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

{
    "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."
    }
}

Ссылка "аргументация" не работает. Есть ли шанс найти текущую ссылку на него?

Don Hatch 23.04.2019 20:05

Дон, к сожалению, Google уничтожил систему социальных сетей, в которой содержался пост; Я понятия не имею, куда делся исходный плакат, если и куда. Я убью ссылку в приведенной выше информации, чтобы устранить двусмысленность. Спасибо.

fyngyrz 24.04.2019 16:50

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

Dominic Cerisano 14.07.2019 19:30

Если в спецификации указано, что «строка, начинающаяся с #, является комментарием», то это будет полностью совместима.. В существующем виде, оба комментария загружают пространство синтаксического анализатора, поскольку они являются действительными проанализированные предметы, а не воспринимаются как комментарии, и они могут быть разными для каждый существующий файл .json. Если (например) в спецификации сказано, что «строки, начинающиеся с #, являются комментариями», то парсеры могут пропустить эти строки без синтаксического анализа (быстрее) и не загружать пространство парсера (лучшее использование памяти). Нет никакой пользы от отсутствия комментариев в .json, только минусы.

fyngyrz 28.01.2020 17:41

Файлы * .json обычно используются как файлы конфигурации или статические данные, поэтому комментарии необходимы → некоторые редакторы, такие как NetBeans, принимают комментарии в * .json.

Проблема заключается в синтаксическом разборе содержимого объекта. Решение - всегда применять функцию очистки (сервер или клиент).

### PHP

 $rgx_arr = ["/\/\/[^\n]*/sim", "/\/\*.*?\*\//sim", "/[\n\r\t]/sim"];
 $valid_json_str = \preg_replace($rgx_arr, '', file_get_contents(path . 'a_file.json'));

### JavaScript

valid_json_str = json_str.replace(/\/\/[^\n]*/gim,'').replace(/\/\*.*?\*\//gim,'')

Что такое "комментарий"?

Peter Mortensen 08.10.2020 19:57

Весь этот поток предполагает, что добавление комментариев - единственное улучшение, которое необходимо внести в JSON. Если кому-то не нужны комментарии в JSON, потому что он будет использоваться для сериализации, просто опустите комментарии. То же самое и с пробелами. Но зачем останавливаться на достигнутом? Почему в JSON используются кавычки требуется? Ничего полезного они не добавляют.

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

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

{stringA: stringB, stringC: stringD, [stringE, stringF]}

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

Необходимо включить кавычки, апострофы, запятые или квадратные скобки в свойство или значение? Просто заключите их в вопросительные знаки или апострофы (с экранированием обратной косой черты), как в JavaScript.

Но, пожалуйста, сделайте кавычки необязательными. Почему? Поскольку JSON не может содержать имена переменных или функций (во избежание атак с использованием инъекций), кавычки не позволяют устранить неоднозначность. Мы уже знаем, что все данные представляют собой строки. Поэтому, пожалуйста, опускайте кавычки, если они действительно не нужны.

Возможно, вас заинтересует yaml (yaml.org), квази-надмножество json, которое допускает комментарии и не требует кавычек.

Bill Cheatham 10.01.2019 14:54

Мой любимый ответ здесь. Поскольку можно написать свой собственный парсер, я надеюсь, что кто-то напишет (или уже написал) широко используемый парсер json, который устраняет необходимость в кавычках, допускает комментарии и другие улучшения. Как насчет удаления скобок и форматирования с помощью пробелов? :)

johny why 13.04.2020 22:13

Практический ответ для пользователей Код Visual Studio в 2019 году - использовать расширение jsonc.

Это практично, потому что это расширение, распознаваемое Visual Studio Code для обозначения «JSON с комментариями». Пожалуйста, дайте мне знать о других редакторах / IDE в комментариях ниже.

Было бы неплохо, если бы Visual Studio Code и другие редакторы также добавили встроенную поддержку JSON5, но на данный момент Visual Studio Code включает поддержку только для jsonc.

(Я просмотрел все ответы, прежде чем опубликовать это, и ни один не упомянул jsonc.)

jsonc хорош, но, к сожалению, вы ограничены // комментариями. Когда вам нужно что-то еще, вы тоже немного сломаны. stackoverflow.com/questions/58553633/…
GhostCat 25.10.2019 10:52

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

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

fetch(filename).then(function(response) {
    return response.text();
}).then(function(commented) {
    return commented.
        replace(/\/\*[\s\S]*?\*\/|([^\\:]|^)\/\/.*$/gm, '$1').
        replace(/\r/,"\n").
        replace(/\n[\n]+/,"\n");
}).then(function(clean) {
    return JSON.parse(clean);
}).then(function(json) {
    // Do what you want with the JSON object.
});

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

Я использовал эту простую функцию Python для замены комментариев и использовал json.loads для преобразования ее в dict:

import json, re

def parse_json(data_string):
  result = []
  for line in data_string.split("\n"):
    line = line.strip()
    if len(line) < 1 or line[0:2] == "//":
      continue
    if line[-1] not in "\,\"\'":
      line = re.sub("\/\/.*?$", "", line)
    result.append(line)
  return json.loads("\n".join(result))

print(parse_json("""
{
  // This is a comment
  "name": "value" // so is this
  // "name": "value"
  // the above line gets removed
}
"""))

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

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

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

Insignificant whitespace is allowed before or after any token. Whitespace is any sequence of one or more of the following code points: character tabulation (U+0009), line feed (U+000A), carriage return (U+000D), and space (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 для его кодирования / декодирования на лету).

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

Это довольно забавно.

Evert 21.03.2021 05:57

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

{
    "//name": "Name comment here",
    "name": "Jack",

    "//age": "Age comment here",
    "age": "25"
}

Большинство парсеров JSON игнорируют свойства, которые не отображаются.

Чем это отличается от предыдущих ответов?

Peter Mortensen 08.10.2020 19:48

Спецификация JSON не поддерживает комментарии в стиле // or /* */.

Но некоторые библиотеки синтаксического анализа JSON и IDE их поддерживают.

Нравиться:

  1. JSON5
  2. Код Visual Studio
  3. Комментарий

Код VS .jsonc FTW ?

Quang Van 13.01.2020 18:28

JSON5 - не пятая версия JSON.

Peter Mortensen 08.10.2020 19:51

Технически нет. Но вы можете решить эту проблему следующим образом.

{
  "json": "actual data goes here, comments below",
  "comment1": "Lorem ipsum dolor sit amet",
  "comment2": "consectetur adipiscing elit"
}

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

Чем это отличается от предыдущих ответов?

Peter Mortensen 08.10.2020 19:51

да. Вы можете помещать комментарии в файл JSON.

{
    "": "Location to post to",
    "postUrl": "https://example.com/upload/",

    "": "Username for basic auth",
    "username": "joebloggs",

    "": "Password for basic auth (note this is in clear, be sure to use HTTPS!",
    "password": "bloejoggs"
}

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

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

N.B.«Имена внутри объекта ДОЛЖНЫ быть уникальными». (Источник: Спецификация IETF JSON, декабрь 2017 г.
Rounin 15.06.2020 19:54

ДОЛЖЕН означает нечто иное, чем ДОЛЖНО в спецификации. Другие ответы с комментариями сломают все парсеры JSON. Мне было бы интересно узнать, есть ли у дублирующихся ключей какие-либо плохие побочные эффекты.

nevelis 16.06.2020 00:56

Моя точка зрения (просто) заключалась не в том, что имена внутри объекта ДОЛЖНЫ быть уникальными, а просто в том, что они ДОЛЖНЫ быть уникальными. После просмотра Stack Overflow (и всей сети) в течение дня Я приложил все усилия, чтобы придумать собственный подход.

Rounin 16.06.2020 01:21

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

nevelis 16.06.2020 01:57

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

Rounin 16.06.2020 02:00

Когда вы, нет, захотите видеть комментарии в нужном месте ?!

nevelis 18.06.2020 19:35

Эй, я думаю, у нас недоразумение. Меня не волнует чтение комментариев в проанализированном объекте JSON в Javascript. Я хочу, чтобы 1) я мог читать содержательные комментарии, когда я редактирование источника (т.е. НЕ во время выполнения), и 2) я не комментирую в своем JSON, чтобы нарушить парсеры, соответствующие стандартам.

nevelis 18.06.2020 19:36

Я плохо это объяснил. В подходе, который я предусмотрел, комментарии полностью отсутствуют ни в одном объекте, анализируемом из JSON. Тем не менее, комментарии видны в нужном месте в пользовательском ридере (ридере / писателе / ​​редакторе), в котором вы можете читать, писать и редактировать файл JSON. (А в нестандартном ридере они располагаются в блоке внизу JSON, вне поля зрения всех данных).

Rounin 18.06.2020 21:12

Мне очень нравится подход @eli, есть более 30 ответов, но никто не упомянул списки (массив). Итак, используя подход @eli, мы могли бы сделать что-то вроде:

"part_of_speech": {
  "__comment": [
    "@param {String} type - the following types can be used: ",
      "NOUN, VERB, ADVERB, ADJECTIVE, PRONOUN, PREPOSITION",
      "CONJUNCTION, INTERJECTION, NUMERAL, PARTICLE, PHRASE",
    "@param {String} type_free_form - is optional, can be empty string",
    "@param {String} description - is optional, can be empty string",
    "@param {String} source - is optional, can be empty string"
  ],
  "type": "NOUN",
  "type_free_form": "noun",
  "description": "",
  "source": "https://google.com",
  "noun_class": {
    "__comment": [
      "@param {String} noun_class - the following types can be used: ",
        "1_class, 2_class, 3_class, 4_class, 5_class, 6_class"
    ],
    "noun_class": "4_class"
  }
}

да, новый стандарт, 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 это файлы конфигурации и другие документы, которые могут быть написаны, отредактированы или прочитаны людьми, а не только парсером.

Является ли JSON5 "очень" стандартным? Или все еще усыновляется? Я имею в виду ... Могу ли я ожидать, что в 2021 году любой фреймворк будет понимать Json5? Или, скорее всего, нет?

Xavi Montero 28.03.2021 16:53

Если вы создаете свой собственный стандарт, вы единственный в мире, кто его использует. Что-то вроде JSON5, наверное, лучше.

Audrius Meskauskas 29.03.2021 00:09

Не предназначено для создания моего стандарта ... просто интересно, пора ли рассмотреть JSON5 или лучше придерживаться «старого JSON» и подождать еще несколько месяцев, прежде чем посвятить время исследованию.

Xavi Montero 29.03.2021 22:00

Комментарии необходимы в JSON и комментарии доступны по крайней мере в .NET Core JSON и Newtonsoft Json. Прекрасно работает.

{
  // this is a comment for those who is ok with being different
  "regular-json": "stuff"...
}

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

AFract 17.03.2021 17:54

Если существуют парсеры JSON, которые анализируют нестандартный JSON, это не означает, что добавление комментариев разрешено в JSON.

Evert 21.03.2021 05:56

Другие вопросы по теме