ToolAct

JSON to XML 変換ツール

JSON入力
XML出力

JSON to XML変換とは？

JSON to XML変換は、JSON（JavaScript Object Notation）データをXML（eXtensible Markup Language）形式に変換する処理です。異なるデータ形式を使用するシステム間の統合、レガシーXML APIとの連携、設定ファイルやデータ交換、ドキュメント保存にXMLが必要な場合に便利です。

使い方

使い方

  1. 左の入力ボックスにJSONデータを貼り付けるか入力してください
  2. 必要に応じてルート要素名をカスタマイズできます
  3. インデントサイズを選択してください（2スペース、4スペース、またはTab）
  4. 変換されたXMLが右側にシンタックスハイライト付きで表示されます
  5. 「コピー」または「ダウンロード」をクリックして結果を保存できます

変換チェック

  • 配列、null値、属性風フィールドは変換後に確認してください。JSONとXMLではデータのモデリング方式が異なります。
  • XMLをAPIリクエスト、設定ファイル、テストフィクスチャにコピーする前に、安定したルート要素名を決めておきましょう。

利用シーン

XML専用インテグレーション向けにJSONペイロードを変換する一部のレガシーエンドポイント、インポートジョブ、ベンダーシステムは、ソースデータがJSONであってもXMLを要求します。このコンバーターではルート要素を選ート要素を選択でき、繰り返しの配列値を繰り返しのitemノードとして保持し、XML特殊文字をエスケープしてから出力します。SOAPリクエストエンベロープ、EDIテストフィクスチャ、またはJSONに移行していないパートナーペイロードの出発点として活用できます。
構造化データから読みやすいXMLサンプルを作成するインデントオプションを使用して、ネストされたJSONサンプルをドキュメント、チケット、契約の議論に十分な整ったXMLに変換します。無効または空のルート名は防御的に処理されるため、小さな命名ミスで素早い実験が失敗することがありません。インデントされた形式は、1行の圧縮版よりもコードレビューでdiffを取りやすくなっています。
手動XML編集前にエッジケースをテストするnull値、空オブジェクト、空配列、プリミティブの配列、ネストされたレコードはそれぞれ異なるXML構造を生成します。まずコンバーターでサンプルを通すことで、結果をマッパー、SOAPクライアント、インポートテンプレートに貼り付ける前にそれらの選択肢が可視化されます。スキーマが変更されるたびに変換を繰り返して、XMLがJSON契約と同期していることを確認してください。
JSONフィールドを属性と子要素に意図的にマッピングするどのキーを属性にし、どのキーを子要素にするかを選択します。一部のレガシースキーマはID系フィールドを属性として扱い、説明は要素のままにするためです。マッピングを変更するたびに再実行して、必須の属性順序と名前空間プレフィックスが期待されるXSDと一致していることを確認してください。ドキュメント内のXML属性の順序は意味を持ちませんが、XSDシーケンスでは要素の順序が要求される場合があることに留意してください。
パートナーのXSDで結果を検証する変換後、XMLをxmllint --schemaまたはオンラインXSDバリデーターに入力して、コンバーターだけでは強制できない必須要素の欠落、型の間違い、順序ルールを検出します。整形式のXMLドキュメントとダウンストリームパートナーが受け入れるXMLは同じではありません。属性と要素の選択はXSDがどのフィールドを必須と見なすかを変えます。バリデーターがクリーンな一致を報告するまでJSONまたは変換ルールを反復し、ペイロードに署名してください。

仕組み

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文字列コンテンツは、要素テキストと属性値でエンティティエスケープも必要です：`&` → `&amp;`、`<` → `&lt;`、`>` → `&gt;`（古いXMLではテキスト内のみ必須ですが、常に安全です）、`"` → `&quot;`、`'` → `&apos;`（属性内）、符号化範囲外の任意の文字は`&#xHHHH;`とします。5つの組み込みエンティティと数値文字参照はXMLで必須であり、HTMLの追加名前付きエンティティ（`&nbsp;`、`&copy;`）はプレーン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名であり、スラグ化するか拒否する必要があります。
  • エンティティエスケープ：`&` → `&amp;`、`<` → `&lt;`、`>` → `&gt;`、`"` → `&quot;`、`'` → `&apos;`、その他の符号化外文字は`&#xHHHH;`とします。5つの組み込みエンティティは必須であり、`&nbsp;`などの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"}
->
&lt;root>
  &lt;name>Alice&lt;/name>
&lt;/root>

配列 -> 要素

[1, 2, 3]
->
&lt;root>
  &lt;item>1&lt;/item>
  &lt;item>2&lt;/item>
  &lt;item>3&lt;/item>
&lt;/root>

ネスト構造

{"user": {"name": "Alice", "age": 25}}
->
&lt;root>
  &lt;user>
    &lt;name>Alice&lt;/name>
    &lt;age>25&lt;/age>
  &lt;/user>
&lt;/root>

よくある質問

コンバータは JSON を XML にどうマッピングしますか？

各 JSON オブジェクトは XML 要素になります。オブジェクトのキーは子要素名になり、プリミティブ値は要素のテキストになります。配列は親要素を複数回繰り返します。テキスト内の特殊文字はエスケープされます (& → &amp;、< → &lt;)。

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 の生成はブラウザ内で行われます。入力はアップロードされません。

関連ツール

ZIPパッケージ圧縮

オンラインZIPパッケージ圧縮ツール。複数ファイルアップロード、ドラッグ＆ドロップ追加、ワンクリックZIPダウンロード。ブラウザローカル処理、プライバシー保護。

URL エンコードデコードツール

オンラインURLエンコード・デコードツール。特殊文字、日本語パラメータを自動処理。URLパラメータを素早く変換し、文字化け問題を解決し、データの正確な送信を確保。

Excel to SQL 変換ツール

オンラインExcel to SQLコンバーター。.xlsxおよび.xls形式に対応、複数シート選択対応。スプレッドシートデータをローカルでSQL INSERT文に変換。

CSV to SQL 変換ツール

カスタムテーブル名、区切り文字、引用符スタイルをサポートするオンラインCSV to SQLツール。CSVデータを素早くSQL INSERTステートメントに変換し、データベースへのインポートを容易にします。

QRコード解析

オンラインQRコード解析ツール。画像アップロード、ドラッグ＆ドロップ、クリップボード貼り付けでQRコードをスキャン・デコード。すべてブラウザ内で処理。

Unicode エンコード変換ツール

オンラインUnicodeエンコード・デコードツール。\uXXXX、&#xXXXX;など複数フォーマットの変換をサポート。国際化テキストを素早く処理し、エンコーディング問題を解決。