データ

XML コンバーター

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

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

概要

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

  1. 01

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

    XML を JSON、YAML、TOML、JavaScript オブジェクトリテラル、PHP 配列へ。JSON と YAML はインデント幅を選べ、キーのアルファベット順ソートはどの変換先にも効きます。TOML はルート要素の下にテーブルを重ね、@name のようなキーには自動で引用符を付けるので、そのまま解析できる出力になります。JS オブジェクトリテラルは引用符付きキーと適切なエスケープを保ち、PHP 配列は完全な <?php return [...]; ファイルを出力します。

  2. 02

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

    各要素はタグ名がそのままキーになり、テキスト内容が値になり、繰り返し現れる同名の兄弟要素は文書順で配列にまとまります。下流のコードに 2 つの形を扱わせたくないなら「常に配列にする」をオンにしてください。ルート要素名はトップレベルのキーとして保持され、出力が元のツリーを反映します。

  3. 03

    属性を自分で制御

    属性は設定可能な接頭辞（既定は @）付きのキーになるので、子要素名と衝突しません。接頭辞を空にして実際に同名の子要素とぶつかった場合も、2 つの値が黙って 1 つの配列に混ざるのではなく、チェックパネルがそのキーを名指しします。要素内容だけが必要なときは属性を完全に無効化でき、要素が属性とテキストの両方を持つ場合はテキストが #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 と YAML にはインデント幅が加わり、キーソートはどの変換先にも効きます。切り替えると出力がリアルタイムに更新されます。

  3. 03

    解析オプションを調整します。属性を保持するか破棄するか、属性接頭辞の変更、名前空間接頭辞を外すか、子要素を常に配列にするか、数値と真偽値のテキストを変換するかそのまま保つか。

  4. 04

    チェックパネルを確認します。混在コンテンツ、CDATA、破棄したコメント、キーの衝突は表示されますが変換を妨げません。変換先に収まらないものが文書のどこにあるかを示すので、想定どおりの形か確認できます。

  5. 05

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

詳細

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

  • 解析はブラウザ同梱の XML エンジンを使うため、整形式のルールが標準準拠の他パーサーの期待と一致します。
  • 繰り返す同名の兄弟要素は文書順で配列になり、「常に配列にする」をオンにすれば 1 件だけのリストも配列になるので、リスト的な XML が予測しやすい JSON、YAML、TOML にマッピングされます。
  • 属性の接頭辞付けで属性と子要素が区別され、要素内容だけが必要ならトグル一つで属性を破棄でき、もう一つのトグルですべてのキーから名前空間接頭辞を外せます。
  • どの変換先も要素順を保ち、安定した git diff、コードレビュー、JSON Schema 検証のために任意のアルファベット順ソートを選べます。
  • TOML に変換するとき、@name・xml:lang・#text のように 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 フィールドにまとまり、望む形でないことが多いので、そのテキストが意味を持つなら元の構造を見直します。
  • 1 回だけ現れる要素は配列に包まれず、2 回以上で初めて配列になります。つまり同じフィールドが単体の値としても一覧としても届きます。リストが 1 件のこともあるなら、下流で両方の形に対応するより「常に配列にする」をオンにするほうが簡単です。
  • XML を JSON に変換したら、結果を前版との JSON 差分にかけ、本番に届く前に静かに変わったフィールドを見つけます。
  • XML のコメントと処理命令は変換時に破棄され、チェックパネルが件数を数えます。残す必要があるものは実際の要素か外部文書に昇格させます。
  • 接頭辞を外す設定にしなければ、名前空間はキー上のリテラル接頭辞として残ります（例：soap:Body）。2 つの形は互換ではないので、出力をコピーする前に下流のコードがどちらを期待するか確かめます。
  • 非常に大きな文書では、まず代表的な一部でオプションを検証し、形が正しいと分かってから全体を変換します。

制限事項

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

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

よくある質問

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

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

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

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

同じ親の下に同名の要素が複数あると、値は文書順で配列にまとまります。これが JSON、YAML、TOML で兄弟要素を無損失に表す唯一の方法です。1 回だけの出現は配列に包まれないため、1 件のこともあるリストはそのままだと両方の形になり得ます。「常に配列にする」をオンにすれば、文書に何個書かれていても子要素は必ず配列になります。

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

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

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

既定ではキーにそのまま残るため、soap:Body はキー「soap:Body」になります。「名前空間接頭辞を外す」をオンにすると同じ要素は「Body」になり、接頭辞を束ねていた xmlns 宣言も一緒に消えます。どちらの場合も名前空間 URL は解決せず、チェックパネルは見つかった接頭辞を必ず一覧表示します。

TOML 出力はどんな形になりますか？

ルート要素がトップレベルのテーブルになり、入れ子の要素は入れ子のテーブルに、繰り返す兄弟要素は配列になります。TOML が裸で書けないキー——@name のような属性キー、名前空間付きの xml:lang、#text フィールド——には自動で引用符が付くので、出力はそのまま解析できます。TOML には null も日時型もありませんが、XML 文書からはどちらも生まれません。空要素は空文字列になります。

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

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

結果を XML に戻せますか？

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

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

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

関連ツール

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