В чем разница между YAML и JSON? Когда предпочесть одно другому
когда мы должны предпочесть использовать YAML над JSON и наоборот, учитывая следующие вещи?
- производительность (время кодирования / декодирования)
- потребление памяти
- выражение ясности
- доступность библиотеки, простота использования (я предпочитаю C)
Я планировал использовать один из этих двух в нашей встроенной системе для хранения файлов конфигурации.
по теме:
должен ли я использовать YAML или JSON для хранения Данных в Perl?
11 ответов:
технически YAML является надмножеством JSON. Это означает, что, по крайней мере теоретически, синтаксический анализатор YAML может понять JSON, но не обязательно наоборот.
см. официальные спецификации, в разделе под названием "YAML: отношение к JSON".
В общем, есть некоторые вещи, которые мне нравятся в YAML, которые недоступны в JSON.
- как @jdupont указал, YAML визуально легче смотреть. На самом деле Домашняя страница и YAML сам по себе действительный ЯМЛ, но человеку легко читать.
- YAML имеет возможность ссылаться на другие элементы в файле YAML с помощью " якоря."Таким образом, он может обрабатывать реляционную информацию, как можно было бы найти в базе данных MySQL.
- YAML более надежен при внедрении других форматов сериализации, таких как JSON или XML внутри файл YAML.
на практике ни один из этих последних двух пунктов, вероятно, важно то, что вы или Я делаем, но в долгосрочной перспективе, я думаю, что YAML будет более надежным и жизнеспособным форматом сериализации данных.
сейчас AJAX и другие веб-технологии, как правило, используют JSON. YAML в настоящее время используется больше для автономных процессов обработки данных. Например, он включен по умолчанию в пакет компьютерного зрения OpenCV на основе C, а JSON-нет.
вы найдете библиотеки C для JSON и YAML. Библиотеки YAML, как правило, новее, но у меня были никаких проблем с ними в прошлом. См., например,Yaml-cpp.
отличия:
- YAML, в зависимости от того, как вы его используете, может быть более читаемым, чем JSON
- JSON часто быстрее и, вероятно, все еще совместим с большим количеством систем
- можно написать "достаточно хороший" парсер JSON очень быстро
- дубликаты ключей, которые потенциально действительный JSON, are наверняка неверный YAML.
- YAML имеет массу функций, включая комментарии и реляционные якоря. Синтаксис YAML, соответственно, довольно сложен и может быть трудно понять.
- можно написать рекурсивные структуры в yaml:
{a: &b [*b]}, который будет петля бесконечно в некоторых преобразователях. Даже при круговом обнаружении "бомба ямла" все еще возможна (см. xml бомба).- поскольку нет ссылок, невозможно сериализовать сложные структуры со ссылками на объекты в JSON. Поэтому сериализация YAML может быть больше эффективный.
- в некоторых средах кодирования использование YAML может позволить злоумышленнику выполнить произвольный код.
замечания:
- программисты Python, как правило, большие поклонники YAML, из-за использования отступа, а не заключенного в скобки синтаксиса, чтобы указать уровни.
- многие программисты считают прикрепление "смысла" к отступу плохим выбором.
- если формат данных будет оставить среда приложения, проанализированная в пользовательском интерфейсе или отправленная на уровне обмена сообщениями, JSON может быть лучшим выбором.
- YAML может использоваться непосредственно для сложных задач, таких как определение грамматики, и часто является лучшим выбором, чем изобретение нового языка.
в обход эзотерической теории
это отвечает на название, а не на детали, так как большинство просто читает название из результата поиска в google, как я, поэтому я чувствовал, что нужно объяснить С точки зрения веб-разработчика.
- YAML использует отступ пробела, который является знакомой территорией для разработчиков Python.
- JavaScript разработчики любят JSON, потому что это подмножество JavaScript и может быть непосредственно интерпретировано и написано внутри JavaScript, наряду с использованием сокращенного способа объявления JSON, не требует двойных кавычек в ключах при использовании типичных имен переменных без пробелов.
- существует множество парсеров, которые очень хорошо работают на всех языках как для YAML, так и для JSON.
- формат пробелов YAML может быть намного проще смотреть во многих случаях, потому что форматирование требует более удобочитаемого подхода.
- пробелы YAML, будучи более компактными и простыми для просмотра, могут быть обманчиво трудно передать редактирование, если у вас нет видимых пробелов или индикаторов отступов в вашем редакторе.
- JSON намного быстрее сериализуется и десериализуется из-за значительно меньшего количества функций, чем YAML для проверки, что позволяет обрабатывать меньший и более легкий код JSON.
- распространенное заблуждение это то, что YAML требует меньше пунктуации и более компактен, чем JSON, но это совершенно неверно. Пробелы невидимы, поэтому кажется, что есть меньше символов, но если вы посчитаете фактические пробелы, которые необходимы для правильной интерпретации YAML вместе с правильным отступом, вы обнаружите, что YAML на самом деле требует больше символов, чем JSON. JSON не использует пробелы для представления иерархии или группировки и может быть легко сглажен с ненужными пробелами, удаленными для более компактного транспорта.
слон в комнате: сам интернет
JavaScript так ясно доминирует в интернете с огромным отрывом, и разработчики JavaScript предпочитают использовать JSON в качестве формата данных в подавляющем большинстве наряду с популярными веб-API, поэтому становится трудно спорить с использованием YAML над JSON при выполнении веб-программирования в общем смысле, поскольку вы, вероятно, будете превзойдены в командной среде. На самом деле, большинство веб-программистов даже не знают о существовании YAML, не говоря уже о том, чтобы использовать его.
Если вы занимаетесь веб-программированием, JSON-это способ по умолчанию, потому что нет шаг перевода необходим при работе с JavaScript, поэтому в этом случае вы должны придумать лучший аргумент для использования YAML над JSON.
этому вопросу уже 6 лет, но, как ни странно, ни один из ответов на самом деле не касается всех четырех точек (скорость, память, выразительность, переносимость).
скорость
однако, учитывая, что файл YAML может быть немного меньше, чем его аналог JSON (из-за меньшего количества
"и,символы), это возможно что высоко оптимизированный парсер YAML может быть быстрее в исключительных обстоятельствах.
в основном тот же самый аргумент применяется. Трудно понять, почему парсер YAML когда-либо будет более эффективным для памяти, чем парсер JSON, если они представляют та же структура данных.
экспрессивность
Как отмечают другие, программисты Python склонны отдавать предпочтение YAML, программисты JavaScript - JSON. Я сделаю следующие наблюдения:
- легко запомнить весь синтаксис JSON и, следовательно, быть очень уверенным в понимании смысла любого файла JSON. ЯМЛ по-настоящему не понятен ни одному человеку. Количество тонкостей и крайних случаев крайне велико.
- потому что мало парсеров реализуйте всю спецификацию, еще сложнее быть уверенным в значении данного выражения в данном контексте.
- отсутствие комментариев в JSON-это, на практике, настоящая боль.
мобильность
трудно представить себе современный язык без библиотеки JSON. Также трудно представить себе парсер JSON, реализующий что-либо меньшее, чем полная спецификация. YAML имеет широкую поддержку, но менее распространен, чем JSON, и каждый парсер реализует a различные подмножества. Следовательно, файлы YAML менее совместимы, чем вы могли бы подумать.
резюме
JSON является победителем по производительности (если это уместно) и совместимости. YAML лучше подходит для файлов, поддерживаемых человеком. HJSON это достойный компромисс, хотя и с гораздо меньшей переносимостью. JSON5 - это более разумный компромисс, с четко определенными синтаксисом.
Я считаю, что YAML легче на глазах: меньше скобок, "" и т. д. Хотя есть раздражение вкладок в ЯМЛ... но один получает повесить его.
с точки зрения производительности/ресурсов, я бы не ожидал больших различий между ними.
кроме того, мы говорим о файлах конфигурации, и поэтому я бы не ожидал высокой частоты кодирования/декодирования активности, нет?
Если вам не нужны какие-либо функции, которые есть у YAML, а у JSON нет, я бы предпочел JSON, потому что он очень прост и широко поддерживается (имеет много библиотек на многих языках). ЯМЛ является более сложным и имеет меньшую поддержку. Я не думаю, что скорость разбора или использование памяти будет очень сильно отличаться, и, возможно, не большая часть производительности вашей программы.
ГИТ и YAML
другие ответы хороши. Сначала прочтите их. Но я добавлю еще одну причину использовать YAML иногда:git.
все чаще многие программные проекты используют репозитории git для распространения и архивирования. И, хотя история РЕПО git может одинаково хранить файлы JSON и YAML, метод "diff", используемый для отслеживания и отображения изменений в файле, ориентирован на линию. Поскольку YAML вынужден быть линейно-ориентированным, любые небольшие изменения в YAML файл легче увидеть человека.
это правда, конечно, что JSON файлы могут быть "сделаны красиво" путем сортировки строк/ключей и добавления отступа. Но это не по умолчанию, и я ленив.
лично я обычно использую JSON для взаимодействия системы с системой. Я часто использую YAML для конфигурационных файлов, статических файлов и отслеживаемых файлов. (Я также, как правило, избегают добавления в YAML реляционных якоря. Жизнь слишком коротка, чтобы выслеживать петли.)
кроме того, если скорость и пространство действительно беспокойство, я тоже не использую. Вы можете посмотреть на зубров.
технически в YAML предлагает намного больше, чем JSON (YAML v1. 2 является надмножеством JSON):
- комментарии
якоря и наследование-Пример 3 одинаковых элементов:
item1: &anchor_name name: Test title: Test title item2: *anchor_name item3: <<: *anchor_name # You may add extra stuff.- ...
большую часть времени люди не будут использовать эти дополнительные функции, а основное различие заключается в том, что в YAML использует отступы пока JSON использует скобки. Это делает ЯМЛ более лаконичным и читабельный (для опытного глаза).
какой из них выбрать?
- в YAML дополнительные функции и краткое обозначение делает его хорошим выбором для конфигурационные файлы (файлы, предоставленные не пользователем).
- JSON ограниченные возможности, широкая поддержка и более быстрый разбор делают его отличным выбором для взаимодействия и данные, предоставленные пользователем.
поскольку этот вопрос теперь занимает видное место при поиске YAML и JSON, стоит отметить одно редко цитируемое различие между ними: лицензия. JSON претендует на то, чтобы иметь лицензия которого пользователи JSON должны придерживаться (в том числе юридически неоднозначный "должен использоваться для добра, а не зла"). YAML не имеет такой лицензии, и это может быть важным отличием (для вашего адвоката, если не для вас).
иногда вам не нужно решать за одного над другим.
в Go, например, вы можете иметь оба одновременно:
type Person struct { Name string `json:"name" yaml:"name"` Age int `json:"age" yaml:"age"` }
Я считаю, что и YAML, и JSON очень эффективны. Единственные две вещи, которые действительно диктуют, когда один используется над другим для меня, - это то, с чем язык используется наиболее широко. Например, если я использую Java, Javascript, я буду использовать JSON. Для Java я буду использовать свои собственные объекты, которые в значительной степени являются JSON, но не имеют некоторых функций, и конвертировать их в JSON, если мне нужно или сделать это в JSON в первую очередь. Я делаю это, потому что это обычная вещь в Java и упрощает ее для других Java-разработчиков, чтобы изменить свой код. Во-вторых, использую ли я его для запоминания атрибутов программы, или если программа получает инструкции в виде файла конфигурации, в этом случае я буду использовать YAML, потому что он очень легко читается человеком, имеет приятный синтаксис и очень легко модифицируется, даже если вы понятия не имеете, как работает YAML. Затем программа прочитает его и преобразует в JSON или что-то предпочтительное для этого языка.
В конце концов, это честно не вопрос. И JSON, и YAML легко читаются любым опытным программистом.
Comments