JSON, YAML и XML: когда какой формат

JSON, YAML и XML решают одну задачу: описать структуру данных текстом. Выбор зависит от того, кто читает файл. Для ответа API и обмена между программами берут JSON: объекты, массивы, числа, строки, булевы значения, вложенность без лишней разметки. Для конфигов, которые правят руками, чаще берут YAML: отступы вместо скобок, комментарии, якоря. Для документов с атрибутами, схемами и старыми интеграциями остаётся XML. На Тулси есть инструмент только для JSON: JSON formatter разворачивает «кашу» в одну строку и показывает синтаксическую ошибку. YAML и XML вы правите в редакторе или в своей системе. Ниже: чем форматы отличаются на практике, как выбрать за минуту и куда увести таблицу через CSV в JSON. Частые вопросы собраны в конце.

Зачем рядом живут три формата

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

JSON пришёл из JavaScript и стал общим языком HTTP API. Браузер, мобильное приложение и бэкенд на любом языке разбирают его одной библиотекой. YAML вырос как «человеческий» слой поверх тех же структур: тот же объект, но с отступами и комментариями. XML старше обоих: теги, атрибуты, пространства имён, схемы. Его держат банки, госсервисы, RSS и SOAP-обёртки.

Путаница начинается, когда один файл пытаются читать сразу тремя правилами. Коллега прислал «настройки» с расширением .yml, а вы вставляете их в парсер JSON. Или ответ API кладут в Excel как текст XML. Формат выбирают под канал: API, конфиг репозитория, документ с подписью схемы.

Люди ищут «json yaml xml» и «json vs yaml», когда нужно назвать формат в тикете, а не выучить три спецификации. Достаточно знать, кто потребитель: программа без человека, человек в редакторе, или система, которая уже ждёт XML.

Ошибка выбора стоит времени на конвертацию. JSON из YAML руками набить можно, но якоря и многострочные блоки YAML в JSON не переезжают один в один. XML с атрибутами в JSON тоже не копируется «как есть»: атрибут становится полем, а текст внутри тега отдельным ключом.

JSON: обмен данными и API

JSON это объекты в фигурных скобках, массивы в квадратных, ключи в двойных кавычках. Числа без кавычек, true / false / null как литералы. Комментариев в стандарте нет: парсер споткнётся на // и на висячей запятой после последнего поля.

Для HTTP это удобно. Тело запроса и ответа умещается в одну строку или в развёрнутый вид с отступами. Фронтенд читает response.json(), бэкенд отдаёт тот же объект. Логи, вебхуки, фикстуры тестов почти всегда JSON.

На Тулси проверка синтаксиса закрывает JSON formatter. Если строка битая, сначала чините скобки и запятые, иначе любой конвертер дальше откажется работать. Разбор типичных сбоев: JSON formatter: как найти ошибку.

JSON не любит лишней семантики. Нет атрибутов у поля, нет схемы внутри самого файла. Типы и обязательность полей живут снаружи: в OpenAPI, в коде, в договорённости команды. Для публичного API этого хватает. Для документа с печатью и жёсткой XSD-схемой JSON слабее XML.

Когда JSON подходит

Ответ REST или GraphQL, webhook, конфиг, который читает только программа, обмен с фронтендом. Массив объектов из таблицы: путь через CSV в JSON и статья CSV в JSON для API.

Короткий тест в Postman: вставили JSON, отправили. Коллега без редактора YAML поймёт объект с двумя полями быстрее, чем отступы на четыре пробела.

Где JSON ломается

Одна строка на тысячу символов: глаз не видит пропущенную запятую. Trailing comma из JavaScript в JSON нельзя. Ключ без кавычек тоже нельзя. Одинарные кавычки вокруг строк парсер не примет.

Кириллица в UTF-8 нормальна. Проблемы начинаются, когда файл сохранили в Windows-1251 и отдали как JSON. Тогда «ломается» не формат, а кодировка. Сначала откройте файл в редакторе и проверьте, читаются ли буквы.

YAML: конфиги и читаемый текст

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

Его берут в Docker Compose, Kubernetes, CI, Ansible, в шапке Markdown (front matter). Человек правит файл в репозитории. Программа потом читает YAML библиотекой. JSON туда тоже кладут, но дифф в git по отступам YAML читается спокойнее, чем по скобкам в одну строку.

На Тулси отдельного инструмента для YAML нет. Файл конфига вы открываете в редакторе кода. Если из YAML нужно получить JSON для API, конвертируйте у себя в проекте или в редакторе с плагином. Не вставляйте YAML в JSON formatter: парсер JSON его не примет.

Ловушка YAML: отступ. Один пробел лишний, и ключ уехал в другой уровень. Табы и пробелы в одном файле ломают разбор. Значения вроде no, on, off старые парсеры могли прочитать как булевы; в новых версиях YAML это уже строже, но привычка брать кавычки вокруг коротких слов остаётся полезной.

Отступы, якоря и слияния

Якоря (&) и ссылки (*) позволяют не копировать один и тот же блок дважды. Для человека это экономия. Для новичка это сюрприз: «откуда взялось это поле». В ревью лучше не злоупотреблять, если файл читает вся команда.

Многодокументный YAML (несколько --- в одном файле) встречается в Kubernetes. Это уже не один объект JSON. Конвертация «весь файл в один JSON» без договорённости даст либо массив документов, либо ошибку.

Где YAML лучше JSON для человека

Список сервисов с портами, переменными и томами. Политика CI на два экрана с комментариями «зачем этот job». Шаблон с длинным текстом письма. JSON это тоже опишет, но править руками больнее: кавычки, запятые, отсутствие комментариев.

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

XML: документы, схемы, старые интеграции

XML это дерево тегов. У элемента есть имя, атрибуты и дочерние узлы. Текст может жить внутри тега, а свойства в атрибутах. Пространства имён разделяют словари, когда в одном документе смешаны разные схемы.

Формат держат там, где уже есть контракт: СМЭВ, банки, 1С-обмен, SOAP, RSS, SVG как частный случай, Office Open XML внутри .docx. Менять канал на JSON без согласования со второй стороной нельзя: их парсер ждёт теги.

Схема (XSD) описывает, какие элементы обязательны и какие типы у значений. Это сильнее «договорённости в чате», чем у типичного JSON API. Цена: файл длиннее, ручное редактирование тяжелее, ошибка в закрывающем теге ломает весь документ.

На Тулси XML не разбираем. Если вам прислали XML, откройте его в редакторе или в той системе, которая его ждёт. Для таблицы из ответа API, который уже JSON, берите JSON в CSV и статью JSON в CSV для Excel.

Теги и атрибуты на пальцах

Элемент <city id="16">Казань</city> несёт и атрибут, и текст. В JSON это обычно {"id": 16, "name": "Казань"} или {"id": 16, "city": "Казань"}. Правила маппинга нужно зафиксировать, иначе два человека получат два разных JSON из одного XML.

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

SOAP и RSS без учебника

SOAP оборачивает вызов метода в конверт XML. Если интеграция уже SOAP, вы живёте в XML, даже если внутри конверта сидят «почти те же» поля, что в JSON. Переписывать канал «потому что JSON моднее» без замены второй стороны бессмысленно.

RSS и Atom отдают ленты новостей XML. Читалка и подкаст-каталог ждут этот синтаксис. JSON Feed существует, но его меньше в дикой природе. Для своей ленты смотрите, что принимает потребитель.

Как выбрать формат за минуту

Спросите, кто главный читатель. Программа по HTTP: JSON. Человек в git и CI: YAML. Чужой контракт со схемой и тегами: XML. Таблица в Excel: сначала CSV, потом при необходимости JSON.

Второй вопрос: файл генерируют или правят руками. Генерация любит JSON. Руки любят YAML с комментариями. XML для ручной правки берут только если иначе нельзя.

Третий вопрос: вложенность и атрибуты. Плоский список объектов: JSON или CSV. Конфиг с повторяющимися блоками: YAML с якорями, если команда их понимает. Документ с атрибутами и смешанным текстом: XML.

Не смешивайте синтаксис в одном файле. Расширение .json с YAML-отступами внутри сломает пайплайн. .xml с JSON-объектом внутри как текст возможен, но это уже поле-строка, не «два формата сразу».

Если сомневаетесь между JSON и YAML для внутреннего API, берите JSON. Меньше сюрпризов с типами и с парсерами. YAML оставьте конфигам репозитория.

Как проверить JSON на Тулси

Откройте JSON formatter. Вставьте текст из буфера или загрузите файл. Режим «Красиво» расставит отступы по уровням. Режим «Сжать» уберёт пробелы для тела запроса. Если синтаксис неверный, вы увидите сообщение об ошибке, а не «почти правильный» объект.

Обработка идёт в браузере на вашем устройстве. Текст не уезжает на сервер Тулси. Это удобно для куска из DevTools или для фикстуры с тестовыми, но чувствительными полями.

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

YAML и XML в это поле не кладите. Сначала приведите данные к JSON в своём редакторе, если цель именно проверить объект API. Конфиг Compose и документ SOAP инструментом JSON не «починить».

Соседние задачи: таблица и ответ API

Таблица в файле или в Excel это не JSON. Чтобы получить массив объектов для скрипта, откройте CSV в JSON. Первая строка станет ключами. Разбор граблей с разделителем и кодировкой: CSV в JSON для API.

Обратный путь: массив объектов уже есть, а смотреть удобнее в Excel. Тогда JSON в CSV и JSON в CSV для Excel. Вложенные объекты сами в колонки не развернутся: для плоской таблицы готовьте плоский JSON.

Три формата из заголовка здесь ни при чём, если исходник сетка. CSV не заменяет YAML-конфиг и не заменяет XML-схему. Он закрывает табличный канал, который потом стыкуют с JSON API.

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

Частые вопросы

JSON YAML XML: в чём разница для практики?

JSON это скобки и кавычки, YAML это отступы и комментарии, XML это теги и атрибуты. Для API берут JSON, для конфигов в репозитории YAML, для старых интеграций и документов со схемой XML. На Тулси проверить синтаксис можно только у JSON, через JSON formatter. YAML и XML остаются текстом в вашем редакторе.

JSON vs YAML: что выбрать для API?

Для тела HTTP берите JSON. Его ждут клиенты, шлюзы и логи. YAML для API имеет смысл, только если контракт уже такой (редко). Конфиг деплоя рядом с тем же сервисом спокойно живёт в YAML, а запросы к сервису остаются JSON. Смешивать синтаксис в одном файле не стоит.

Чем JSON отличается от XML в ответе сервиса?

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

YAML что это в Docker и Kubernetes?

Это текстовый конфиг со списками сервисов, портов, томов и манифестов. Файл читает оркестратор, человек правит его в git. Отступы задают вложенность. На Тулси YAML не разбирается: правьте файл в редакторе кода. JSON из такого манифеста получают отдельной конвертацией в проекте, не вставкой в форматтер JSON.

Нужен ли XML для нового REST API?

Для нового публичного REST обычно хватает JSON. XML оставляют, если потребитель уже SOAP, СМЭВ или внутренний обмен 1С. Схема и теги тогда часть контракта, а не вкус команды. Переход на JSON требует согласия второй стороны и нового разбора на их стороне.

Какой формат брать для конфига репозитория?

Если файл правят люди и нужны комментарии, берите YAML. Если файл пишет скрипт и читает программа, JSON проще и строже. XML для конфига приложения берут, когда так заведено во фреймворке (старые Java-стеки, некоторые CMS). Смотрите, что уже открывает ваш инструмент сборки.

Можно ли превратить YAML в JSON один в один?

Структуру словаря и списка перенести можно. Комментарии YAML в JSON пропадут: в стандарте JSON их нет. Якоря развернутся в повторяющиеся объекты. Несколько документов YAML станут массивом или несколькими файлами. После конвертации проверьте результат в JSON formatter, если дальше объект уходит в API.

YAML front matter в Markdown это отдельный формат?

Это блок YAML в начале .md между ---. Его читает генератор сайта или CMS, чтобы взять title, date, теги. Для статьи блога это метаданные, не тело API. На Тулси front matter не разбираем. Если из шапки нужно получить JSON, скопируйте блок в конвертер YAML у себя, не в форматтер JSON вместе с текстом статьи.

Почему парсер JSON ругается на файл из конфига?

Частая причина: в буфер попал YAML или XML. Отступы без скобок, ключи без кавычек, теги в угловых скобках. Вторая причина: висячая запятая или комментарий //. Вставьте кусок в JSON formatter и посмотрите сообщение. Если исходник не JSON, сначала смените формат, а не «подкручивайте» кавычки вслепую.

JSON или CSV, если данные уже таблица?

Таблица это CSV (или Excel). JSON нужен, когда потребитель API или скрипт. Конвертация: CSV в JSON, подробности в CSV в JSON для API. YAML и XML здесь ни при чём, пока вы не отдаёте ту же сетку в чужой XML-обмен. Для выгрузки ответа API обратно в таблицу берите JSON в CSV.

Если правите JSON из DevTools, откройте JSON formatter. Если исходник таблица, путь через CSV в JSON. Соседние разборы: как найти ошибку в JSON, CSV в JSON для API, JSON в CSV для Excel.