XML→JSON変換

XML形式のデータをJSONに変換します。レガシーなXML APIのレスポンスやSOAP連携、RSS/Atomフィードなどの中身を、属性は@attributes・テキストは#text・繰り返し要素は配列という規約でJSON化し、ブラウザ上だけで完結して確認できます。

XMLをJSONへ変換する

レガシーなXML APIやSOAP連携、RSS/Atomフィードの中身を、扱い慣れたJSONの形で見たいことがあります。このツールはXMLを貼り付けるだけでJSONへ変換し、ブラウザの中だけで処理を終えます。貼り付けたデータが外部へ送られることはありません。

**変換に規約が必要なのは、XMLとJSONでデータの持ち方そのものが違うからです。** XMLは属性とテキストを区別し、同じ名前の要素を何度でも並べられますが、JSONにはそのどれもありません。そこで属性は `@attributes`、要素が持つ文字列は `#text`、繰り返し現れる要素は配列という規約に置き換えます。**ここで避けられないのが、繰り返し要素がたまたま1件だけだったときの曖昧さです。** 元のXMLでは「1件の繰り返し」でも、JSONにすると単一の値に見えてしまうため、受け取る側のコードは要素数1と複数の両方を想定して書くのが安全です。

使い方

  1. XMLを貼り付ける SOAPのレスポンスでもRSSフィードでも、そのまま貼れます。
  2. 変換結果を確認する **属性は `@attributes`、テキストは `#text` というキーに収まります。**
  3. 構造を見比べる 元のXMLと並べて、どの要素がどのキーに対応したかを確かめられます。
  4. コピーまたはダウンロードする そのままコードへ貼るか、ファイルとして保存できます。

使いこなすためのヒント

  • 属性を持つ要素は `@attributes` キーの中にオブジェクトとしてまとめられ、要素本来のテキストや子要素とは区別されます。
  • 属性と子要素・テキストが混在する要素では、テキスト部分が `#text` キーに格納されるので、属性値と取り違えることがありません。
  • 同じ名前の兄弟要素が複数回登場すると自動的に配列にまとめられます。`` が3つあれば3要素の配列になり、1つだけなら単一のオブジェクトのままです。
  • 属性もテキストも子要素も持たない空要素(例: ``)は `null` に変換されます。
  • `xmlns` などの名前空間プレフィックスは分離せず、`ns:tag` のような要素名としてそのままキーに使われます。

活用シーン

XML APIをJSON前提のコードに繋ぐ

受け取る側がJSONしか扱えない場合に、変換後の形を先に確かめられます。

RSS/Atomフィードを解析する

フィードの項目をJSONにすると、そのままスクリプトで回しやすくなります。

SOAPレスポンスの中身を読む

**入れ子と名前空間で読みにくいSOAPも、JSONにすると階層が追いやすくなります。**

テスト用のフィクスチャを作る

実際のXMLレスポンスからJSONのモックを起こせます。

変換規約の用語

@attributes
**XMLの属性を収めるキーです。** JSONには属性という概念が無いため、専用のキーに逃がしています。
#text
要素が直接持つ文字列を収めるキーです。属性と子要素の両方がある要素で必要になります。
繰り返し要素
同じ名前で複数回現れる要素です。**JSONでは配列になりますが、1件だけの場合は配列にならず単一の値として現れます。**
名前空間接頭辞
`soap:Body` の `soap:` の部分です。JSONではキー名の一部としてそのまま残ります。
混在内容
テキストと子要素が同じ要素の中に混ざっている状態です。**JSONには対応する構造が無く、変換で情報が落ちやすい箇所です。**
ルート要素
XMLの最上位にある唯一の要素です。JSONでは最も外側のキーになります。

よくある質問

各要素の属性は `@attributes` というキーの中にオブジェクトとしてまとめられます。例えば `` は `{"@attributes": {"category": "fiction"}, ...}` のように変換され、要素本来の値(テキストや子要素)とは別の場所に格納されるため混同しません。

同じ親の下に同名の兄弟要素が複数存在する場合、自動的に配列としてまとめられます。例えば `` タグが2つあれば、親要素の `book` キーの値が2要素の配列になります。1つしかない場合は配列にせず単一のオブジェクトのままです。

最も多い原因は終了タグの記述漏れや対応関係のズレ(開始タグと異なる名前で閉じている等)です。またXMLはルート要素が1つだけである必要があるため、`......` のようにトップレベルに複数の要素を並べて貼り付けた場合もエラーになります。

本ツールはXML→JSONの一方向のみに対応しています。JSON自体の整形やXMLの整形・検証を行いたい場合は、サイト内のJSONフォーマッター・XMLフォーマッターなど他のツールをご利用ください。

名前空間プレフィックスは分離せず、`ns:tag` のような形のままキー名として扱います。名前空間の解決(プレフィックスとURIの対応付け)までは行わないため、複雑な名前空間を使うXMLでは意図した構造にならない場合があります。
ツールくん

余談ですが ― XMLとJSONの間に「唯一の正解」がない理由

XMLとJSONの間には、CSVとJSONのような単純な行→オブジェクトの対応とは異なり、唯一絶対の変換規約が存在しません。XMLには属性・テキストノード・子要素という3種類の情報が混在できるのに対し、JSONにはキーと値の単純な対応関係しかないため、変換時に必ず何らかの取り決めが必要になります。属性をどう表現するか、テキストと子要素が同居する場合にどちらを優先するかといった点で、xml2json・xml-js・org.jsonなど主要な実装ごとに異なる規約が採用されてきました。

それでもなお開発者がXMLを扱う場面は少なくありません。SOAP形式のWeb APIや、金融・行政・医療分野の古くからのシステム間連携、RSS/Atomフィード、Androidのレイアウトファイルなど、XMLが標準フォーマットとして今も現役の領域は多岐にわたります。こうしたレガシーな仕組みから取得したデータを、モダンなJSON専用のツールチェーン(jqでの加工やJavaScriptでのオブジェクト操作など)に載せたいというニーズは根強く残っています。

本ツールが採用した `@attributes`/`#text` という規約は、記号を多用する徹底した記法までは踏み込まず、実務でよく使われるシンプルな規約を選んでいます。属性を持たない葉要素はテキストをそのまま値にするため、単純な設定値やRSSのタイトルのような一般的なケースでは扱いやすいJSONになる一方、属性が絡む要素だけ明示的に区別されるため、変換結果を見れば元がどの値だったのか一目で分かるようにしています。