Конвертер JSON XML

JSON и XML как взаимозаменяемые деревья

JSON и XML оба представляют иерархические данные, но выросли из разных традиций. JSON — лёгкая модель объектов/массивов, которую используют большинство веб-API. XML — модель размеченного документа с элементами, атрибутами, пространствами имён и смешанным содержимым; она по-прежнему центральна для корпоративного обмена сообщениями, издательских процессов и многих форматов конфигурации.

Преобразование между ними — это структурное отображение, а не простая смена синтаксиса. Имена, вложенность и подсказки о типах нужно выбирать осознанно: две модели не изоморфны. Этот хаб объясняет семейство такого отображения. Для прямого пути конвертации откройте Из JSON в XML.

Подинструменты этого семейства

• Из JSON в XML — принимает значение JSON и формирует XML-документ, где объекты становятся элементами, а массивы — повторяющимися дочерними узлами (по правилам конвертера).
• Из XML в JSON — разбирает XML и строит JSON-представление элементов, текста и атрибутов.
• Форматировать JSON — pretty-print или минификация JSON, когда нужен контроль раскладки в том же рабочем процессе, что и конвертация.

Используйте конвертеры, когда системы по разные стороны интеграции расходятся в кодировании. Используйте format-json, когда полезная нагрузка уже JSON и нужна только читаемая или компактная форма до или после преобразования.

Где модели расходятся

Объекты vs элементы. Объекты JSON — неупорядоченные отображения строковых ключей в значения. Элементы XML упорядочены в порядке документа и могут повторяться с тем же именем. Массив объектов JSON часто становится повторяющимися соседними элементами; объект JSON — набором дочерних элементов с уникальными именами, пока ключ не окажется недопустимым как имя XML.

Атрибуты vs свойства. Атрибуты XML — только строки, неупорядочены на элементе и не могут вкладываться. У JSON нет отдельного канала атрибутов; конвертеры обычно отображают атрибуты в ключи с условным префиксом (например @id) или вкладывают их под зарезервированный объект. Round-trip должны согласовать эту конвенцию, иначе атрибуты и дочерние элементы поменяют смысл.

Типы. JSON различает числа, булевы значения, null, строки, массивы и объекты. Текст XML остаётся текстом, пока схема (XSD) или конвенция его не переинтерпретируют. Без метаданных типа true, 1 и "true" могут пережить round-trip как строки — либо конвертер применит эвристики, которые вас удивят.

Пространства имён. Пространства имён XML (xmlns) различают словари. У JSON нет нативного узла пространства имён; префиксы могут сплющиваться в строки ключей или отбрасываться. Потеря информации о пространствах имён — частый тихий сбой, когда XML→JSON→XML используют как конвейер «очистки».

Смешанное содержимое. XML допускает чередование текста и элементов (<p>Привет <em>мир</em></p>). Деревья JSON обычно хранят либо строку, либо детей, но не оба варианта, если конвертер не использует явный массив содержимого. Документо-ориентированный XML часто требует более богатого отображения, чем дата-ориентированный.

JSON → XML (концептуальный конвейер)

1. Разобрать JSON; отклонить неверный синтаксис до построения любого XML.
2. Выбрать имя корневого элемента (у JSON нет требования единственного корня для массива верхнего уровня; конвертеры придумывают обёртку).
3. Отобразить каждый ключ объекта в дочерний элемент или атрибут по правилам именования.
4. Отобразить массивы в повторяющиеся элементы с одним и тем же тегом.
5. Экранировать спецсимволы (&, <, >, кавычки) в тексте и атрибутах.
6. Сериализовать с XML-объявлением и отступами или без них.

Недопустимые имена XML (ключи, начинающиеся с цифр, содержащие пробелы или конфликтующие с зарезервированными префиксами xml) нужно санитизировать или отклонять. В конвейерах данных лучше громко падать, чем выдавать некорректно сформированную разметку.

XML → JSON (концептуальный конвейер)

1. Разобрать как корректно сформированный XML (и при необходимости валидировать по схеме отдельно).
2. Представить каждый элемент как объект JSON или как значение, если у него только текст.
3. Решить, как кодировать атрибуты, повторяющихся детей и пустые элементы ("" vs null vs {}).
4. Схлопывать или сохранять текстовые узлы согласно политике смешанного содержимого.
5. Выдать текст JSON; при желании pretty-print для проверки через Форматировать JSON.

Соседние элементы с одним именем обычно становятся массивом JSON. Единственный ребёнок с таким именем может стать «голым» объектом — ещё один риск round-trip, если код всегда ожидает массивы.

Форматирование JSON в конвейере конвертации

Ошибки конвертации легче диагностировать на JSON с отступами. Минифицированный JSON лучше подходит для встраивания в логи или транспорт после правок. Format-json в этом семействе — сосед по раскладке: он не переносит данные в XML, а готовит JSON для человека или машины вокруг конвертеров.

Без потерь и когда прекращать round-trip

Round-trip по умолчанию с потерями, если оба направления не разделяют документированный набор конвенций (префиксы атрибутов, обёртка массивов, приведение типов, обработка пространств имён). Безопасные шаблоны:

• Конвертировать один раз на границе систем и держать единый system of record.
• Хранить исходный XML, когда важна юридическая/архивная верность; считать JSON рабочей проекцией.
• Для корпоративных сообщений предпочитать schema-aware инструменты (XSD + data binding) произвольным обходам дерева.

Небезопасные шаблоны: использовать JSON как редактор XML (XML→JSON, ручная правка, JSON→XML) для подписанных документов, пространств имён или смешанного содержимого без golden-тестов.

Символы, кодировка и размер

XML-документы часто объявляют кодировку в прологе; текст JSON в API почти всегда UTF-8. При конвертации убедитесь, что Unicode-строка в памяти корректна до сериализации. Управляющие символы, недопустимые в XML 1.0, нужно удалять или экранировать по политике — они могут встречаться в строках JSON и ломать наивные XML-писатели.

Очень большие документы нагружают память браузера. Для многомегабайтных экспортов предпочитайте потоковые конвертеры в стандартной экосистеме вашего языка; браузерные инструменты идеальны для образцов, фикстур и отладочных срезов.

Практические примеры интеграции

• Устаревший SOAP/XML-сервис, современный JSON-клиент: отобразить XML ответа в JSON для UI; оставлять шаблоны запросов в XML, если удалённый контракт этого требует.
• Мост конфигурации: вести внутреннюю конфигурацию как JSON; выдавать XML для инструментов, которые читают только XML.
• Сборка фикстур: писать данные как JSON, конвертировать в XML для harness парсера — хранить golden-пары вход/выход под теми же правилами отображения, что и в production.

Ограничения

Эти инструменты не валидируют по XSD или JSON Schema, не запускают XSLT и не реализуют XML Canonicalization (C14N) для подписей. Они сосредоточены на практической проекции деревьев. Для цифрово подписанного XML используйте специализированные библиотеки подписи.

Связанные инструменты

Проверки синтаксиса: Valida JSON, Valida XML. Чистая раскладка JSON: Pretty-print JSON. Конвертируйте, когда должен меняться модель; форматируйте или валидируйте, когда она остаётся прежней.