onlinetools.dev

XML ↔ JSON変換

XML ドキュメントと JSON を相互変換。属性も含めて変換

ローカル実行
loading…
このツールについて

レガシーな SOAP レスポンス、RSS フィード、Maven POM を JavaScript や jq、JSON ネイティブな API に渡すために XML を JSON に変換します — 逆方向に、JSON データから XML を生成することもできます。属性は保持されます。属性は "@_name" キーになり、属性と共存するテキストコンテンツは "#text" の下に収まるため、情報が黙って消えることはありません。

2 つのフォーマットは根本的な部分で食い違っており、このコンバーターは標準的で実用的な選択をします。同名の兄弟要素の繰り返しは JSON 配列にまとめられ、数値に見える値は数値になり、名前空間は要素名の一部として運ばれます。典型的なドキュメントであれば、XML → JSON → XML のラウンドトリップで構造と内容が保たれます。

どちらの方向もブラウザ内でローカルに実行されます。請求書のフィードや API レスポンスを、どこかに送られる心配なく貼り付けられます。

よくある質問

なぜ一部の値が文字列ではなく数値として返ってくるのですか?
パーサーは数値のテキストを認識して変換します。これはほとんどのコンシューマーが望む挙動です。先頭にゼロを持つ識別子(商品コード、電話番号)には注意してください — それが重要なデータなら、変換後にクォートし直すか、出力を出発点として扱ってください。
繰り返される要素はどう扱われますか?
同じ名前の兄弟要素が 2 つ以上あると、そのキーの下の JSON 配列になります。1 回だけの出現はただのオブジェクトのままです — この非対称性はマッピングに固有のものなので、JSON を消費するコードは両方の形を許容するか、先に正規化してください。
@_ と #text のキーは何を意味しますか?
@_ は XML の属性だったものを示し、#text は属性と併存する要素のテキストを運びます。同じ規約を JSON → XML 方向に戻せば、元のマークアップが再構築されます。
なぜ JSON → XML はトップレベルの配列を拒否するのですか?
XML ドキュメントにはちょうど 1 つのルート要素が必要で、裸の配列にはそれがありません。配列をオブジェクトで包めば — {"items": {"item": [...]}} — コンバーターは整形式のドキュメントを生成します。
関連ツール