JSON to XML 変換ツール
JSON to XML変換とは？
JSON to XML変換は、JSON（JavaScript Object Notation）データをXML（eXtensible Markup Language）形式に変換する処理です。異なるデータ形式を使用するシステム間の統合、レガシーXML APIとの連携、設定ファイルやデータ交換、ドキュメント保存にXMLが必要な場合に便利です。
使い方
使い方
- 左の入力ボックスにJSONデータを貼り付けるか入力してください
- 必要に応じてルート要素名をカスタマイズできます
- インデントサイズを選択してください（2スペース、4スペース、またはTab）
- 変換されたXMLが右側にシンタックスハイライト付きで表示されます
- 「コピー」または「ダウンロード」をクリックして結果を保存できます
変換チェック
- 配列、null値、属性風フィールドは変換後に確認してください。JSONとXMLではデータのモデリング方式が異なります。
- XMLをAPIリクエスト、設定ファイル、テストフィクスチャにコピーする前に、安定したルート要素名を決めておきましょう。
利用シーン
仕組み
JSON（RFC 8259、JavaScriptオブジェクトリテラルに由来）とXML（W3C XML 1.0、1998年策定）はいずれもツリー構造のシリアライゼーション形式ですが、文法が異なります。JSONはオブジェクト（文字列キーを持つキー/値マップ）、配列（順序付きリスト）、6種類のスカラ型（文字列、数値、ブール値、null、および構造型）を持ちます。XMLは要素（開始/終了タグのペアでテキストや子要素を囲む）、属性（開始タグの名前/値ペア）、テキストノード、コメント、処理命令、CDATAセクションを持ちます。変換は正解のない構造変換であり、BadgerFish、JSONML、SOAP/RPCエンコーディング、OOXMLのフラットスキーマ、XBRLのリンクベース形式など、既存のすべての規約は同じ入力に対する異なるルールです。 「属性と子要素」の選択が中心的な曖昧さです。JSONのメタデータはキー名にのみ存在するため、{"id": "42", "name": "Alice", "admin": true}のようなJSONオブジェクトは、どのキーが「メタデータ」でどのキーが「データ」かを示しません。3つの一般的な規約があります：(1)ページのデフォルト — スカラ値はテキストコンテンツとなり、ネストされた属性バッグオブジェクト（値がすべてスカラのみの非配列オブジェクトで認識）の元のJSONキーは、`@`プレフィックス付きのXML属性になります（BadgerFish規約）。(2)JSONML — すべてのJSONオブジェクトは要素となり、「tag」キーが要素名、「attr」キーが属性マップ、子エントリが子要素となります。(3)oData/Atom — JSONオブジェクトは要素となり、配列は配列名のラッパー要素でインライン化されます。各ルールは一部のダウンストリームコンシューマーに対して証明可能な正しさを持ち、別のコンシューマーに対して証明可能な誤りを持ちます。これが、XMLへのコンバーターが普遍的に受け入れられたことがない理由です。 配列は2番目の曖昧さです。JSON配列は順序付きリストですが、XMLにはネイティブの配列型がありません。3つの標準的な解決策があります：(a)子要素を繰り返す（ページのデフォルト、OOXML/SOAP規約）：[1, 2, 3] → <root><item>1</item><item>2</item><item>3</item></root>。(b)コンテナーで囲む：<root><items><item>1</item>...</items></root>。(c)配列を単一の区切り文字列として符号化し、区切り文字を文書化する（CSV-in-XML、コンシューマーが解析する場合のみ）。各解決策は異なるダウンストリームXSDに対して正しく、変換ステップはどれを出力するかを知る必要があります。 XML要素名は有効なQNameトークンでなければなりません（XML 1.0 §2.3 / XML Namespaces 1.0 §3）：文字、アンダースコア、またはコロンで始まり、その後に文字、数字、ハイフン、アンダースコア、ピリオド、またはコロンが続きます。JSONでは「123」や「first name」のようなこのルールに違反するキーが許容されますが、コンバーターはそれらをリネームする（first_nameにスラグ化、_プレフィックスを付与）か、失敗させる必要があります。JSON文字列コンテンツは、要素テキストと属性値でエンティティエスケープも必要です：`&` → `&`、`<` → `<`、`>` → `>`（古いXMLではテキスト内のみ必須ですが、常に安全です）、`"` → `"`、`'` → `'`（属性内）、符号化範囲外の任意の文字は`&#xHHHH;`とします。5つの組み込みエンティティと数値文字参照はXMLで必須であり、HTMLの追加名前付きエンティティ（` `、`©`）はプレーンXMLでは定義されておらず、使用には明示的なDOCTYPEが必要です。 出力ドキュメントにはプロローグと名前空間宣言も必要です：最初に`<?xml version="1.0" encoding="UTF-8"?>`、その後にxmlns宣言を記述します。ターゲットシステムが名前空間を使用する場合（SOAPは`http://www.w3.org/2003/05/soap-envelope`、XSLTは`http://www.w3.org/1999/XSL/Transform`）、プレフィックスマッピングはルート要素の`xmlns:prefix="uri"`属性として追加されます。JSONには名前空間の概念がないため、どのURIを使用するかはプロジェクト固有です。空の値について、JSON nullは通常`<key xsi:nil="true"/>`（XMLスキーマ規約）または`<key></key>`（空要素規約）として表現されます。コンバーターはいずれかを選択しますが、正しい答えはコンシューマーのXSDバリデーションに依存します。 逆方向（XML → JSON）についても同じ曖昧さが存在します：属性はBadgerFishでは`@attributes`キーにマッピングされ、CDATAは`$`または`#text`キーにマッピングされ、混合コンテンツ要素（テキストと子要素が交互に並ぶ）はきれいなJSON表現を持たず、通常は文字列連結として出力されます。実世界のコンバーターは常に「属性キー」「テキストキー」「配列ラッパー」オプションを公開しており、これを回避する方法はありません。
- JSON（RFC 8259）とXML（W3C XML 1.0、1998年）はいずれもツリー構造のシリアライゼーション形式であり、変換は正解のない構造変換のため、BadgerFish、JSONML、SOAP、OOXMLなど複数の規約が同じ入力に対して併存します。
- 属性と子要素の選択：スカラ値はデフォルトでテキストコンテンツとなり、ネストされた属性バッグオブジェクト（値がすべてスカラのみ）は@プレフィックス付き属性になります（BadgerFish）。JSONMLは「tag」/「attr」キーを使用し、oData/Atomはラッパー要素を使用します。
- 配列：ページのデフォルトでは子要素を繰り返します（OOXML/SOAP規約）。代替手段として、コンテナー要素で囲むか、区切り文字列として符号化します。JSONの配列順序はXML出力で保持されます。
- XML要素名のルール：文字、アンダースコア、またはコロンで始まり、その後に文字/数字/ハイフン/アンダースコア/ピリオド/コロンが続きます（XML 1.0 §2.3）。JSONキーの「123」や「first name」は無効なXML名であり、スラグ化するか拒否する必要があります。
- エンティティエスケープ：`&` → `&`、`<` → `<`、`>` → `>`、`"` → `"`、`'` → `'`、その他の符号化外文字は`&#xHHHH;`とします。5つの組み込みエンティティは必須であり、` `などのHTML拡張には明示的なDOCTYPEが必要です。
- ドキュメントプロローグ：`<?xml version="1.0" encoding="UTF-8"?>`が標準の最初の行です。ルート要素のxmlns宣言で名前空間プレフィックスを宣言し、JSONには名前空間の概念がないため、コンバーターはプロジェクトごとに選択します。
- JSON null → XML：`<key xsi:nil="true"/>`（XMLスキーマ規約）または`<key></key>`（空要素）のいずれか。選択はコンシューマーのXSDに一致させる必要があり、さもなければバリデーションが失敗します。
- 逆方向のXML → JSONでも同じ曖昧さがあります：CDATAセクションは`$`または`#text`キー（BadgerFish）となり、混合コンテンツ要素（テキストと子要素が交互に並ぶ）はきれいなJSON形式を持たず、通常は文字列に連結されます。
使用例
オブジェクト -> 要素
{"name": "Alice"}
->
<root>
<name>Alice</name>
</root>配列 -> 要素
[1, 2, 3]
->
<root>
<item>1</item>
<item>2</item>
<item>3</item>
</root>ネスト構造
{"user": {"name": "Alice", "age": 25}}
->
<root>
<user>
<name>Alice</name>
<age>25</age>
</user>
</root>よくある質問
コンバータは JSON を XML にどうマッピングしますか？
各 JSON オブジェクトは XML 要素になります。オブジェクトのキーは子要素名になり、プリミティブ値は要素のテキストになります。配列は親要素を複数回繰り返します。テキスト内の特殊文字はエスケープされます (& → &、< → <)。
JSON から XML への変換が常に可逆ではないのはなぜですか？
JSON には明示的な数値・真偽値・null 型がありますが、XML にはテキストしかありません。JSON はスペースや特殊文字を含むキーを許可しますが、XML の要素名には許可されません。トップレベルの配列には明確な XML での等価表現がありません。本ページではヒューリスティック (ラッパー要素 'root'、無効なキーのサニタイズ) を使ってこれらの差を埋めます。
配列の値は XML でどう表現されますか？
各配列要素は同じ名前の兄弟要素になります。[{a:1},{a:2}] → <items><item><a>1</a></item><item><a>2</a></item></items>。ラッピングは設定可能で、一部のページでは単数形の要素名を明示的に選択できます。
有効な XML 名でない JSON キーはどうなりますか？
XML 要素名は数字で始められず、スペースや特定の記号を含めることもできません。本ページは無効な文字をアンダースコアに置換するか、CDATA で包んでサニタイズします。結果は有効な XML ですが、ラウンドトリップは厳密ではありません。
JSON の null と真偽値は保持されますか？
null は設定により空要素になるか、要素自体が省略されます。true/false はリテラルテキスト 'true' または 'false' になります。これらの型に対する XML 標準はないため、下流のパーサーが独自の型解釈を適用する必要があります。
XML 属性を追加できますか？
JSON には属性の概念がないため、ジェネレータはデフォルトですべてを要素として出力します。一部のコンバータは属性を示すために特別なキープレフィックス (例えば '@id') を使用します。属性出力が XML スキーマで重要な場合はページのオプションを確認してください。
変換はローカルで行われますか？
はい。JSON の解析と XML の生成はブラウザ内で行われます。入力はアップロードされません。