データ

XML コンバーター

XML を JSON、YAML、TOML、JavaScript オブジェクトリテラル、PHP 配列に変換します。ブラウザ内蔵の XML パーサーが文書を読み取り、構造に沿ってマッピングします。要素はキーになり、同名で繰り返す兄弟要素は配列にまとまり、属性は接頭辞付きのフィールドになるため、出力は元の構造をできるだけ保ちます。SOAP レスポンス、RSS や Atom フィード、サイトマップ、SVG、Android や Maven の設定、レガシー API の報文といった日常的な XML に対応し、属性・テキスト値・数値の扱いを選べます。チェックパネルはルート要素、要素と属性の数、名前空間接頭辞、混在コンテンツ、CDATA をまとめて表示します。解析エラーには行・列と前後の文脈が付きます。解析・変換・コピーはすべてこのタブ内で行われ、サーバーへの送信・中継・記録はありません。

  • 1 つの XML 入力から 5 つのターゲット（JSON、YAML、TOML、JavaScript オブジェクトリテラル、PHP 配列）を生成し、それぞれ独自のオプションを持つ
  • 属性は接頭辞付きキー（設定可能、既定は @）にマッピングされ、要素内容だけが必要なときは丸ごと除外できる
  • 繰り返す子要素は配列にまとまり、テキスト値は数値・真偽値へ変換することも、そのまま保つこともできる
  • チェックパネルはルート要素、要素と属性の数、ネストの深さ、名前空間接頭辞、混在コンテンツ、CDATA を表示
  • 完全ローカル処理。アップロードもテレメトリもなく、本番報文、SOAP のキャプチャ、設定サンプルでも安全
tools/XML コンバーター
0 文字
入力待ち
変換結果がここに表示されます
操作

概要

XML を起点とする作業に絞ったツールです。要素からキーへのマッピング、繰り返す兄弟要素の配列化、属性の扱い、値の型変換は解析時に解決されるため、出力は下流の API、設定ローダー、JSON Schema バリデーター、コードジェネレーターへ二度手間の手直しなしに渡せます。

  1. 01

    標準で 5 つのターゲット形式

    XML を JSON、YAML、TOML、JavaScript オブジェクトリテラル、PHP 配列へ。JSON はインデント幅とキーのアルファベット順ソートを備え、YAML と TOML は整ったネスト構造を出力し、TOML は中途半端な出力ではなくオブジェクトのルートを強制します。JS オブジェクトリテラルは引用符付きキーと適切なエスケープを保ち、PHP 配列は完全な <?php return [...]; ファイルを出力します。

  2. 02

    予測しやすい要素からオブジェクトへのマッピング

    各要素はタグ名をキーとするオブジェクトになり、テキスト内容が値になり、繰り返し現れる同名の兄弟要素は文書順で配列にまとまります。ルート要素名はトップレベルのキーとして保持され、出力が元のツリーを反映します。

  3. 03

    属性を自分で制御

    属性は設定可能な接頭辞（既定は @）付きのキーにマッピングされ、子要素名と衝突しません。要素内容だけが必要なときは属性を完全に無効化でき、要素が属性とテキストの両方を持つ場合はテキストが #text フィールドに移ります。

  4. 04

    任意の値の型変換

    数値や真偽値のテキストは実際の数値・真偽値に変換することも、文字列のまま保つこともできます。変換は値が厳密に往復できる場合だけ適用されるため、先頭ゼロのコード、版番号らしき文字列、電話番号、安全範囲を超える整数は文字列のまま残ります。

  5. 05

    不慣れな XML のためのチェックパネル

    パネルはルート要素、要素と属性の数、ネストの深さ、名前空間接頭辞、混在コンテンツ、CDATA の有無をまとめ、変換結果を信頼する前に見知らぬ文書を読み解けるようにします。

  6. 06

    すべてブラウザ内で動作

    解析、変換、チェック、コピーはすべてブラウザ内蔵の XML パーサーでこのページ上で行われます。XML はサーバー、CDN、第三者の分析基盤へリクエストで送られることはなく、本番報文や設定サンプルでも安全です。

使い方

ワークフローは 4 ステップにまとまります。XML を貼り付け、形式を選び、チェックパネルを確認し、結果をコピーする。

  1. 01

    左の入力パネルに XML を貼り付けます。解析はすぐに行われ、チェックパネルにルート要素、各種カウント、名前空間接頭辞、混在コンテンツの警告が表示されます。

  2. 02

    下部でターゲットを選びます。JSON、YAML、TOML、JavaScript オブジェクト、PHP 配列。JSON にはインデント幅とキーソートが加わり、切り替えると出力がリアルタイムに更新されます。

  3. 03

    解析オプションを調整します。属性を保持するか破棄するか、属性接頭辞の変更、数値と真偽値のテキストを変換するかそのまま保つか。

  4. 04

    チェックパネルを確認します。混在コンテンツと CDATA は表示されますが変換を妨げません。テキストと構造が重なる箇所を示すので、想定どおりの形か確認できます。

  5. 05

    コピーを押し、出力を IDE、スニペット管理ツール、API クライアント、設定ローダーへ貼り付けて作業を続けます。

詳細

日常的な XML 作業で繰り返し出てくる手間が、既定で滑らかになります。きれいな変換のためだけに外部ツールを連結する必要はありません。

  • 解析はブラウザ同梱の XML エンジンを使うため、整形式のルールが標準準拠の他パーサーの期待と一致します。
  • 繰り返す同名の兄弟要素は常に文書順で配列になり、リスト的な XML が予測しやすい JSON、YAML、TOML にマッピングされます。
  • 属性の接頭辞付けで属性と子要素が区別され、要素内容だけが必要なときはトグル一つで属性を破棄できます。
  • JSON 出力は要素順を保ち、安定した git diff、コードレビュー、JSON Schema 検証のために任意のアルファベット順ソートを選べます。
  • TOML 変換はオブジェクトのルートを要求し、どのパーサーも受け付けない中途半端なファイルを出すのではなく明確に報告します。
  • JavaScript オブジェクトと PHP 配列の出力はネスト、エスケープ、リテラルを保つため、結果をテストデータ、設定、サンプルへそのまま落とし込めます。
  • チェックパネルがルート要素、各種カウント、深さ、名前空間接頭辞を一覧化し、不慣れな XML ファイルを数秒で読めるようにします。
  • すべてブラウザ内で動作し SaaS バックエンドが不要なので、機内、VPN 限定のネットワーク、企業プロキシの背後でも動き続けます。

活用シーン

元が XML であれば、次のような日常作業から手作業のコピペやスクショ説明が一層減ります。

  1. SOAP レスポンスを JSON にする

    SOAP やレガシー XML API のレスポンスを貼り付けて JSON として読み、フィールドをモダンなクライアント、テストデータ、TypeScript の型へ、山括弧を手で追わずにマッピングします。

  2. RSS と Atom フィードをデータとして読む

    フィードを JSON や YAML に変換して項目のタイトル、リンク、日付を確認し、構造化された結果をスクリプト、静的サイトジェネレーター、コンテンツパイプラインへ渡します。

  3. XML 設定を YAML や TOML へ移行

    web.xml、Spring の XML コンテキスト、Maven の pom.xml から離れますか。まず YAML や TOML の出力を見てから手で仕上げれば、ツリー全体を打ち直さずに済みます。

  4. SVG の構造を調べる

    SVG を JSON に変換してグループ、パス、属性をプログラムでたどったり、完全な XML DOM ライブラリなしで特定の属性値を取り出したりします。

  5. サンプル報文からテストデータを作る

    バックエンドや取引先は XML のサンプルをよく共有します。それを JSON や JS オブジェクトに変換し、フロントの Jest、Vitest、Storybook テストで同じデータ形を使えます。

  6. XML から PHP 設定を生成

    レガシーな XML 設定ファイルを <?php return [...]; 配列に変換し、ネストとエスケープを保ったまま Laravel や WordPress プロジェクトへそのまま落とし込みます。

  7. 2 つの XML 文書を比較

    両方のファイルを JSON に変換してから構造化された差分を取り、報文や設定の 2 つの版でどの要素、属性、値が変わったかを正確に把握します。

  8. XML 構造を教える・文書化する

    ネストした XML を JSON や YAML に変換し、記事、講義資料、オンボーディング資料で例文書を読みやすく示します。深い山括弧のインデントは不要です。

関連情報

手元の源が YAML の場合、たとえば Kubernetes マニフェスト、Helm の values ファイル、CI ワークフローを JSON、TOML、XML、JavaScript オブジェクトリテラル、PHP 配列へ進めたいときは、YAML コンバーター を使います。XML 自体に先に手入れが要るとき、たとえば圧縮された報文の整形、深いノードの折りたたみ、変換を信頼する前の整形式確認には、XML フォーマッター に渡してください。インデント、圧縮、検証を行い、行・列のエラー表示が付きます。すでに JSON があり、それを YAML、XML、CSV、TOML、JavaScript オブジェクト、PHP 配列へ移したいときは、JSON コンバーター でその方向に変換でき、形式別のオプションも備わっているので、各ターゲットを手で直すのではなく単一の情報源を保てます。

使い方のヒント

XML は要素、属性、テキストの三か所に同時に情報を持つため、きれいな変換はそれぞれをどうマッピングするか決めることにかかっています。小さな習慣で結果がどのプロジェクトでも予測しやすくなります。

  • まず属性が重要かを決めます。データを担うなら分かりやすい接頭辞で残し、要素内容だけが必要なら破棄します。
  • XML に識別子、版番号、先頭ゼロのコード、文字列のままにしたい電話番号が含まれる場合は、値の型変換を無効にします。
  • 混在コンテンツ、つまり子要素と並ぶテキストに注意します。#text フィールドにまとまり、望む形でないことが多いので、そのテキストが意味を持つなら元の構造を見直します。
  • 要素の単独出現はオブジェクト、2 回以上で配列になることを覚えておきます。リストが 1 件のこともあるなら、下流で両方の形に対応します。
  • XML を JSON に変換したら、結果を前版との JSON 差分にかけ、本番に届く前に静かに変わったフィールドを見つけます。
  • XML のコメントと処理命令は変換時に破棄されます。残す必要があるものは実際の要素か外部文書に昇格させます。
  • 名前空間はキー上のリテラル接頭辞として残ります（例：soap:Body）。下流のコードが接頭辞付きか、剥がしたローカル名かを期待するか判断します。
  • 非常に大きな文書では、まず代表的な一部でオプションを検証し、形が正しいと分かってから全体を変換します。

制限事項

このツールが何をしないかを知っておくと、完全な XML IDE、スキーマバリデーター、変換エンジンとして使おうとせずに済みます。

  • スキーマ検証は行いません。DTD、XML Schema（XSD）、RELAX NG のルールは範囲外で、整形式は有効と同義ではありません。
  • XSLT や XPath は行いません。構造を他形式へマッピングするだけで、スタイルシート変換やパス式の評価はしません。
  • XML のコメント、処理命令、宣言は出力に保持されません。マッピングされるのは要素、属性、テキストだけです。
  • 混在コンテンツ（テキストと子要素が交錯）は常にきれいにはマッピングできません。テキストは #text フィールドに集められ、テキストと要素の間の順序は保持されません。
  • 外部エンティティ、DOCTYPE のインクルード、名前空間 URL は解決しません。すべてローカルテキストとして扱い取得しないため、エンティティ展開のリスクも避けられます。
  • 往復は保証されません。XML を JSON にして戻しても、いくつかの XML 構造には直接対応する JSON がないため、元の文書をバイト単位で再現するとは限りません。
  • 非常に大きなファイル（数 MB）はブラウザを遅くすることがありますが、処理はローカルのままで、切り詰めもアップロードもされません。

よくある質問

よくある質問は属性の扱い、配列、値の型、名前空間、データがブラウザの外に出るかどうかを扱います。

属性はどう表現されますか？

既定では各属性が @ 接頭辞（設定可能）付きのキーになり、子要素名と衝突しません。接頭辞を変更したり、要素内容だけが必要なときは属性を完全に無効化できます。要素が属性とテキストの両方を持つ場合、テキストは #text キーに格納されます。

なぜ繰り返す要素が配列になったのですか？

同じ親の下に同名の要素が複数あると、値は文書順で配列にまとまります。これが JSON、YAML、TOML で兄弟要素を無損失に表す唯一の方法です。単独出現はオブジェクトのままなので、1 件のこともあるリストは両方の形になり得ます。下流で両対応してください。

なぜ数値が文字列のままなのですか？

値の型変換は厳密に往復できるテキストだけを変換するため、「007」「1.0」、電話番号、JavaScript の安全範囲を超える整数はデータを失わないよう文字列のまま残ります。「数値・真偽値を解析」を無効にすると全ての値を文字列として扱い、識別子やコードに最も安全です。

名前空間はどうなりますか？

名前空間接頭辞はキーにそのまま残るため、soap:Body はキー「soap:Body」になります。名前空間 URL の剥離や解決は行いません。チェックパネルが見つかった接頭辞を一覧表示するので、下流コードがそれを期待するか判断できます。

なぜ TOML 変換でルートはオブジェクトでなければと出るのですか？

TOML はトップレベルにテーブルを要求します。コンバーターは常にルート要素名で出力を包むため、これは通常は変わった入力でのみ現れます。出た場合は JSON 出力で形を確認してから TOML に変換できます。

コメントや CDATA は保持されますか？

コメント、処理命令、XML 宣言は破棄され、マッピングされるのは要素、属性、テキストだけです。CDATA セクションは通常のテキストとして読み込まれ、CDATA があるときはチェックパネルが知らせるので驚きはありません。

結果を XML に戻せますか？

このツールは XML を起点に変換します。逆方向には、JSON コンバーターと YAML コンバーターが XML を出力できます。いくつかの XML 構造には直接対応する JSON がないため、往復はバイト単位で同一になるとは限りません。

貼り付けたデータはアップロードされますか？

いいえ。解析、変換、チェック、コピーはすべてブラウザ内蔵の XML パーサーで行われます。あなたの XML をこのページからサーバー、CDN、分析基盤へ運ぶリクエストはなく、本番報文や機密サンプルデータでも安全です。

関連ツール

データ作業を続けましょう。逆方向に変換したり、XML を整形・検証したり、次の工程のために JSON を組み替えたり。下のツールが一連のワークフローにつながります。