Конвертер JSON в XML
Что такое конвертация JSON в XML?
JSON to XML преобразует структурированные JSON-данные в XML-разметку, чтобы передавать информацию между системами с разными форматами обмена. JSON использует объекты, массивы, числа, строки, booleans и null, а XML — элементы, атрибуты, текстовые узлы и пространства имен. Поэтому преобразование не всегда один к одному: имена массивов, отображение атрибутов, пустые значения, специальные символы и порядок нужно представлять осмысленно. Инструмент полезен для SOAP-подобных интеграций, старых корпоративных систем, миграции данных, тестовых payload и документации. В production результат нужно проверять по XSD, API-контракту или формату партнера. Для production-данных или кодовой базы результат все равно нужно проверить parser, тестами или правилами проекта.
Как использовать
Как использовать
- Вставьте или введите JSON-данные в левое поле ввода
- При необходимости измените имя корневого элемента
- Выберите размер отступа (2 пробела, 4 пробела или табуляция)
- Преобразованный XML отображается справа с подсветкой синтаксиса
- Нажмите «Копировать» или «Скачать», чтобы сохранить результат
Проверки при конвертации
- После конвертации проверьте массивы, значения null и поля, похожие на атрибуты — JSON и XML по-разному моделируют данные.
- Выберите стабильное имя корневого элемента, прежде чем вставлять XML в запрос API, конфигурационный файл или тестовый набор.
Применение
Технический принцип
JSON (RFC 8259, на основе литералов объектов JavaScript) и XML (W3C XML 1.0, изначально 1998 года) — оба являются форматами сериализации с древовидной структурой, но их грамматики различаются. JSON содержит объекты (отображения ключ/значение со строковыми ключами), массивы (упорядоченные списки) и шесть скалярных типов (строка, число, логическое значение, null, а также структурные типы). XML содержит элементы (пары начального и конечного тегов, содержащие текст или дочерние элементы), атрибуты (пары имя/значение в начальном теге), текстовые узлы, комментарии, инструкции обработки и секции CDATA. Конвертация представляет собой структурное преобразование без канонического ответа — каждое существующее соглашение (BadgerFish, JSONML, кодирование SOAP/RPC, плоская схема OOXML, формат linkbase XBRL) задаёт свои правила для одних и тех же входных данных. Выбор «атрибут или дочерний элемент» — центральная неоднозначность. Единственные метаданные JSON живут в имени ключа, поэтому объект вроде {"id": "42", "name": "Alice", "admin": true} не указывает, какие ключи являются «метаданными», а какие — «данными». Три распространённых соглашения: (1) конвертер по умолчанию — скаляры становятся текстовым содержимым, а исходный JSON-ключ вложенного объекта атрибутов (определяемого как не-массивный объект, все значения которого — скаляры) становится XML-атрибутом с префиксом @ (соглашение BadgerFish). (2) JSONML — каждый JSON-объект становится элементом, ключ 'tag' задаёт имя элемента, ключ 'attr' — карту атрибутов, а дочерние записи становятся детьми. (3) oData / Atom — JSON-объекты становятся элементами, а массивы вставляются с элементом-обёрткой имени массива. Каждое правило доказуемо корректно для какого-то потребителя и доказуемо ошибочно для другого, поэтому ни один конвертер в XML не получил универсального признания. Массивы — вторая неоднозначность. JSON-массивы — это упорядоченные списки; в XML нет встроенного типа массива. Три стандартных решения: (a) повторение дочерних элементов (по умолчанию, соглашение OOXML/SOAP): [1, 2, 3] → <root><item>1</item><item>2</item><item>3</item></root>. (b) Обёртка в контейнер: <root><items><item>1</item>...</items></root>. (c) Кодирование массива как одной строки с разделителем и документирование разделителя (CSV-in-XML, только если потребитель его парсит). Каждый вариант корректен для определённого потребительского XSD; шаг конвертации должен знать, какой именно выводить. Имена XML-элементов должны быть допустимыми токенами QName (XML 1.0 §2.3 / XML Namespaces 1.0 §3): начинаться с буквы, подчёркивания или двоеточия, затем буквы, цифры, дефисы, подчёркивания, точки или двоеточия. JSON допускает ключи вроде '123' или 'first name', нарушающие это правило — конвертер должен либо переименовать их (слагифицировать в first_name, добавить префикс _), либо отклонить. Строковое содержимое JSON также требует экранирования сущностей в тексте элемента и значениях атрибутов: & → &, < → <, > → > (обязательно в тексте только в старых версиях XML, но всегда безопасно), " → " и ' → ' в атрибутах, а любой символ за пределами диапазона кодировки — как &#xHHHH;. Пять встроенных сущностей плюс числовые ссылки на символы обязательны в XML; дополнительные именованные сущности HTML ( , ©) не определены в обычном XML и требуют явного DOCTYPE. Выходной документ также нуждается в прологе и объявлениях пространств имён: <?xml version="1.0" encoding="UTF-8"?> в начале, затем объявления xmlns. Если целевая система использует пространства имён (SOAP использует http://www.w3.org/2003/05/soap-envelope, XSLT использует http://www.w3.org/1999/XSL/Transform), сопоставления префиксов добавляются как атрибуты xmlns:prefix="uri" на корневом элементе. В JSON нет концепции пространств имён, поэтому выбор URI зависит от проекта. Для пустых значений JSON null обычно выражается как <key xsi:nil="true"/> (соглашение XML Schema) или <key></key> (соглашение пустого элемента). Конвертер выбирает одно; правильный ответ зависит от XSD-валидации потребителя. Для обратного направления (XML → JSON) те же неоднозначности в обратную сторону: атрибуты отображаются в ключ @attributes в BadgerFish, CDATA отображается в ключ $ или #text, элементы со смешанным содержимым (текст + дочерние элементы чередуются) не имеют чистого представления в JSON и обычно выводятся как конкатенация строк. Реальные конвертеры всегда предоставляют параметры «ключ атрибута», «ключ текста», «обёртка массива» — обойтись без этого невозможно.
- JSON (RFC 8259) и XML (W3C XML 1.0, 1998) — оба формата с древовидной структурой сериализации; конвертация — это структурное преобразование без канонического ответа, поэтому для одних и тех же входных данных сосуществуют несколько соглашений (BadgerFish, JSONML, SOAP, OOXML).
- Атрибут или дочерний элемент: скаляры по умолчанию становятся текстовым содержимым; вложенные объекты «мешок атрибутов» (только скалярные значения) становятся атрибутами с префиксом @ (BadgerFish). JSONML использует ключи 'tag' / 'attr'. oData / Atom использует элементы-обёртки.
- Массивы: по умолчанию повторяются дочерние элементы (соглашение OOXML/SOAP). Альтернативы: обёртка в элемент-контейнер или кодирование как строки с разделителем. Порядок массива JSON сохраняется в XML-выводе.
- Правила имён XML-элементов: должны начинаться с буквы, подчёркивания или двоеточия, затем буквы/цифры/дефисы/подчёркивания/точки/двоеточия (XML 1.0 §2.3). JSON-ключи вроде '123' или 'first name' недопустимы как XML-имена и должны быть слагифицированы или отклонены.
- Экранирование сущностей: & → &, < → <, > → >, " → ", ' → ', любой другой символ кодировки как &#xHHHH;. 5 встроенных сущностей обязательны; HTML-дополнения вроде требуют явного DOCTYPE.
- Пролог документа: <?xml version="1.0" encoding="UTF-8"?> — стандартная первая строка. Объявления xmlns на корневом элементе определяют префиксы пространств имён; в JSON нет концепции пространств имён, поэтому конвертер выбирает под проект.
- JSON null → XML: либо <key xsi:nil="true"/> (соглашение XML Schema), либо <key></key> (пустой элемент). Выбор должен соответствовать XSD потребителя, иначе валидация не пройдёт.
- Обратное направление XML → JSON имеет те же неоднозначности: секции CDATA становятся ключами $ или #text (BadgerFish), элементы со смешанным содержимым (текст + дочерние элементы чередуются) не имеют чистой формы JSON и обычно конкатенируются в строку.
Примеры
Объект -> элемент
{"name": "Alice"}
->
<root>
<name>Alice</name>
</root>Массив -> элементы
[1, 2, 3]
->
<root>
<item>1</item>
<item>2</item>
<item>3</item>
</root>Вложенная структура
{"user": {"name": "Alice", "age": 25}}
->
<root>
<user>
<name>Alice</name>
<age>25</age>
</user>
</root>Часто задаваемые вопросы
Как конвертер сопоставляет JSON и XML?
Каждый JSON-объект становится XML-элементом. Ключи объекта становятся именами дочерних элементов; примитивные значения — текстом элемента. Массивы повторяют родительский элемент несколько раз. Специальные символы в тексте экранируются (& → &, < → <).
Почему преобразование JSON в XML не всегда обратимо без потерь?
В JSON есть явные типы number/boolean/null; в XML — только текст. JSON допускает ключи с пробелами или специальными символами; имена XML-элементов — нет. Массивы на верхнем уровне не имеют очевидного XML-эквивалента. Страница использует эвристики (элемент-обёртка root, санитизация недопустимых ключей), чтобы заполнить эти пробелы.
Как значения массивов представляются в XML?
Каждый элемент массива становится сестринским элементом с тем же именем. [{a:1},{a:2}] → <items><item><a>1</a></item><item><a>2</a></item></items>. Обёртка настраивается; некоторые страницы позволяют явно выбрать имя единственного элемента.
Что делать с JSON-ключами, которые недопустимы как XML-имена?
Имена XML-элементов не могут начинаться с цифры, содержать пробелы или включать определённые символы. Страница санитизирует, заменяя недопустимые символы подчёркиваниями или оборачивая в CDATA. Результат — валидный XML, но обход туда-обратно не точен.
Сохраняются ли null и булевы значения JSON?
null становится пустым элементом или элемент опускается — в зависимости от настроек. true/false становятся буквальным текстом true или false. Стандарта XML для этих типов нет — нижестоящие парсеры должны применять собственную интерпретацию типов.
Можно ли добавлять XML-атрибуты?
В JSON нет понятия атрибутов, поэтому генератор по умолчанию выводит всё как элементы. Некоторые конвертеры используют специальный префикс ключа (например, @id) для обозначения атрибутов — проверьте параметры страницы, если вывод атрибутов важен для вашей XML-схемы.
Преобразование выполняется локально?
Да. Разбор JSON и генерация XML происходят в вашем браузере. Входные данные никуда не загружаются.