JSON⇔XML 変換ツール

JSONとXMLを相互変換：2つのデータ世界をつなぐ実用的なコンバーター

開発者の多くは望むと望まないとに関わらず、XMLとJSONの両方を扱います。モダンなウェブAPIはほぼJSON一択ですが、銀行・保険会社・政府機関のエンドポイント・エンタープライズERP・旧来のSOAPサービスに触れた瞬間、XMLが再び現れます。このページのJSON to XMLコンバーターはJSONをXMLに、またXMLをJSONに直接ブラウザ内で変換します。機密性の高いペイロードをリモートサービスにコピーせずに、2つのフォーマット間を自在に移動できます。

暗いインディゴの背景に、光り輝くネストされたJSONブレースがXMLタグのブラケットツリーに変換される様子 — JSONオブジェクトとXMLタグツリーは同じデータを異なる形で表現する。

XMLとJSONの本質

XML（Extensible Markup Language）はネストされたタグ・属性・名前空間を中心に構築されたマークアップフォーマットです。ドキュメントと構造化データの交換向けに設計されており、豊富な機能を持ちます。スキーマ（XSD）・名前空間・処理命令・コメント・CDATAセクション・先頭の正式な宣言などです。その豊かさこそがXMLがレガシーおよびエンタープライズシステムで今も支配的な理由です。SOAPウェブサービス・RSSおよびAtomフィード・設定ファイル（Spring・Maven・.NETアプリ設定）・Officeドキュメント形式・SWIFT・ISO 20022などの金融メッセージング標準（銀行や保険会社が今も毎日XMLを交換しています）で見られます。

JSON（JavaScript Object Notation）ははるかにシンプルです。キーと値のペアを持つオブジェクト・配列・文字列・数値・ブール値・nullです。ほぼすべてのプログラミング言語のデータ構造に1対1でマッピングされます。だからこそモダンなウェブAPI・RESTエンドポイント・モバイルアプリ・package.jsonのような設定ファイルを席巻しました。JSONは通常、同等のXMLより30〜50%小さく、パースも明らかに速くなります。XMLを冗長にする閉じタグと属性の仕組みを省略しているからです。

変換で重要な主な違い

2つのフォーマットは互いにマッピングできるほど重複していますが、クリーンではありません。ほぼすべての摩擦の原因となる構造的な違いがいくつかあります：

属性と子ノード。XMLは<user id="1">（属性）と<user><id>1</id></user>（子要素）を区別します。JSONにはそのような概念がないため、コンバーターが1つ考案します。慣例では属性は@attributesのようなキーや@プレフィックスに折りたたまれ、要素のテキストは#textのようなキーに入ります。
配列。JSONにはネイティブの配列があります。XMLにはありません。XMLのリストは単に同じタグが繰り返されるだけです。例えば3つの<item>要素が並ぶ形です。コンバーターは繰り返しの兄弟要素がJSON配列にまとめられるべきか、1つの要素がプレーンなオブジェクトとして残るべきかを推測しなければなりません。
名前空間。XMLはスキーマ間の名前衝突を避けるために名前空間（xmlns:soapプレフィックス）を使います。JSONには同等のものがないため、プレフィックスはキーの中にリテラル文字として残るか、削除されます。
冗長性とメタデータ。XMLは属性を通じてノードにメタデータを付加できます。JSONはすべてをキーと値として表現します。そのためJSONはよりコンパクトで読みやすく、XMLはXSDスキーマによる検証能力を保持します。

注意すべき変換の落とし穴

JSONをXMLに変換し、さらにJSONに戻して同一の結果を期待するのが典型的な誤りです。両方向でルールを制御しない限り、変換は非可逆です。以下の点に注意してください：

属性が変形する。JSONをXMLに変換する際、ツールはどのキーが属性になり、どのキーが要素になるかのルールが必要です。逆方向では属性がどこかに行かなければならず、その「どこか」（@プレフィックス・@attributesブロック）はライブラリによって異なります。下流のパーサーが異なる慣例を期待している場合、何も失われていないのにデータがおかしく見えます。
単一要素と配列。1つの<item>を持つXMLフィードはJSONオブジェクトを生成しますが、同じフィードに2つのアイテムがあると配列を生成します。配列を前提としたコードは単一アイテムのケースで壊れます。これはRSSおよびSOAPのパースバグの一般的な原因です。
名前空間が漏れるか消える。ツールによっては、soap:Bodyが文字通りsoap:Bodyという名前のキーになったり、プレフィックスが完全に削除されてドキュメントの意味が変わったりします。
混在コンテンツと型。XMLはすべてをテキストとして扱うため、trueや42のような値はJSONへの変換後も文字列のままになることがあります。逆方向ではJSONにコメントやCDATAのネイティブな置き場所がありません。

シアンとゴールドの光で作られた抽象的なマークアップノードで橋渡しされた2つの構造化データツリー — フォーマット間のマッピングでは、属性・配列・名前空間の変換方法を決める必要がある。

ローカルのみの変換が重要な理由

JSONとXMLのペイロードは、開発者が扱う中で最も機密性の高いものであることが多いです。トークンを含むAPIレスポンス・アカウント番号を含むSOAPメッセージ・クレデンシャルを含む設定ファイルなどです。ブラウザ内で動作するコンバーターはそれらを一切アップロードしません。パースとシリアライズはマシン上で行われ、サーバーには何も送信されず、ページがロードされれば一度はオフラインでも動作します。本番データのデバッグやコンプライアンス規制下の作業では、安全なクイックチェックと偶発的なデータ漏洩の違いがそこにあります。

結果を後で整形したい場合は、他のデータコンバーターと組み合わせるか、パイプラインの次のツールに渡す前にJSONフォーマッターで出力を整えてください。

よくある質問

コンバーターはJSONやXMLをどこかにアップロードしますか？

いいえ。JSONからXMLへの変換もXMLからJSONへの変換も、すべてブラウザ内で実行されます。データがデバイスを離れることはなく、ページのロード後はオフラインでも動作します。

JSONに変換する際にXMLの属性はどのように扱われますか？

JSONにはネイティブの属性の概念がないため、XML属性はアットマーク（@）プレフィックスやattributesブロックで囲まれた専用キーに配置されます。要素のテキストコンテンツは別途保存されるため、両者が変換後も保持されます。

単一のXML要素がなぜ配列ではなくオブジェクトになったのですか？

XMLにはネイティブの配列がないため、リストは単に繰り返しタグです。要素が1つしかない場合、コンバーターはそれを通常のオブジェクトと区別できないため、オブジェクトになります。同じタグ名を持つ2つ以上の兄弟要素がJSON配列にまとめられます。

soapやxmlnsのようなXML名前空間はどうなりますか？

JSONにはXML名前空間に相当するものがありません。変換によって、プレフィックスはキーの中にリテラルテキストとして保持されるか、削除されます。下流のコンシューマーが名前空間プレフィックスに依存している場合は出力を確認してください。

JSONをXMLに変換して元のドキュメントと同じにできますか？

必ずしもできません。XMLのコメント・CDATA・属性と要素の区別にはJSONで対応できるものがないため、変換は両方向で非可逆です。両側でネーミングルールを制御できる場合、ラウンドトリップは最も安定します。

JSONと比べてXMLが今も使われているのはどこですか？

XMLはレガシーおよびエンタープライズシステムに存在します。SOAPウェブサービス・RSSおよびAtomフィード・設定ファイル・SWIFTやISO 20022のような金融メッセージングなどです。JSONはモダンなウェブAPI・RESTエンドポイント・モバイルアプリを支配しています。