JSON (JavaScript Object Notation) и XML (eXtensible Markup Language) — два текстовых формата для хранения и передачи структурированных данных: конфигов, ответов API, выгрузок из учётных систем. Если вы впервые столкнулись с одним из файлов и не знаете, как его вообще открыть, — сначала разберитесь, чем открыть .json-файл, а здесь мы сравним оба формата и поможем выбрать нужный под конкретную задачу.
Коротко: JSON — компактный формат «ключ-значение», удобен для веб-API и мобильных приложений; XML — формат с тегами и атрибутами, поддерживает строгие схемы (XSD) и метаданные, поэтому остаётся стандартом в корпоративных и регулируемых системах. Выбор зависит не от «моды», а от задачи: скорость и простота — JSON, строгая валидация и совместимость с legacy-системами — XML.
Что такое JSON и XML: коротко о форматах
Оба формата кодируют одни и те же данные — объекты, списки, текстовые и числовые значения, — но делают это принципиально по-разному: JSON через пары «ключ-значение», XML через вложенные теги и атрибуты.
Как устроен JSON
JSON — это текстовая запись объектов JavaScript: фигурные скобки {} обозначают объект, квадратные [] — массив, а данные внутри хранятся как пары «ключ: значение». Формат появился как простая альтернатива XML для веба и стал стандартом де-факто для REST API, мобильных приложений и конфигурационных файлов — он нативно парсится в JavaScript и поддерживается практически всеми языками программирования. Официальное описание синтаксиса — на json.org.
Как устроен XML
XML описывает данные через открывающие и закрывающие теги, которые могут содержать атрибуты и вложенный текст: <product id="1">Ноутбук</product>. Такая структура даёт больше возможностей, чем JSON: XML поддерживает атрибуты (метаданные прямо в теге), пространства имён (namespaces) для объединения разных схем в одном документе, смешанный контент (текст вперемешку с тегами) и комментарии. XML старше JSON и укоренён в корпоративных и документных системах — банковских выгрузках, государственных реестрах, офисных форматах. Спецификацию ведёт консорциум W3C — см. w3.org/XML.
Главные структурные различия: ключ-значение против тегов и атрибутов
Если не уверены, какой формат вообще перед вами (расширение могло быть изменено или потеряно), сначала определите формат файла по сигнатуре — это займёт несколько секунд прямо в браузере.
| Критерий | JSON | XML |
|---|---|---|
| Синтаксис | Фигурные/квадратные скобки, пары «ключ: значение» | Открывающие/закрывающие теги с атрибутами |
| Типы данных | Строка, число, булево, null, массив, объект — различает нативно | Всё текст по умолчанию; тип задаётся отдельно через схему |
| Атрибуты / метаданные | Нет отдельного понятия атрибута — только вложенные ключи | Есть: метаданные можно хранить прямо в теге |
| Комментарии | Нет — спецификация не предусматривает | Да — <!-- комментарий --> |
| Пространства имён (namespaces) | Нет | Да — позволяют совмещать разные схемы в одном документе |
| Смешанный контент | Не поддерживает (текст и структура разделены) | Поддерживает (текст и теги внутри одного элемента) |
| Читаемость для человека | Компактнее, легче читать на глаз в небольших файлах | Подробнее за счёт тегов, удобнее для документо-ориентированных данных |
| Размер файла | Обычно компактнее за счёт отсутствия закрывающих тегов | Тяжелее — каждый элемент требует открывающего и закрывающего тега |
| Поддержка в языках программирования | Встроена почти везде, особенно в JS/веб-стеке | Требует парсера (DOM/SAX), но поддержка тоже повсеместная |
| Валидация схемы | JSON Schema — более молодой стандарт | XSD — зрелая, широко принятая схемная валидация |
Один и тот же документ в JSON и XML — наглядный пример
Проще всего увидеть разницу на одинаковых данных, записанных в обоих форматах. Возьмём простую карточку товара:
// JSON
{
"product": {
"id": 101,
"name": "Ноутбук",
"price": 54990,
"inStock": true,
"tags": ["электроника", "компьютеры"]
}
}
<!-- XML -->
<product id="101">
<name>Ноутбук</name>
<price currency="RUB">54990</price>
<inStock>true</inStock>
<tags>
<tag>электроника</tag>
<tag>компьютеры</tag>
</tags>
</product>
Обратите внимание: в XML-варианте атрибут id и currency хранятся прямо в теге — отдельного синтаксиса для «метаданных поля» у JSON нет, пришлось бы заводить дополнительный вложенный ключ. Зато JSON-запись короче и без усилий превращается в объект JavaScript одной функцией.
Когда выбрать JSON?
Нужен обмен данными с REST API, мобильным приложением или веб-фронтендом; важны компактность и скорость; схема данных простая и плоская или с неглубокой вложенностью.
JSON — стандарт де-факто для современных REST API: если вы интегрируетесь с внешним сервисом или пишете собственный backend для сайта или мобильного приложения, формат ответа почти наверняка будет JSON. Он нативно парсится в JavaScript без дополнительных библиотек и занимает меньше места на диске и при передаче по сети, так как в нём нет закрывающих тегов.
Конфигурационные файлы современных инструментов (package.json, tsconfig.json и десятки других) тоже используют JSON — он проще читается человеком в небольших объёмах и не требует специального парсера.
Когда выбрать XML?
Работаете с корпоративной или регулируемой системой (банки, госреестры, 1С); нужна строгая схемная валидация (XSD); документ содержит смешанный контент или метаданные через атрибуты; требуется совместимость с legacy-системами.
XML остаётся стандартом там, где важна строгая проверка структуры данных до их обработки: банковские выгрузки, декларации ФНС, данные ФИАС, обмен между корпоративными системами (SOAP, EDI). Зрелая XSD-валидация позволяет заранее описать, какие элементы обязательны, какой у них тип и порядок — и отклонить документ, не соответствующий контракту, ещё до того, как его начнут обрабатывать.
Пространства имён XML дают возможность комбинировать несколько словарей (схем) в одном документе без конфликта имён тегов — это критично для сложных отраслевых стандартов документооборота. Смешанный контент (текст с разметкой внутри, как в HTML) тоже доступен только в XML — у JSON такого механизма нет.
Производительность и размер файла: что быстрее разбирается
JSON обычно компактнее за счёт отсутствия закрывающих тегов — тот же набор данных в XML занимает заметно больше байт просто из-за синтаксиса. Меньший объём и более простая структура обычно означают, что парсинг JSON быстрее: современные JS-движки разбирают его встроенным методом без дополнительной библиотеки, тогда как XML требует DOM- или SAX-парсера, который строит дерево элементов или обрабатывает документ потоково.
Разница в скорости парсинга заметна на больших объёмах данных или при высокой частоте запросов (тысячи операций в секунду). Для одиночного конфига или небольшого API-ответа выбор формата на производительность приложения практически не влияет — важнее удобство разработки и требования интеграции.
DOM-парсер XML загружает весь документ в память и строит дерево — удобно для произвольного доступа к элементам, но затратно по памяти на больших файлах. SAX-парсер читает документ последовательно и не хранит его целиком в памяти, но писать обработчик сложнее. У JSON такого выбора нет — он либо разбирается целиком, либо потоково через сторонние библиотеки для очень больших файлов.
Валидация данных: JSON Schema и XSD — в чём разница
Валидация — это проверка, что документ соответствует ожидаемой структуре: обязательные поля на месте, типы данных верны, значения в допустимых пределах.
XSD (XML Schema Definition) — зрелый, широко принятый стандарт для описания структуры XML-документов. XSD позволяет задать типы элементов, их порядок, обязательность, ограничения на значения и даже пространства имён. Благодаря давности и распространённости XSD поддерживается практически всеми корпоративными системами и средствами разработки.
JSON Schema решает похожую задачу для JSON, но как стандарт появился позже XSD, поэтому его приняли не так широко и не во всех экосистемах есть одинаково зрелые инструменты валидации. Тем не менее JSON Schema активно используется в описании API (например, в OpenAPI/Swagger) и постепенно становится таким же привычным, как XSD для XML.
При переводе XML в JSON теряются атрибуты и пространства имён, если конвертер не настроен специально их сохранять — атрибут превращается в обычный вложенный ключ, а привязка к namespace попросту исчезает. Проверяйте результат конвертации на регулируемых данных вручную, а не полагайтесь на автоматику вслепую.
Как конвертировать JSON в XML и обратно
Задача конвертации встречается часто: API отдаёт JSON, а принимающая корпоративная система ожидает XML, или наоборот. Разберём три рабочих способа.
Способ 1: онлайн-конвертер
- Откройте сервис конвертации JSON ⇄ XML в браузере.
- Вставьте или загрузите исходный файл.
- Запустите конвертацию и скачайте результат.
- Проверьте вручную, что атрибуты и вложенность перенеслись корректно — автоматика иногда теряет нюансы структуры.
Подходит для разовых задач с небольшими файлами. Не загружайте так конфиденциальные или персональные данные — файл уходит на чужой сервер.
Способ 2: библиотека в коде
Для разработчиков самый надёжный путь — использовать специализированную библиотеку на нужном языке программирования. В Python, например, задачу решают пакеты для работы с деревьями XML в связке с json-модулем из стандартной библиотеки: JSON-объект обходится рекурсивно и на каждом шаге превращается в XML-элемент с сохранением вложенности. Так вы полностью контролируете, как атрибуты и массивы отображаются в XML-тегах.
Способ 3: через Excel / Power Query
Если конечная цель — не сам XML, а анализ данных в таблице, не обязательно хранить промежуточный XML-файл вообще: Excel умеет импортировать и XML, и JSON напрямую. Подробный разбор импорта с решением проблемы кодировки кириллицы — в статье как конвертировать XML в Excel.
FAQ: частые вопросы про JSON и XML
Можно ли конвертировать JSON в XML без потери данных?
В большинстве случаев да, если конвертер настроен правильно: ключи JSON становятся тегами, вложенные объекты — вложенными элементами. Сложность возникает с массивами (нужно решить, как их представить тегами) и с типами данных — XML по умолчанию хранит всё как текст, поэтому информация о том, что значение было числом или булевым, может потеряться без дополнительной схемы.
Что компактнее — JSON или XML?
Как правило, JSON компактнее за счёт отсутствия закрывающих тегов и более лёгкого синтаксиса. На тех же данных XML-документ обычно занимает больше места просто из-за разметки.
Поддерживает ли JSON комментарии, как XML?
Нет. Спецификация JSON не предусматривает комментарии — любой текст в файле должен быть частью данных. XML поддерживает комментарии через синтаксис <!-- комментарий -->.
Какой формат лучше для REST API?
Для большинства современных REST API предпочтительнее JSON — он компактнее, нативно парсится в JavaScript и стал стандартом де-факто для веба и мобильных приложений. XML по-прежнему используется в SOAP-интерфейсах и там, где важна строгая XSD-валидация запросов и ответов.
Чем XML лучше JSON для корпоративных систем?
XML даёт зрелую схемную валидацию (XSD), поддержку пространств имён для объединения разных стандартов в одном документе и возможность хранить метаданные через атрибуты. Это важно в банковских, государственных и документо-ориентированных системах, где контракт данных должен проверяться строго и однозначно.
Можно ли использовать атрибуты в JSON, как в XML?
Отдельного понятия «атрибут» в JSON нет — всё представлено как вложенные пары «ключ: значение». Если нужно сымитировать атрибут, обычно заводят дополнительный ключ (например, "id": 101 рядом с остальными полями объекта), но синтаксически это неотличимо от обычного поля данных.