無料XMLかJSONコンバーター
XMLをJSONに即時に変換します。属性、ネストされた要素、テキストノードに対応します。完全にブラウザ内で動作します。
XMLとは何ですか？
XML（Extensible Markup Language）は、データの保存と転送のためのフォーマットです。カスタムタグを使用してデータ構造を記述し、人間が読みやすく、広くサポートされています。JSONと異なり、XMLは要素に属性を含めることができます。
なぜXMLをJSONに変換するのか？
- より小さいファイルサイズ · JSONはXMLよりコンパクトです。
- Web API · ほとんどの現代のWebサービスはXMLではなくJSONを使用します。
- 解析が簡単 · JSONはJavaScriptオブジェクトに直接マッピングされます。
- レガシーシステムとの統合 · 古いXMLデータを現代のJSONフォーマットに変換します。
よくある質問
XMLの属性はどのように処理されますか？
XMLの属性は@プレフィックス付きのJSONプロパティに変換されます（例：@id、@href）。これにより、JSON構造内で属性情報が保持されます。
ネームスペースについてはどうですか？
ネームスペースは出力に保持されます。プレフィックスは要素名に含められます（例：「ns:element」）。
JSONをXMLに逆変換できますか？
このツールはXMLをJSONに変換します。逆変換には、JSONかXMLコンバーターをご利用いただけます。
2つのフォーマット、3つの十年を隔てて
XML 1.0は1998年2月10日にW3C勧告となった。最初の編集者はTim Bray（Textuality / Netscape）、Jean Paoli（Microsoft）、C. M. Sperberg-McQueen（イリノイ大学シカゴ校）で、ワーキンググループはSun MicrosystemsのJon Bosakが議長を務めた。XMLの系譜はSGML（ISO 8879:1986）にさかのぼる。SGMLは1970年代にIBMのGMLから発展したドキュメントマークアップ標準だ。SGMLは強力だったが難解だった。XMLの設計方針は「SGMLの「ライト」バージョンを設計する」ことで、オプション機能を削減してUnicode、名前空間、属性豊富なドキュメントを維持しながら数千行のコードで実装できるプロファイルに絞り込んだ。
JSON（JavaScript Object Notation）は設計されたのではなく発見された。Douglas CrockfordとChip MorningstarはState Softwareで2001年4月に最初のJSONメッセージを送信し、JavaScriptのオブジェクトリテラル構文からフォーマットを導出した。Crockfordは2002年にjson.orgを登録して1ページの仕様を公開した。このフォーマットは2006年7月にRFC 4627として初めて正式化され、2014年にRFC 7159として改訂され、2017年12月にRFC 8259 / STD 90として安定化した。同年ECMA-InternationalはECMA-404を発行した。JSONの設計意図（Crockfordの回顧録より）：最小限、言語非依存、生成と解析が容易、バージョン番号なし（「バージョン番号はない」）、そして意図的にコメントなし（「人々がコメントを解析ディレクティブの保持に使っているのを見てコメントを削除した」）。
JSONは2000年代後半にRESTがSOAPに取って代わり、XMLHttpRequestがJSON-over-fetchに道を譲る中でウェブAPIを席巻した。2015年までにJSONはほぼすべての公開APIのデフォルトのレスポンス形式になった。XMLは長尾のエンタープライズSOA、ドキュメント形式（Office Open XML、OpenDocument）、標準に縛られたニッチな領域で生き残っている。
XMLとJSONの違い
| XML | JSON | |
|---|---|---|
| 属性 | 第一級（<item id="5"/>） | 属性なし、すべてキーと値のペア |
| 名前空間 | ネイティブ（xmlns:prefix="uri"） | フラットな名前；プレフィックスの衝突はアプリ側の問題 |
| コメント | <!-- … --> | 仕様上なし |
| 混合コンテンツ | ネイティブ（<p>text <b>and</b> markup</p>） | 扱いにくい。配列化または文字列化が必要 |
| スキーマ | DTD、XSD 1.0（2001年）/ 1.1（2012年）、RELAX NG、Schematron | JSON Schema（コミュニティ仕様、ドラフト2020-12） |
| 順序 | 仕様上、要素の順序は有意 | オブジェクトキーの順序は保証されない（実際にはほとんどのパーサーが挿入順序を保持する）。配列は順序付き |
| 数値 | スキーマによって型付けされるまでは文字列 | IEEE 754倍精度；仕様レベルでは整数/浮動小数点の区別なし |
| 冗長さ | 高い（すべての値がタグで囲まれる | 低い）区切り文字のみ |
XML→JSONが根本的にロッシーである理由
XMLからJSONへの標準的なW3C認定マッピングは存在しない。すべてのコンバーターはXMLでは表現できるがJSONにはネイティブな語彙がない問題への答えを発明しなければならない。繰り返し発生する決定事項：
- 属性vs子要素：XMLでは同じデータを両方の方法で表現できる。JSONにはひとつの概念（オブジェクトのキー）しかないため、コンバーターはマーカーを発明しなければならない。一般的な規則：BadgerFishは属性に
@、テキストに$を使用する。Parkerは属性を完全に削除する（ロッシーだが単純）。JsonMLは要素を型タグ付きの配列として表現する（順序と構造を保持）。GData / Newtonsoft / xml2jsは@attributesサブオブジェクトと必要に応じた#textキーを使用する。このコンバーターはGDataスタイルの規則に従う：属性は@attributesの下に、混合コンテンツのテキストは#textの下に、繰り返しの子要素は配列になる。 - 繰り返しの子要素：コンバーターが子要素ごとに1つのキーを作成すると、2つ目の子が1つ目を上書きする。標準的な修正は繰り返しを検出して配列として出力することだ。ただしJSONの形状はデータに依存することになる。
<book>が1つなら文字列になり、2つなら文字列の配列になる。一部のコンシューマーは1つのアイテムでも配列形式を望む。一部のコンバーターは特定の要素名に「常に配列」のトグルを提供している。 - 混合コンテンツ：
<p>Hello <b>world</b>!</p>はテキストと要素を有意な順序で混在させる。JSONは混合型の配列や番兵#textキーなしではそのインターリーブをネイティブに表現できない。多くのコンバーターは要素間の散文を削除する。より保守的なものは複数のテキストノードエントリに分割する。 - 名前空間：
<soap:Envelope xmlns:soap="…">はプレフィックスとバインディングURIの両方を持つ。ほとんどのコンバーターはプレフィックスをJSONキーの一部として保持し（soap:Envelope）バインディングを削除する。コンシューマーが名前空間を解決する必要がない場合は問題ない。 - コメントと処理命令：通常は黙って削除される。JSONにはコメント構文がない。
- CDATAセクション：プレーン文字列に平坦化される。
<![CDATA[…]]>ラッパーは失われる。 - ホワイトスペース：XMLには有意なホワイトスペース用の
xml:space="preserve"がある。JSONには同等のものがない。ほとんどのコンバーターは要素間のホワイトスペースのみのテキストノードをトリムする。
このツールを使う場面
- 最新のJSフロントエンドからのレガシーSOAPサービスの利用。SOAPレスポンスはXMLだ。境界で一度変換することでアプリの残りの部分をJSONで動作させられる。
- RSS / Atomフィードの処理。どちらもXMLフォーマットだ。最新のニュースリーダーとアグリゲーターは通常JSONを必要とする。
- XMLサイトマップ（
sitemap.xml）：JSONに変換することでプログラム的に検査・処理しやすくなる。 - OpenStreetMap OSMデータ。XMLで公開されており、クライアントサイドマッピング用にJSONが頻繁に必要とされる。
- Google Earth KML / GPXファイル。XMLで提供される地理データフォーマット。
- Office Open XMLの内部構造。
.docx、.xlsx、.pptxはZIP圧縮されたXMLファイルだ。展開してJSON形式で構造を検査したい場合、これが変換ステップになる。 - SVGの操作。SVGはXMLだ。JSONに変換することでJavaScriptでツリーを走査・変更してから再シリアライズしやすくなる。
- Maven POM、Antビルドファイル、Spring設定、Androidリソース、Appleのplist、XBRL財務データ、HL7医療記録、MusicXML、NMX法律文書。ダウンストリームのツール向けにJSONが必要になることが多い長尾のXMLフォーマット群。
現代の代替手段
- ネイティブJSON API。アップストリームのサービスがJSONバリアントを提供している場合はそれを使う。SOAPサービスは通常提供しないが、現代のほとんどの同等物は提供している。
- GraphQL。クライアントが型付きスキーマから必要なJSONの形状を正確にリクエストできるクエリ言語。
- Protocol Buffers（Protobuf）、MessagePack、CBOR、Avro。スキーマを持ちXMLもJSONよりもはるかに小さいワイヤーサイズのバイナリシリアライズフォーマット。マイクロサービスメッシュの内部では一般的だが、明示的なデコードライブラリが必要なためブラウザの境界ではほとんど使用されない。
- XMLに留まる。データが真にドキュメント指向（混合コンテンツ、深い型付き構造、重要なスキーマ検証）であれば、XMLの方が適している。JSONの強みはAPI形状のデータだ。ドキュメントの忠実性はその専門領域ではない。
その他の質問
同じXMLが異なるツールで異なるJSONの形状を生成するのはなぜか？
標準的なXML→JSONマッピングが存在しないためだ。各コンバーターは規則（BadgerFish、Parker、JsonML、GDataスタイル）を選び、属性のマーク方法、混合コンテンツの保持方法、繰り返しの子要素の配列化によって結果のJSONの形状が異なる。異なるコンバーターでXMLをラウンドトリップすると異なるJSONになる。異なるコンバーターでJSONをXMLにラウンドトリップすると属性の配置や要素の順序まで変わることがある。相互運用性のためには使用している規則を文書化して一貫して使用すること。
CDATAセクション、コメント、処理命令はどうなるか？
CDATAセクション（<![CDATA[…]]>）はプレーンな文字列コンテンツに平坦化される。ラッパーは消えるが内部のテキストはそのまま保持される。XMLコメント（<!-- … -->）と処理命令（<?xml-stylesheet …?>）は削除される。JSONにはどちらの構文もない。コメントを保持するラウンドトリップの忠実性が必要な場合はXMLのみのラウンドトリップが適切なアプローチだ。
XMLスキーマ（XSD）は変換を経て残るか？
いいえ。XSDはXMLの構造と型を記述する。JSON SchemaはJSONの類似した（別の）標準だ。一部の高度なツールはXSDをJSON Schemaに変換できるが、ロッシーな操作だ。XSDにはJSON Schemaに相当するものがないクリーンな機能がある（混合コンテンツ、代替グループ、派生型）。重要なドキュメント検証にはJSON変換後ではなく元のXMLに対してXSDを実行すること。
なぜJSONはウェブAPIで勝利したのか？
いくつかの理由がある。JSONはJavaScriptオブジェクトに直接マッピングされるため、ブラウザサイドの解析はJSON.parse()の1回の呼び出しだけだ。フォーマットははるかに小さく、閉じタグがなく、名前空間宣言もなく、スキーマのバゲージもない。RESTは2000年代後半にほとんどの公開APIでSOAPに取って代わり、JSONはRESTの自然なペイロードだった。XMLの強み（厳格なスキーマ、名前空間、混合コンテンツ）はドキュメントとレガシーエンタープライズシステムでは重要だが、「ユーザーオブジェクトをください」では滅多に重要ではない。ウェブはシンプルなケースに最適化された。
何かサーバーに送信されるか？
いいえ。XMLはブラウザのネイティブDOMParserによって解析され、JavaScriptで再帰的に走査してJSONを構築する。貼り付けたXMLはページから出ることはない。このツールは読み込まれた後オフラインで動作する。ソースXMLに内部APIエンドポイント、顧客データ、またはどこにもアップロードしたくない独自スキーマが含まれている場合に重要だ。