2 つのモデルは並んでいません: RFC 8259 属性のない 6 つの JSON タイプを定義します XML 1.0 属性、名前空間、順序付き混合コンテンツがあります。この方向に進むということは、違いをどうするかを選択することを意味します。
初めてJSONデータをXMLしか話さないシステムに送信しなければならなかったとき、私は素朴なことをしました: テキストエディタで角括弧を手書きしました SOAP風のエンベロープを期待するサプライヤフィードでした、そして私のソースはLaravel APIから出てくる整然としたJSON配列でした 20 分後、私は40 番目のレコードの周りのどこかにクロージングタグを不一致にしていて、受信パーサーが" junk after document element" について何も教えてくれないエラーを投げました どこ。その晩は、私がそれ以来すべての統合に適用してきた教訓を教えてくれました。JSON と XML 間の変換は創造的な行為ではありません。これは少数のルールによるマッピング問題であり、それらのルールを書き留めた瞬間、全体が機械的なものになります。
このガイドは、I' dが持っていればよかった、そのマッピングのバージョンです。 [Toolz.dev] (/) をビルドし、そこにあるツールの1 つはブラウザベースです JSON から XML コンバーター それは以下の規則に正確に適用されます。 しかし、この記事のポイントはボタンではありません - it& #39; sの理解 なんでや キーが要素になるのはなぜですか @接頭辞付きキーが属性になり、配列が番号付きリストではなく繰り返しタグに変わる理由。これら 3 つのアイデアをクリックすると、必要に応じて任意の JSON を手動で XML に変換でき、ダウンストリーム システムが出力を拒否した場合に出力をデバッグできます。
tl;dr: JSON を XML に変換するには、各オブジェクト キーを要素にマッピングします
@親要素の属性の接頭辞付きキーと、#textkey to the element's text content. key's 名を共有する繰り返しの兄弟要素にすべての配列を展開します。 escape&、<、そして>テキストで (プラス)"属性値で)、および isn't は合法的な XML 名であるキーをサニタイズします。ブラウザで実行するため、トークンや顧客データを含むペイロードがマシンから離れることはありません。
そもそもなぜJSONをXMLに変換するのでしょうか?
JSONは何年も前にWeb API戦争に勝ち、React、Laravel、またはNodeで日々を過ごすなら、あなたは合理的に尋ねるかもしれません いつあなた& #39; dはXMLをまったく必要としない 答えは: 常に、あなたが見る場所ではないだけです XMLは、JSON時代より前のシステムの巨大なインストールベースの共通語であり、どこにも行きません SOAP Webサービス - まだ銀行、保険、物流、政府統合のバックボーン - はXMLでペイロードを運びます RSSとAtomフィードはXMLです サイトマップはXMLです Androidレイアウト、 .docx あんど .xlsx 内部 (Office Open XML) 、SVG、RSS ポッドキャスト フィード、および無数の B2B EDI スタイルの交換はすべて XML です。
したがって、現実世界のシナリオはほとんどの場合同じ形状です。つまり、データがあります で JSON なぜなら、それは'あなたのスタックが生成するものであり、それが必要だからです で XML because that's what the other side demands. maybe you're pushing product data into the marketplace that only accepts an XML feed. maybe you're wraping an API response in a SOAP body. maybe you're generating an RSS feed from a JSON content export.いずれの場合も、don' は毎回シリアライゼーションを再発明したくない - あなたは、任意のJSON構造を有効なXMLに変える予測可能なルールを望んでいるので、それを自動化して考えるのをやめることができます。
There's もより静かな理由です: デバッグ中の可読性。 you' が階層を理解しようとしている深くネストされた JSON ブロブを見つめているとき、それをインデントされた XML に変換すると、ツリー構造が飛び出すことがあります。なぜなら、XML's のオープン/クローズ タグは、JSON's が don't を中括弧で囲む方法でネストを明示するからです。私は保管します JSON から XML コンバーター そしてその逆 XML から JSON へのコンバー 隣接するタブで I' よりも頻繁に開きます。推測した.
JSON は正確にどのように XML にマッピングされるのでしょうか?
その核心です ルールは4 つしかなく それ以外は全て詳細です。
ルール1: オブジェクトキーが要素になる. JSON オブジェクト { "book": { "title": "..." } } なる <book><title>...</title></book>。 キーはタグ名です; 値は内側に行くものです。
ルール2: @ー接頭辞付きキーが属性になります. XML要素は属性を運ぶことができ、JSONにはそれらのネイティブの概念がないため、規則が必要です。 広く使用されているもの - そして私のツールが使用するもの - はプレフィックス文字です、 @ デフォルトで。 so { "book": { "@id": "bk101", "title": "..." } } なる <book id="bk101"><title>...</title></book>。属性は、XML 属性が実際にどのように機能するかと一致する、ネストされていない構造であるプリミティブ値 (文字列、数値、ブール値) のみを保持できます。
ルール 3: The #text キーはテキストコンテンツになります. 要素が必要な場合 両方 属性とテキスト - 考えてください <title lang="en">Hello</title> ー you can't express that with a plain string value, because the string leaves no room for the attribute.規則は予約キーです、 #text: { "title": { "@lang": "en", "#text": "Hello" } }.要素にテキストのみがあり、属性がない場合は、スキップできます #text そして、単純な文字列値を使用するだけです。
ルール4:配列は反復要素となる. 最も頻繁に間違うのはこれです. XML には配列型がありません. 物事のリストは同じタグ名を持つ兄弟要素の繰り返しとして表現されます. ですから. { "tags": { "tag": ["computer", "web"] } } なる <tags><tag>computer</tag><tag>web</tag></tags> ー じゃない <tag>0</tag> または、インデックスベースのナンセンス。 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 deliberate: well-formed XML ドキュメントは、正確に 1 つのルートを持つ必要があります。 json がすでに単一のラッピングキーを持っているとき、そのキー です ルート。 does' t - コンバータにマルチキーオブジェクトまたは裸の配列を渡すと、ツールは構成可能なルート要素の下にすべてをラップします ()root デフォルトでは) 出力は整ったままになります。
エスケープや無効な名前はどうですか?
2 つのことが、どのネスティング バグよりも多くの変換を静かに破ります。それは、エスケープされていない特殊文字と違法な要素名です。
脱出. XMLは、一握りの文字を予約します。 element テキストの中、 &、 <、そして > と書かなければならない &、 <、そして >。 double-quoted 属性値の内側では、追加で double-quotation を としてエスケープする必要があります "。 JSON 文字列に が含まれている場合 Tom & Jerry そしてそれを XML raw にドロップすると、裸のアンパサンドがドキュメントを不正な形式にし、パーサーが死にます。正しいコンバーターは自動的にエスケープします "a < b & c" なる a < b & c 出力では、解析時に元のテキストに戻るラウンドトリップします。これはオプションではありません。有効な XML と無効な XML の違い。
要素名. XML にはタグ名に含まれる可能性のあるものについての厳密な規則があります。 names can' t にはスペース、can' t には数字、ハイフン、ピリオドで始まり、ほとんどの句読点は除外されます。 JSON キーにはそのような制限はありません - "first name"、 "123"、そして "total($)" すべて完全に合法的な JSON キーとすべての違法な XML 名です これを無視するコンバーターは、パーサーが受け入れないドキュメントを生成します。 pragmatic fix、そして私のツールが行うことは、サニタイズすることです: 違法な文字をアンダースコアに置き換え、名前が数字で始まるときにアンダースコアの先頭に付けることです "123 bad" なる <_123_bad>。それと#39;華やかではありませんが、出力解析を保証します。これが全体のポイントです。
ブラウザベースのコンバーターはどのように使用すればよいですか?
ワークフローがオンになっています Toolz.dev/tools/json-to-xml 上記のルールを反映しており、実際のエッジ ケースに対していくつかのオプションがあります。
入力にあなたのJSONを貼り付け、変換を押します。 jsonが奇形である場合、あなたはサイレントガベージではなく、明確な解析エラーを取得します - 私はbrowser& #39; s ownに頼ります JSON.parse、従ってエラーメッセージはあなたのコンソールでyou& #39; dが見るものと一致する。 you& #39; re shipping it over the wire and every byte counts (SOAP requests and feed payloads especially). minify を選ぶときあなたがレビューのために人間読める文書を望むときインデントの2 つか4 つのスペースを選ぶか、または1 行に全体を崩壊させるときあなたのJSONが単一のラッピングキーを持っていない場合のルート要素名を設定する.XML宣言を切り替えます ()<?xml version="1.0" encoding="UTF-8"?>消費者がプロログを期待するかどうかに応じてオンまたはオフになります。そして、空のノードが自己閉じるべきかどうかを決定します <tag/> または に展開します <tag></tag> - 一部の厳格な消費者は気にかけています。
すべてクライアント側で実行されます コンバーターはTypeScriptで書かれた依存関係のないシリアライザーであり、リモートAPIのラッパーではありません それは聞こえるよりも重要です: API応答とコンフィグファイルには日常的にアクセストークン、顧客レコード、内部識別子が含まれており、" 無料のオンラインコンバーター" ペイロードを誰かにPOSTする' sサーバーはデータ漏洩が起こるのを待っています これはネットワーク呼び出しを決して行わないため、機密データを安全に変換することができ、まったく接続せずに動作し続けます ブラウザツールのプライバシーがあなたが考えるものである場合 - そしてあなたが他の人々& #39; sデータを扱う場合は、そうあるべきです - 私はそれについて詳しく書きました データ プライバシー ツール ガイド。
JSON と XML: 簡単な比較
2 つの形式を維持するのに役立ちます'トレードオフは考慮に入れることができます 理由 マッピングには次のような規則が必要です @ あんど #text XML は JSON can't、またはその逆の表現ができるということですか。
| アスペクト | json | シーリング |
|---|---|---|
| 属性 | ネイティブの概念はありません | ファーストクラス()<tag attr="v">) |
| 配列/リスト | ネイティブ [ ] タイプ |
繰り返される兄弟要素 |
| コメント | 許可されていません | <!-- ... --> サポート |
| 名前空間 | なし | フルネームスペースのサポート |
| 混合コンテンツ (テキスト + 要素) | 厄介な | ネイティブ |
| スキーマ/検証 | JSON スキーマ (アドオン) | XSD、DTD、RELAX NG(熟年) |
| 冗長性 | コンパクト | より冗長 (タグを閉じる) |
| 今日の典型的な使用 | Web API、config | SOAP、フィード、ドキュメント、エンタープライズ |
ザ・ @ "attributes" をブリッジするためにプレフィックスが存在します。行;繰り返しタグ ルールは、"arrays" 行; をブリッジします。そして #text "mixed content" 行をブリッジします。マッピングがこれらの特定のギャップをブリッジすると、任意に感じられなくなります。
JSON から XML への往復はクリーンに行えますか?
ほとんど、はい - そしてそれ& #39; s 設計によって。 私の JSON から XML へ あんど XML から JSON へ ツールは同じものを共有します @ 属性 プレフィックス および #text コンテンツキー, だから変換 XML → JSON とバックは、一般的に元の文書を再現します。 you& #39; データを両方向に移動する必要があるパイプラインを構築する再構築, その対称性は頼る価値があります。
Where round-tripping gets fuzzy is the same place every JSON/XML mapping gets fuzzy: order and mixed content.JSONオブジェクトは公式には順序付けされていないため、コンバータは異なる名前の要素の正確な兄弟順序を保持しない場合があります。 XMLはテキストと子要素をインターリーブします()<p>Hello <b>world</b>!</p>) does' はクリーンなJSON表現を持ち、近似として戻ってくる。 そして、時々1 回現れ、時々複数回現れる要素はあいまいである - それは単一の値か、1 つの配列か? These aren't bugs in any particular tool; they're inherent to the fact that the two data models don't perfectly overlap.縫い目がどこにあるかを知ることは、変換が損失のないままであるようにJSONを設計することができます: 物事が常に配列であるかどうかについて一貫性を保ち、混合コンテンツを避けることができます。
JSON をよく使えば、it'コンバージョン ファミリー全体にわたって流暢さを構築する価値があります。私が最もリーチできるコンバージョンを集めました JSON ツールの究極のガイド、 と より 広い コーディング ツール ガイド フォーマットコンバータが日常のワークフローに適合する場所をカバーします。逆方向と隣接するフォーマットについては、 JSON から YAML へのコンバータ そして平原 JSON フォーマッタ セットを丸めます.
JSONをXMLに変換するときによくある間違い
いくつかのトラップI& #39; 打撃または他の人がヒットするのを見ました:
配列インデックスをタグ名として扱う. もし見たら <item0>、 <item1> someone& #39; s 出力では、コンバーターを間違って構築しました。 配列になります 繰り返した を備えたタグ 同じ 名前。配列's キーから取得されます。
忘れることは1 つの根しかあり得ません. マルチキーオブジェクトをシリアライザにラッピングせずにそのまま渡すと、複数のトップレベルの要素が生成されますが、これは整形式のドキュメントではありません。それをラップします。
" のエスケープをスキップするデータがクリーンに見えるため." 1 つの製品説明にアンパサンドまたは a が含まれるまでは、きれいに見えます <。 常に逃げる; 決して仮定しない.
構造化データを属性に入れる. 属性にはプリミティブが保持されます。 nested オブジェクトを に押し込もうとすると、 @接頭辞付きキー、正しいコンバーターはそれをドロップするか無視します (そしてそうすべきです)。なぜなら、there's には有効な XML がないからです。代わりに子要素としてモデル化します。
詳細: 消費者向けのインデントと宣言の選択
統合パートナーと何度もやり取りする私を救ってくれた習慣の 1 つは、出力を一致させることです 正正と 消費者が期待するものに、その後停止する SOAP エンドポイントの中には、バイトオーダーマークや予期しないプロログを含むドキュメントを拒否するものもあります; 他のものは、 <?xml ... ?> 宣言とそれなしで415 あなた 一部のフィードバリデータは、自分のデバッグのためにかなり印刷されたインデントされたXMLを望んでいます; ほとんどの生産トランスポートは、それを縮小することを主張するのではなく、仕様が求めるバリアントのいずれかを生成します。 that' s コンバータがインデント (minify オプションを含む)、宣言の切り替え、およびファーストクラスのコントロールとしての自己閉じる動作を公開する理由 - they're decoration, they're the knobs that re picky consumer accepts your document on the first try.
フェイク
JSON を XML に変換するにはどうすればよいですか?
JSONをエディタに貼り付けて 変換 を押します オブジェクトキーはXML要素になり、配列は繰り返しタグになり、結果はコピーまたはダウンロードの準備ができているように見えます アップロードはありません - 変換はブラウザで行われます。
JSON 属性は XML でどのように表されますか?
慣例により、 "@" で始まる任意のオブジェクトキーは、プレフィックスは子要素としてではなく、親要素上の属性として記述されます。たとえば、 {"book": {"@id": "bk101", "title": "..."}} になります
コンバータは JSON 配列をどのように処理しますか?
配列の各要素は、key's 名を共有する繰り返しの兄弟要素として放出されます。 So {"tags": {"tag": ["a", "b"]}} が生成します
#テキストキーは何のため?
要素に属性とテキスト コンテンツの両方が必要な場合、テキストは "#text" キーの下に保存されます。 {"title": {"@lang": "en", "#text": "Hello"}} になります
インデント出力の代わりに、縮小された XML を取得できますか?
はい。 インデントを 0 (minify) に設定すると、コンバーターは、タグの間に空白を持たない 1 行でドキュメント全体を放出します。 これは、ペイロード サイズが重要な SOAP リクエストまたはフィードに役立ちます。読み取り可能なドキュメントが必要な場合は、2 つまたは 4 つのスペースに切り替えます。
XML 要素名が有効でないキーはどうなりますか?
XML 要素名にはスペースを含めることはできず、数字、ハイフン、ピリオドで始めることもできず、ほとんどの句読点を除外することもできません。これらのルールに違反するキーはサニタイズされます。無効な文字はアンダースコアになり、必要に応じて先頭のアンダースコアが追加されます。そのため、JSON キーが XML に適していなかったとしても、出力は常に解析されます。
JSON から XML へのラウンドトリップ XML から JSON ツールを使用しますか?
一般的な構造の場合、それは行われます。このツールと XML から JSON へのツールは同じ "@" 属性プレフィックスと "#text" コンテンツ キーを共有するため、XML を JSON に変換して戻すことは通常、同じドキュメントを再現します。順序に依存しない詳細と混合コンテンツは、XML/JSON マッピングの場合と同様に、小さな違いの通常のソースです。
ここで機密性の高い JSON を変換しても安全ですか?
はい。コンバータは完全にブラウザで実行されるプレーンな JavaScript です。貼り付けたものはサーバーに送信されず、ログに記録されず、保存されません。これにより、API 応答、トークンや個人データを含む構成ファイルやレコードに対して安全になり、ネットワーク接続なしで動作し続けます。
