JSON ↔ XML 変換

JSON ↔ XML 変換とは？#

JSON と XML は、構造化データを書き記す 2 つの異なる方法であり、構文レベルでは互換性がありません——一方は波括弧と角括弧を使い、もう一方は山括弧のタグを使います。両者の変換ツールは「圧縮」や「エンコード」をするわけではなく、同じ値のツリーをもう一方の表記法で書き直します。その結果、XML しか扱えないシステムが、JSON で届いたデータを利用でき、その逆も可能になります。

対応はほぼ機械的ですが、よく知られた 2 つの難点があります。第一に、XML はすべてを包むルート要素をちょうど 1 つ要求しますが、JSON は最上位に裸のオブジェクトや配列を置けます——そのため JSON から XML への変換では、常にこの外側のラッパー名を決める必要があります。第二に、XML 要素は属性を持てます（<a id="7">）が、JSON にはそれに直接相当するものがありません。一般的な慣習は、属性を @ 接頭辞付きのキーの下に置き、属性と並存するテキストを #text キーの下に置くことです。

このページはブラウザ内で両方向の変換を行います。JSON から XML（あなたが名付けたルート要素の下に値を包む）、および XML から JSON（属性を @ キーに展開し、既定では外側のルートを剥がして内側の値を返す）です。

使い方#

1. ツールバー左上のJSON → XML / XML → JSON切り替えで方向を選びます。
2. 左側の入力ペインに入力または貼り付けを行います。
   • JSON → XML は有効な JSON を期待します。最上位の値はすべてルート要素の下に包まれます。
   • XML → JSON は整形式の XML ドキュメントを期待します。単一の外側要素は自動的に展開（アンラップ）されるため、内側の内容が JSON として得られます。
3. JSON → XML モードでは、ルート要素フィールド（既定は root）でラッパータグの名前を設定します——例えば user、feed、response。XML は単一のルートを必須とするため、この名前は常に必要です。
4. 結果は出力ペインにリアルタイムで表示されます。コピーで取り出せます。
5. サンプルは現在の方向に合った小さなドキュメントを読み込みます。クリアは両ペインをリセットします。

主な特徴#

• 1 つのツールで両方向。 単一の切り替えで JSON→XML と XML→JSON を切り替え、入力ペインは自動的に再設定されます。
• 設定可能なルート要素。 XML は単一の外側要素なしでは存在できないため、ラッパーに名前を付けます。コンバーターは JSON のどんな最上位の形にもラッピングを適用します。
• 適切な XML 宣言。 JSON→XML の出力は標準の <?xml version="1.0" encoding="UTF-8"?> プロローグで始まり、2 スペースのインデントで整形されます。
• 属性の往復変換。 XML→JSON は要素の属性を @ 接頭辞付きキーの下に保持し、属性の隣にあるテキストは #text の下に保たれるため、何も黙って削り落とされません。
• 数値を考慮した解析。 XML はすべてテキストです。パーサーは数値に見える要素の値を JSON の数値に戻します（<age>36</age> は "36" ではなく 36 になります）。

実例#

JSON → XML#

方向をJSON → XML に設定し、ルート名を root としてサンプルを読み込みます:

{
  "name": "Ada",
  "age": 36,
  "skills": ["math", "logic"]
}

コンバーターはすべてを <root> の下に包み、配列を XML が要求する形に展開します——各エントリが同じタグの独自の要素になります:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <name>Ada</name>
  <age>36</age>
  <skills>math</skills>
  <skills>logic</skills>
</root>

ルート要素フィールドを person に変えると、ラッパーは <person> / </person> になります——内側の構造はそのままです。

XML → JSON#

XML → JSON に切り替えてサンプルを読み込みます:

<?xml version="1.0"?>
<root><name>Ada</name><age>36</age></root>

外側の <root> は剥がされ、内側の要素が JSON のプロパティになります。36 は数値として認識されます:

{
  "name": "Ada",
  "age": 36
}

属性も保持されます。<a id="7">label</a> のような要素は { "@id": "7", "#text": "label" } になります——属性は @id の下、テキストは #text の下に置かれ、どちらも失われません。

よくある質問#

JSON の配列が、要素を内側に持つ 1 つのラッパーではなく、繰り返しの XML 要素になるのはなぜですか？#

それが XML におけるリストの表現方法です。「配列」の構文がないため、各エントリは同じタグ名の独自の要素でなければなりません。したがってキー skills の下の JSON 配列 ["math", "logic"] は、子要素を含む単一の <skills> ではなく、2 つの兄弟 <skills> 要素になります。これは標準的でスキーマフレンドリーな対応であり、XML の消費側もこれを期待します。

XML → JSON で、外側の要素はどこへ行きましたか？#

コンバーターは単一のルートを自動的に展開します。XML は最上位要素をちょうど 1 つ強制しますが、JSON ではそのラッパーは通常冗長です——<root><name>Ada</name></root> は、root に JSON が必要とする情報を何も持ちません。これを剥がすことで、意味のある内側の値が直接得られます。ルートを本当に保持したい場合は、通常の要素として扱い、名前でアクセスしてください。

出力で 36 が文字列ではなく数値なのはなぜですか？#

XML には数値型が別途なく、タグの間はすべてテキストです。パーサーは数値への強制変換を適用するため、テキストが数値に見える要素（36、3.14）は JSON の数値として戻ります。これは典型的なデータには便利ですが、製品コード <code>007</code> のような値は先頭のゼロを失うことを意味します——そのような値は属性として保存するか、文字列として受け取ってください。

任意の XML ドキュメントを変換できますか？#

整形式の XML なら可能です。タグの名前空間、属性、自己終了要素、宣言を含みます。DTD の解決、スキーマに対する検証、外部エンティティの取得は行いません——処理はローカルかつテキストのみであり、それがすなわち、完全には信頼できないドキュメントを貼り付けても安全だという理由でもあります。