Как писать коментарии в json-конфиге?
Есть конфиг файл в формате json . Нужно закоментировать одну строку и попробовать другое значение. Ну и сопроводиловку для будущего себя накатать. Какой знак за это отвечает?
Отслеживать
задан 13 сен 2016 в 6:19
don Rumata don Rumata
4,205 3 3 золотых знака 19 19 серебряных знаков 41 41 бронзовый знак
Сам по себе json может содержать коментарии(только никто так не делает) зависит от парсера. Лично сталкивался с json содержащим // или /**/ коментарии.
18 окт 2018 в 13:18
Я не про костыли. Я именно про общепринятый стандарт. Понятно, что можно даже синтаксис полностью переделать с парсером вместе. И всем говорить, что это немного другой json.
18 окт 2018 в 20:55
В общепринятом стандарте json не предусмотрены комментарии. Однако даже .NET Newtonsoft.Json спокойно их проглатывает — <"key":"value" // comment>не вызовет ошибки парсинга. правда тут стоит понимать что другой парсер может оказаться менее лояльным.
Konstantin Shibkov
Как писать комментарии в JSON Body в Postman
Как писать комментарии в JSON запросе теле в Postman
Время чтения: 2 мин.
Нравится мне работать с Postman при работе с API и тестах своих контроллеров.
И как-то прекрасным днем, пришлось написать большой JSON кусок и отправить для запроса. Он состоял из набора uuid и мне хотелось в разных версиях данных пометить, как для человека, что там за ними скрывается.
Есть комментарии подумал я, и быстро набросал:
// Не используйте 42 в полях "key": "value", //описание поля, заметки "yet-another-key": true //true for truth > Да, это не тот запрос-монстр, а просто пример.
�� Но такой запрос сервер не принял, так и сказал — мне ваши комментарии синтаксически не нужны. Присылайте без них.
Не вопрос, есть в Postman Pre-request Script. JS скрипт, который исполняется перед запросом. Там и можно очистить запрос от комментов.
Копируй скрипт и вставляй:
// Strip JSON Comments if (pm?.request?.body?.options?.raw?.language === 'json') const rawData = pm.request.body.toString(); const strippedData = rawData.replace( /\\"|"(?:\\"|[^"])*"|(\/\/.*|\/\*[\s\S]*?\*\/)/g, (m, g) => g ? "" : m ); pm.request.body.update(JSON.stringify(JSON.parse(strippedData))); > Скрипт распаковывает json в строку, далее удаляет комментарии и обновляет тело запроса.
Не сразу после этого взлетело, на меня ругались что формат переданных данных не application/json , а text/plain . Хотя в postman в Headers был установлен формат Content-Type . Скорее, после манипуляций формат ломался.
Решается добавлением своего параметра в Headers
Content-Type : application/json 
✨ Красота! Теперь можно немного расслабить мозг и не запоминать, за что отвечают наборы нечитаемых значений в json.
Как комментировать файлы JSON
Если у вас возникли проблемы с добавлением комментариев к файлу JSON, на то есть веская причина: JSON не поддерживает комментарии.
“Я убрал комментарии из JSON, потому что увидел, что люди используют их для парсинга директив — практика, которая разрушила бы совместимость”, — пишет Дуглас Крокфорд, популяризировавший текстовый формат данных.
Однако есть и обходной путь. И эта статья посвящена именно ему.
Добавляйте данные в виде комментариев
Чтобы обойти проблему комментариев, добавьте в свой файл JSON данные, которые функционируют как комментарии.
Давайте рассмотрим это на примере. Начнем с файла JSON, в котором содержится следующая информация:
"sport": "basketball",
"coach": "Joe Smith",
"wins": 15,
"losses": 5
>
Теперь давайте добавим еще одну пару ключ-значение, чтобы она служила для нас комментарием — как вы можете видеть в первой строке кода ниже:
"_comment1": "здесь мой комментарий",
"sport": "basketball",
"coach": "Joe Smith",
"wins": 15,
"losses": 5
>
Вот еще один пример. На этот раз мы используем два подчеркивания — в начале и в конце ключа:
"__comment2__": "здесь другой комментарий",
Подчеркивание помогает отличить комментарий от остальных данных в файле.
Небольшое предостережение
Есть одна важная деталь, которую нужно иметь в виду.
Комментарии, которые мы добавили в файл JSON, включены в объект JSON. Другими словами, комментарии рассматриваются как данные.
Вот что имеется в виду.
"_comment1": "здесь мой комментарий",
"sport": "basketball",
"coach": "Joe Smith",
"wins": 15,
"losses": 5
>
Теперь мы собираемся прочитать эти данные из файла read_comments.py :
import json
with open("data.json", mode="r") as j_object:
data = json.load(j_object)
print(data)
Результат включает в себя наш комментарий:
Мы даже можем извлечь значение комментария из объекта JSON: this is my comment :
import json
with open("data.json", mode="r") as j_object:
data = json.load(j_object)
print(data["_comment1"])
Имейте в виду, что такой комментарий является комментарием только в глазах разработчика, а не компьютера.
Другой тип комментария
Эта практика комментирования JSON отличается от комментариев в языках программирования, таких как Python, которые обычно игнорируются при запуске программы.
# Здесь мой комментарий
word = "house"
for letter in word:
print(letter)
Когда мы запускаем программу Python, приведенную выше, мы получаем буквы в слове “house”. Но мы не видим комментария. Он был проигнорирован.
Варианты комментирования
JSMin — это еще один вариант, стоящий рассмотрения.
Это инструмент, который удаляет лишние пробелы и комментарии из файлов JavaScript. Но он также работает и с файлами JSON. JSMin удаляет комментарии из файлов JSON до того, как они будут обработаны.
Таким образом, когда речь заходит о комментировании в файлах JSON, у вас есть варианты. Хотя эти решения и не идеальны, но по крайней мере дают возможность включить необходимую документацию, когда она вам нужна.
- 3 фундаментальных постулата JS, приближающих вас к Pro-статусу
- Добро пожаловать в ад…зависимостей JavaScript
- Движок JavaScript: что внутри
Евгений Степанищев
Пишу, по большей части, про историю, свою жизнь и немного про программирование. Живу в Казани.
Комментарии в формате JSON
Наткнулся случайно на ссылку, где автора очень изящно решает проблему комментариев в формате «джейсон». Это лучшее решение, которое я только видел (обычно либо выделяют специальный ключ, либо расширяют формат). Только поглядите:
Он полностью синтаксически верен и разбирается правильным образом во всех языках, по всей видимости.
37 комментариев
Работает. Но что-то в этом кривое. Хотя для web’а это привычно- там всё такое.
An object structure is represented as a pair of curly brackets
surrounding zero or more name/value pairs (or members). A name is a
string. A single colon comes after each name, separating the name
from the value. A single comma separates a value from a following
name. The names within an object SHOULD be unique.
Евгений Степанищев (bolknote.ru) 2014
Комментарий для RomaS:
SHOULD This word, or the adjective «RECOMMENDED», mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Евгений Степанищев (bolknote.ru) 2014
Комментарий для alxt:
Работает. Но что-то в этом кривое. Хотя для web’а это привычно — там всё такое.
Мда? Ну вот, скажем, Perl был разработан не для веба, а Си весь вызывает ощущение кривизны.
Я ж не говорю, что всё, что не для веба- хорошо 😀
SunChaser (sunchaser.info) 2014
Проверил — это так же норм жуётся парсерами Yaml в Ruby и PHP (ext-yaml)
Неправильно работает парсер Yaml в Symfony, но он и в целом плохо парсит JSON
(т. к. json подмножество yaml, неплохо бы не терять эту совместимость)
Евгений Степанищев (bolknote.ru) 2014
Комментарий для sunchaser.info:
Симфони поддерживает Yaml 1.2 же, а JSON — это Yaml 2.0, если не ошибаюсь.
Евгений Степанищев (bolknote.ru) 2014
Комментарий для alxt:
Ну так и утверждение «там всё такое» тоже неверно.
Евгений Степанищев (bolknote.ru) 2014
Комментарий для sunchaser.info:
Симфони поддерживает Yaml 1.2 же, а JSON — это Yaml 2.0, если не ошибаюсь.
Ошибаюсь, 2.0 не существует, как раз с 1.2 перепутал.
SunChaser (sunchaser.info) 2014
Комментарий для Евгения Степанищева:
ага, но там даже не Yaml 1.2, а «selected subset of features» из Yaml 1.2
Это все равно решение из разряда «костыль» т. к. стандарт JSON ничего не говорит о том, как обрабатывать дубликаты ключей в объекте. YAML например, прямо и явно их запрещяет. Это ведет к неопределенному поведению в различных библиотеках, которые могут совершенно спокойно взять первый ключ «с комментарием» и выбросить все остальные «с данными» — и это поведение будет совершенно корректно с точки зрения стандарта. Так же некоторые JSON парсеры раскладывают object не в hash-map, а в список ключ-значение сохраняя тем самым и «комментарий» и «значение» перекладывая на пользователя ответственность за дубликаты ключей — это поведение так же совершенно корректо с точки зрения стандарта.
Закладываться на такое поведение не рекомендуется — можно в один прекрасный момент наткнуться на интересные баги. Если нужны комментарии в JSON, возможно стоит обратить внимане на другие форматы. Или остановиться на том же YAML (для которого, кстати, JSON не является полным подмножеством — там есть пограничные случаи когда JSON не будет соответствовать стандарту YAML).
Евгений Степанищев (bolknote.ru) 2014
Комментарий для kxepal:
Всегда обход ограничений чего-либо — это костыль, разумеется, как иначе? Но вы так говорите, как будто «джейсон» — формат данный свыше. Вот есть решение, которое малой кровью добавляет комментарии. Осталось его правильно оформить и закинуть на json.org, пусть сделают новый формат JSON 1.1 — тот же JSON, но с комментами. Потому что другие решения явно хуже.
Да и проблем, описанных вами, я не вижу. Очевидно же (или нет?), что формат с комментариями нужен не для обмена (зачем там комментарии?), а я для хранения (конфигов и чего-то близкого к ним), а это значит парсить его будут управляемый нами код. Что я сделал в подобных случаях, я описал — в одном случае расширил JSON обычными JS-комментариями (это удобно, но совершенно несовместимо с текущим форматом), в другом — завёл «мусорные» ключи (ужасно неудобно, но 100% совместимо). Решение с двойными ключами находится посередине — (вероятно) полностью совместимо, но не так удобно, как отдельные комментарии.
Комментарий для Евгения Степанищева:
Очевидно же (или нет?), что формат с комментариями нужен не для обмена (зачем там комментарии?), а я для хранения (конфигов и чего-то близкого к ним), а это значит парсить его будут управляемый нами код.
В таком случае возникает вполне логичный вопрос: «а зачем нам JSON?». Или перефразируя: «а зачем нам втыкать костыли в формат, не предназначенный для конфигов?». Есть много других замечательным форматов для конфигурации как то YAML, INI, TOML. XML в конце концов. Тем более, что парсить его будет управляемый нами код. Понимаю, что адаптировать любимый инструмент под случай, на который он не рассчитывался, всегда интересно, но это редко когда заканчивается чем-то хорошим.
На мой взгляд, конфиги лучше хранить в старом добром ини-файле. Там и секции, и комментарии. Джейон лучше использовать для передачи файлов.
И никто не гарантирует, что в каком-то языке библиотека парсинга будет брать первое поле и пропускать последующие дубли.