Две модели не совпадают: RFC 8259 определяет шесть типов JSON без атрибутов, при этом XML 1.0 имеет атрибуты, пространства имен и упорядоченное смешанное содержимое. идти в этом направлении означает выбрать, что делать с разницей.
В первый раз, когда мне пришлось отправить данные JSON в систему, которая говорила только на XML, я сделал наивную вещь: я вручную написал угловые скобки в текстовом редакторе Это был канал поставщика, который ожидал конверт в стиле SOAP, и моим источником был аккуратный массив JSON, выходящий из API Laravel. Через двадцать минут я неправильно сопоставил закрывающий тег где-то около сороковой записи, и получающий парсер бросил "junk после элемента документа & quot; ошибка, которая ничего не говорила мне о где. В тот вечер я преподал мне урок, который я применил по каждой интеграции, поскольку: преобразование между JSON и XML - это не творческий акт. Это проблема сопоставления с небольшим количеством правил, и в тот момент, когда вы записываете эти правила, все это становится механическим.
Это руководство является версией того сопоставления, которое я хотел бы I'd имел. Я создаю [Toolz.dev](/, и один из инструментов там основан на браузере Конвертер JSON в XML это в точности применимо к соглашениям ниже. Но суть этой статьи не в кнопке - it's понимание почему ключ становится элементом, почему @-префиксный ключ становится атрибутом, и почему массив превращается в повторяющиеся теги, а не в пронумерованный список. Как только эти три идеи щелкнут, вы можете преобразовать любой JSON в XML вручную, если это необходимо, и вы можете отладить выходные данные, когда нижестоящая система отклонит его.
TL;DR: Чтобы преобразовать JSON в XML, сопоставьте каждый ключ объекта с элементом, каждый
@-предварительно исправленный ключ к атрибуту на его родительском элементе и#textключ к элементу's текстового содержимого.Expand каждый массив в повторяющиеся элементы sibling, которые разделяют ключ's имени.Escape&,<, и>в тексте (плюс"в значениях атрибутов), и очистить любой ключ, который является 't законное XML имя.Сделайте это в браузере, чтобы полезные нагрузки с токенами или данными клиента никогда не покидали вашу машину.
Зачем вам вообще конвертировать JSON в XML?
JSON выиграл войну веб-API много лет назад, и если вы проведете дни в React, Laravel или Node, вы можете разумно спросить, когда вам ' когда-либо вообще понадобится XML. Ответ таков: постоянно, только не в тех местах, куда вы смотрите. XML - это лингва-франка огромной установленной базы систем, которые появились еще до эпохи JSON и никуда не денутся. Веб-сервисы SOAP - по-прежнему основа банковского дела, страхования, логистики и государственной интеграции - несут свою полезную нагрузку в XML. Ленты RSS и Atom - это XML. Карты сайтов - это XML. Макеты Android, .docx а .xlsx внутренние каналы (Office Open XML), SVG, RSS подкасты, и бесчисленные B2B EDI-стиль обмена все XML.
Таким образом, реальный сценарий почти всегда имеет одну и ту же форму: у вас есть данные на JSON, потому что это 's то, что производит ваш стек, и вам это нужно на XML, потому что это 's то, что требует другая сторона. Может быть, вы и #39;переносите данные о продукте на торговую площадку, которая принимает только XML-канал. Может быть, вы и #39;переворачиваете ответ API в тело SOAP. Может быть, вы и #39; создаете RSS-канал из экспорта контента JSON. В каждом случае вы не хотите & #39; не хотите каждый раз изобретать сериализацию заново - вам нужно предсказуемое правило, которое превращает любую структуру JSON в действительный XML, чтобы вы могли автоматизировать ее и перестать об этом думать.
Там 's также более тихая причина: читаемость во время отладки. Когда вы ' смотрите на глубоко вложенный блок JSON, пытаясь понять иерархию, преобразование его в XML с отступом иногда приводит к выскочке древовидной структуры, потому что теги XML's открытия/закрытия делают вложение явным таким образом, что JSON's подтяжки don't. Я сохраняю Конвертер JSON в XML а наоборот XML в JSON конвертер открывайте на соседних вкладках чаще, чем предполагал I'd.
Как именно JSON сопоставляется с XML?
Вот суть его Есть только четыре правила, а все остальное - деталь.
Правило 1: Объектные ключи становятся элементами. Объект JSON { "book": { "title": "..." } } становиться <book><title>...</title></book>. Ключ - это имя тега; значение - это то, что входит внутрь.
Правило 2: @-префиксные ключи становятся атрибутами. Элементы XML могут нести атрибуты, и JSON не имеет собственного понятия о них, поэтому нам нужно соглашение. широко используемый - и тот, который использует мой инструмент - является префиксным символом, @ по умолчанию. так { "book": { "@id": "bk101", "title": "..." } } становиться <book id="bk101"><title>...</title></book>. Атрибуты могут содержать только примитивные значения (строки, числа, логические значения), никогда не вложенные структуры, что соответствует тому, как на самом деле работают атрибуты XML.
Правило 3: The #text ключ становится текстовым контентом. Когда элемент нуждается оба атрибуты и текст - думать <title lang="en">Hello</title> - вы можете 't выразить это простым строковым значением, потому что строка не оставляет места для атрибута. Соглашение - это зарезервированный ключ, #text, { "title": { "@lang": "en", "#text": "Hello" } }. Если элемент имеет только текст и не имеет атрибутов, вы можете пропустить #text и просто используйте простое строковое значение.
Правило 4: Массивы становятся повторяющимися элементами. Это тот, кто ошибается чаще всего. XML не имеет типа массива. список вещей выражается как повторяющиеся элементы-братья с одним и тем же именем тега. так { "tags": { "tag": ["computer", "web"] } } становиться <tags><tag>computer</tag><tag>web</tag></tags> - нет <tag>0</tag> или любая ерунда на основе индексов.The array's ключ поставляет повторяющееся имя тега.
Соберите их вместе на реалистичный объект, и результат будет именно таким, как ожидает нижестоящий анализатор XML:
{
"catalog": {
"book": [
{ "@id": "bk101", "author": "Gambardella, Matthew", "price": 44.95 },
{ "@id": "bk102", "author": "Ralls, Kim", "price": 5.95 }
]
}
}
становиться
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<book id="bk101">
<author>Gambardella, Matthew</author>
<price>44.95</price>
</book>
<book id="bk102">
<author>Ralls, Kim</author>
<price>5.95</price>
</book>
</catalog>
Обратите внимание, что единственная клавиша верхнего уровня, catalog, стал корневым элементом document's. That's преднамеренно: хорошо сформированный XML-документ должен иметь ровно один корень. когда ваш JSON уже имеет один ключ упаковки, этот ключ есть корень. Когда это не так 't - когда вы передаете конвертеру объект с несколькими ключами или голый массив - инструмент оборачивает все под настраиваемый корневой элемент (root по умолчанию), поэтому выходные данные остаются хорошо сформированными.
А как насчет побега и недействительных имен?
Две вещи незаметно нарушают больше конверсий, чем любая ошибка вложения: неэкранированные специальные символы и имена незаконных элементов.
Побег. XML оставляет несколько символов. Текст внутреннего элемента, &, <, и > должно быть написано как &, <, и >. Внутри значения атрибута с двойными кавычками вам дополнительно необходимо избежать двойной кавычки как ". Если ваша строка JSON содержит Tom & Jerry и вы опускаете его в XML необработанный, голый амперсанд делает документ искаженным, и синтаксический анализатор умирает. Правильный преобразователь выходит автоматически, так что "a < b & c" становиться a < b & c в выводе и туда и обратно к исходному тексту при анализе Это не необязательная полировка - it's разница между действительным и недействительным XML.
Имена элементов. В XML действуют строгие правила относительно того, что может содержать имя тега.Names can't включают пробелы, can't начинаются с цифры, дефиса или точки, и исключают большинство пунктуаций.JSON-ключи не имеют таких ограничений - "first name", "123", и "total($)" все являются совершенно законными ключами JSON и всеми незаконными именами XML. конвертер, который игнорирует это, производит документы, которые ни один синтаксический анализатор не примет. прагматическое исправление, и то, что делает мой инструмент, - это очистить: заменить незаконные символы подчеркиваниями и подготовить подчеркивание, когда имя начинается с цифры. Итак "123 bad" становиться <_123_bad>. It's не гламурный, но гарантирует анализ вывода, который представляет собой всю суть.
Как использовать браузерный конвертер?
Рабочий процесс включен Toolz.dev/tools/json-to-xml отражает приведенные выше правила, предлагая несколько вариантов практических крайних случаев.
Вставьте свой JSON во вход и нажмите Convert. если ваш JSON неверен, вы получаете явную ошибку анализа, а не бесшумный мусор - я опираюсь на браузер и #39;s собственный JSON.parseтаким образом, сообщения об ошибках соответствуют тому, что вы 'd видите в своей консоли. Выберите 2 или 4 пробела отступов, когда вам нужен удобочитаемый документ для просмотра, или выберите Minify, чтобы свернуть все это в одну строку, когда вы ' повторно отправляете его по проводу и каждый байт имеет значение (особенно запросы SOAP и полезные данные ленты). Установите имя корневого элемента для случая, когда у вашего JSON нет единого ключа обертывания. Переключить объявление XML (<?xml version="1.0" encoding="UTF-8"?>) включительно или выключено в зависимости от того, ожидает ли потребитель пролога. И решить, следует ли пустым узлам самозакрываться как <tag/> или расширить до <tag></tag> - некоторым строгим потребителям это небезразлично.
Все работает на стороне клиента. конвертер представляет собой сериализатор без зависимостей, написанный на TypeScript, а не оболочку вокруг удаленного API. Это имеет большее значение, чем звучит: ответы API и файлы конфигурации обычно содержат токены доступа, записи клиентов и внутренние идентификаторы, а также "бесплатный онлайн-конвертер и котировки; что POSTS ваша полезная нагрузка кому-то и #39;s сервер - это утечка данных, ожидающая своего часа. Поскольку этот никогда не вызывает сетевой вызов, вы можете безопасно конвертировать конфиденциальные данные, и он продолжает работать вообще без подключения. Если вы думаете о конфиденциальности в инструментах браузера - и если вы обрабатываете данные других людей и #39;s, это должно быть - я написал об этом больше в Руководство по инструментам конфиденциальности данных, йо-
JSON против XML: быстрое сравнение
Это помогает сохранить два формата и №39; компромиссы в виду, потому что причина для картирования необходимы такие соглашения, как @ а #text это то, что XML может выражать вещи JSON can't, и наоборот.
| Аспект | JSON | хм-лиг |
|---|---|---|
| атрибуты | Никакого родного понятия | Первоклассный (<tag attr="v">)) |
| Массивы/списки | Родной [ ] тип |
Повторные родственные элементы |
| замечания | Не разрешается | <!-- ... --> поддерживаемый |
| Пространства имен | ни один | Поддержка полного пространства имен |
| Смешанное содержание (текст + элементы) | Неуклюжий | Родной |
| Схема/проверка | Схема JSON (дополнение) | XSD, DTD, RELAX NG (зрелый) |
| многословие | Компактный | Более многословный (закрывающие теги) |
| Типичное использование сегодня | Веб-API, конфигурация | МЫЛО, ленты, документы, предприятие |
выше @ существует префикс для объединения "attributes" ряд; правило повторных тегов объединяет "arrays" ряд; и #text соединяет & quot;mixed content & quot; row.Oncelly (англ.)русск. как только вы видите отображение как мост через эти конкретные пробелы, оно перестает чувствовать себя произвольным.
Чисто ли JSON-XML отправляется туда и обратно?
В основном, да - и это's по дизайну. Мой json в xml а XML в JSON инструменты имеют одно и то же @ префикс атрибута и #text ключ контента, так что преобразование XML → JSON и обратно в целом воспроизводит исходный документ. если вы 'ре строите конвейер, который должен перемещать данные в обоих направлениях, на эту симметрию стоит положиться.
Где округление-tripping становится нечетким - это одно и то же место, где каждое сопоставление JSON/XML становится нечетким: порядок и смешанный контент. Объекты JSON официально не упорядочены, поэтому конвертер может не сохранять точный порядок родственных элементов в элементах с разными именами. XML, который чередует текст и дочерние элементы (XML, который чередует текст и дочерние элементы)<p>Hello <b>world</b>!</p>) не имеет 't имеет чистое представление JSON и возвращается в качестве приближения. А элемент, который иногда появляется один раз, а иногда появляется несколько раз, неоднозначен - это одно значение или массив из одного? Это ошибки 't в каком-либо конкретном инструменте; они ' присущи тому факту, что две модели данных не полностью перекрываются. Знание того, где находятся швы, позволяет разработать свой JSON, чтобы преобразование оставалось без потерь: будьте последовательны в отношении того, всегда ли вещь является массивом, и избегайте смешанного контента там, где вы можете.
Если вы много работаете с JSON, стоит бегло использовать все семейство конверсий - я собрал те, к которым обращаюсь больше всего в мире Полное руководство по инструментам JSON, и шире Руководство по инструментам кодирования охватывает места, где преобразователи формата вписываются в повседневный рабочий процесс. Для обратного направления и соседних форматов JSON в YAML конвертер и равнина Форматтер JSON завершать сет.
Распространенные ошибки при преобразовании JSON в XML
Несколько ловушек I' ударили или смотрели, как другие ударили:
Обработка индексов массива как имен тегов. Если увидите <item0>, <item1> в чьем-то & #39;s вывода, они построили преобразователь неправильно Массивы становятся повторяется теги с же имя, взятое из массива's ключ.
Забыть там может быть только один корень. Передача многоключевого объекта прямо в сериализатор без его обертывания приводит к образованию нескольких элементов верхнего уровня, что не является хорошо сформированным документом. Оберните его.
Пропуск бегства & quot;потому что данные выглядят чистыми. & quot; Он выглядит чистым, пока одно описание продукта не содержит амперсанд или а <. Всегда убегайте; никогда не предполагай.
Размещение структурированных данных в атрибутах. Атрибуты содержат примитивы. Если вы попытаетесь засунуть вложенный объект в @-префиксный ключ, правильный преобразователь откажется (и должен) от него или проигнорирует его, потому что там 's нет для него действительного XML. Вместо этого смоделируйте его как дочерний элемент.
Дополнительно: выбор отступов и декларации для потребителя
Одна привычка, которая спасла меня, повторялась с партнерами по интеграции: сопоставляйте результат точно к тому, что ожидает потребитель, затем остановитесь. Некоторые конечные точки SOAP отклоняют документ, который включает в себя отметку байтового заказа или неожиданный пролог; другие требуют <?xml ... ?> декларация и 415 вы без нее. Некоторые валидаторы каналов хотят красиво напечатанный XML с отступом для собственной отладки; большинство производственных транспортов хотят, чтобы он был минифицирован. Вместо того, чтобы спорить, я генерирую любой вариант, который запрашивает спецификация. Это и № 39; почему конвертер раскрывает отступы (включая опцию минификации), переключатель объявлений и самозакрывающееся поведение в качестве первоклассных элементов управления - они и № 39; не украшение, они и № 39; это ручки, которые определяют, принимает ли придирчивый потребитель ваш документ с первой попытки.
часто задаваемые вопросы
Как преобразовать json в xml?
Вставьте свой JSON в редактор и нажмите Convert.Object ключи становятся XML элементами, массивы становятся повторяющимися тегами, и результат кажется готовым к копированию или загрузке.Загрузки нет - преобразование происходит в вашем браузере.
Как представлены атрибуты JSON в XML?
По соглашению, любой объектный ключ, который начинается с & quot;@& quot; префикс записывается как атрибут на его родительском элементе, а не как дочерний элемент. Например, {& quot;book& quot;: {& quot;@id& quot;: & quot;bk101& quot;, & quot;title& quot;: & quot;...& quot;}} становится
Как конвертер обрабатывает массивы JSON?
Каждый элемент массива излучается как повторяющийся элемент-брат, разделяющий имя ключа 's. Итак {"tags": {"tag": ["a", "b"]}} производит
Для чего нужен текстовый ключ?
Когда элементу нужны и атрибуты, и текстовое содержимое, текст хранится под ключом & quot;#text" {& quot;title& quot;: {& quot;@lang& quot;: & quot;en& quot;, & quot;#text& quot;: & quot;Hello& quot;}} становится
Могу ли я получить минимальный XML вместо выходного вывода?
да. Установите отступ на 0 (minify), и преобразователь выдает весь документ в одну строку без пробелов между тегами. Это полезно для запросов или каналов SOAP, где имеет значение размер полезной нагрузки; переключитесь на 2 или 4 пробела, когда вам нужен читаемый документ.
Что происходит с ключами, которые не являются допустимыми именами элементов XML?
Имена элементов XML не могут содержать пробелы, не могут начинаться с цифры, дефиса или точки и исключать большинство знаков препинания. клавиши, нарушающие эти правила, очищаются - недопустимые символы становятся подчеркиваниями, а при необходимости добавляется ведущее подчеркивание - поэтому выходные данные всегда анализируются, даже если ваши ключи JSON не были дружественны к XML.
Должна ли JSON в XML-окнообеданный с помощью инструмента XML в JSON?
Для общих структур это делает. этот инструмент и инструмент XML в JSON имеют один и тот же & quot;@ & quot; префикс атрибута и & quot;#text & quot; ключ контента, поэтому преобразование XML в JSON и обратно обычно воспроизводит один и тот же документ. Независимо от порядка детали и смешанный контент являются обычными источниками небольших различий, как и при любом сопоставлении XML/JSON.
Безопасно ли конвертировать здесь чувствительный JSON?
Да. конвертер является простым JavaScript, который полностью работает в вашем браузере - ничто из того, что вы вставляете, не передается на сервер, не регистрируется и не сохраняется. Это делает его безопасным для ответов API, конфигурирует файлы и записи, содержащие токены или персональные данные, и он продолжает работать без сетевого соединения.
