メインコンテンツへ移動
ToolsByUs

JSONをXMLに変換

「JSONをXMLに変換」は、ドキュメントをブラウザ内で変換します。名前が属性プレフィックスで始まるメンバーはXML属性になり、配列はラッパー要素を足すのではなくメンバー名を繰り返します。XMLの正当な名前ではないJSONキーは、黙って壊すのではなく、元の名前をname属性に残したまま書き換えます。

端末内で処理
インデント
JSON
0 B1 行行 1、列 1
XML読み取り専用
0 B1 行

JSONをXMLに変換はどう動きますか？

難しい方向は、たいていXMLからJSONへの変換です。XMLのほうが構造が多いからです。逆方向は決めることが少ないのですが、うち3つは土台を支える決断で、どれか1つでも間違えると、整形式のXMLですらない出力になります。

JSONのキーはXMLの名前にはならない

JSONのキーは何でもあり得ます。2024 total、user.name、""、絵文字。XMLの要素名は、数字で始められず、空白を含めることも、空であることもできません。典型的な対処はアンダースコアへの置き換えですが、それではキーを黙って壊します。このツールでも名前は同じ方法で修復しますが、元の名前はname属性に書き込みます。ドキュメントは整形式のまま、何も失われません。修復したキーの数は、埋もれることなく報告されます。

ルートが配列だとルート要素が2つできてしまう

XMLドキュメントのルート要素は、ちょうど1つでなければなりません。これはスタイルのルールではなく、ドキュメントをドキュメントたらしめているものです。トップレベルのJSON配列の要素をトップレベルに書き出すと、ルートが要素の数だけでき、すべてのXMLパーサーが拒否します。そこで、配列のルートはラップし、その要素はアイテム名を取ります。

メンバーである配列は話が違います。メンバー自身の要素名を繰り返します。XMLがリストを表現する方法がそれだからです。JSONにコンテナ要素がなかった限り、コンテナ要素は作りません。おかげで、出力を「XMLをJSONに変換」に通して戻すと、force-arrayリストで同じ要素が再現されます。

エスケープは省略できない

テキストの中の&、<、>、さらに属性値の中の"とリテラルの改行は、すべてエスケープしなければ出力は不正な形式になります。見落とされるのは属性の中の改行です。&#10;と書かない限り、XMLパーサーは改行を空白に正規化するため、値は戻ってきたときに黙って変わっています。

XMLは大きくなる。それがこの変換の対価

要素名は、すべて2回書かれます。サイズの差は統計ストリップに表示され、代償が見えるようにしてあります。それで買えるのは、属性、名前空間、コメント、処理命令、スキーマ検証です。どれもJSONにはなく、どれかひとつが、あなたが変換している理由かもしれません。

JSON

{
  "@id": "1",
  "line": ["a", "b"],
  "note": null
}

XML

<?xml version="1.0" encoding="UTF-8"?>
<root id="1">
  <line>a</line>
  <line>b</line>
  <note/>
</root>

JSONをXMLに変換が対応するオプションとエッジケースは？

技術リファレンスとオプション
パラメータ型デフォルト動作とエッジケース
ルート名要素名root単一のラッピング要素です。必須です。XMLドキュメントには必ず1つのルートがあり、JSONのトップレベルは名前を提供しないためです。
属性プレフィックス文字列@このプレフィックスで始まるメンバーは属性になります。XML→JSON変換ツールのデフォルトと一致しているため、両方を経由してもドキュメントが保持されます。
テキストキー文字列#text子要素ではなく要素コンテンツとして書き込まれるメンバーです。これにより、要素が属性とテキストの両方を持つことができます。
項目名要素名要素トップレベル配列のアイテムの要素名です。これはメンバー名を借用できないためです。メンバーである配列は、代わりにメンバー名を繰り返します。
インデントスペース2ゼロは1行を出力します。これは通信時に望ましい形式です。要素間の空白は厳密なパーサーにとって意味があり、整形出力はドキュメントを変更します。
XML宣言真偽値on<?xml version="1.0" encoding="UTF-8"?>を出力します。出力が大きなドキュメントに埋め込まれるフラグメントの場合はオフにします。
空要素を自己閉じ真偽値onnullと空のオブジェクトは<a/>になり、<a></a>にはなりません。両者はすべてのXMLパーサーにとって同一です。一部の下流ツールは仕様よりも厳格です。
不正なキー修復元の名前を保持要素名になれないキーは書き換えられ、元のものはname属性に書き込まれます。修復された数は出力の上に報告されます。
エスケープ自動—テキスト内の& < >、属性値内の& < > "と改行です。属性値内のエスケープされていない改行は、読み取り側によってスペースに正規化され、値が変更されます。

よくある質問

子要素ではなく属性を得るにはどうすればよいですか？

メンバー名の先頭に@を付けてください。{"@id": "1"}は、要素のid="1"になります。プレフィックスは設定可能で、「XMLをJSONに変換」のデフォルトも同じ値です。そのため、ドキュメントはXML → JSON → XMLと通しても、同じ形で戻ってきます。

キーが改名されたのはなぜですか？

XMLの正当な要素名ではないからです。数字で始まっていたか、空白やXMLが許さない文字を含んでいたか、空だったかのいずれかです。要素名は修復され、元のキーはname属性に書き込まれます。失われるものはなく、ドキュメントは整形式のままです。件数は出力の上に表示されるので、起こったことが分かります。

配列の周りにラッパー要素がないのはなぜですか？

XMLは、リストをラップするのではなく、要素の繰り返しで表現するからです。{"line": ["a","b"]}は2つの<line>要素になり、これは慣用的なXMLであり、正しく往復できる形でもあります。<lines><line>…</line></lines>が欲しい場合は、そのネストをJSONに含めてください。{"lines": {"line": ["a","b"]}}とします。

出力をインデントするべきですか？

通信に載せるものには、しないでください。XMLでは要素間の空白に意味があります。厳格なパーサーはインデントをテキストノードとして扱い、混合コンテンツでは実際にドキュメントが変わります。読むためにはインデントし、送るためにはindentをゼロにしてください。空白が常に無意味なJSONとの、本物の違いです。

XSDに対して検証が通るドキュメントを作れますか？

偶然一致する場合を除いて、できません。スキーマは、要素の順序、出現回数、データ型、名前空間を制約しますが、その情報はJSONの中に存在しません。オブジェクトのメンバーには意味のある順序がないので、コンバーターには、スキーマが要求するシーケンスが分かりません。形を得るためにこのツールを使い、その後でスキーマに合わせて順序を整え、名前空間を追加してください。

JSONはアップロードされますか？

いいえ。パースも変換も、すでに開いているタブの中で実行されます。Networkパネルで確認できます。JSONをXMLに変換する理由は、たいてい古いエンタープライズシステムにデータを流し込むためです。そこで扱うペイロードは、知らないサーバーを通ってほしくないものであることがほとんどです。

ToolsByUsチーム · ツールの検証方法