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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К вашему сведению, база данных Firebase Realtime не позволяет использовать '/' в ключе. так что это может быть хорошим соглашением для вашего собственного использования, но вы не можете сделать это в Firebase

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

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

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

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

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

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

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

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

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

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

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

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

Код VS .jsonc FTW ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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