Does JSON to XML Converter work with large files?

Yes, since it runs in your browser, it can handle reasonably large inputs. Performance depends on your device's capabilities.

モバイルデバイスで使用できますか？

Yes, this tool works on any device with a modern browser including phones and tablets.

Are my JSON documents uploaded to a server?

No. Conversion runs entirely in your browser, pasted JSON never leaves your device. Safe for converting sensitive API responses or configuration data to XML without sharing it externally.

このツールはオフラインで動作しますか？

Yes, once the page has loaded, the tool works entirely in your browser without needing an internet connection. All processing is done locally with JavaScript.

Is there a character or line limit?

There is no hard limit. The tool can handle files with tens of thousands of lines, though very large inputs may slow down depending on your browser and device.

JSONからXMLへのコンバータ

JSONデータをXML形式に変換します。左側にJSONを貼り付けて、整形されたXML出力を取得します。

ルートタグ: インデント:

入力JSON

XML出力

JSONとXML

XML(Extensible Markup Language)は1998年2月10日に W3C 勧告として標準化されました、Tim Bray、Jean Paoli、C.M. Sperberg-McQueen が編集した W3C XML 1.0 仕様です。XML は SGML(古い Standard Generalised Markup Language、ISO 8879:1986)から最も複雑な機能を取り除き、web が現実的に使えるものを生み出すことで派生しました。21世紀の最初の十年間、XML はあらゆる構造化データ交換の前提形式でした、SOAP web サービス、RSS フィード(RSS 2.0、Dave Winer、2002)、Atom(RFC 4287、2005)、Microsoft Office の Open XML フォーマット(.docx/.xlsx/.pptx、ISO/IEC 29500:2008)、Android XML レイアウト、Java プロパティファイル、ほぼあらゆるサーバーフレームワークの設定。XML の強みは名前空間、属性、混合コンテンツ(テキストと子要素が交互する)、豊富なスキーマエコシステム(DTD、XML Schema 1.1、Relax NG)です。その弱みは冗長性です、各値が開きタグと閉じタグを運びます。

JSON(JavaScript Object Notation)は2001年に Douglas Crockford によって仕様化されました、json.org サイトと彼の元のエッセイ「JSON: The Fat-Free Alternative to XML」。JSON は意図的に JavaScript オブジェクトリテラル構文のサブセットです、オブジェクト、配列、文字列、数値、true/false/null。RFC 4627 として2006年7月に標準化、RFC 7159(2014年3月)、RFC 8259(2017年12月、現在の STD 90 標準、ECMA-404 として ECMA でも公開)で改訂されました。XML を犠牲にした JSON の web API 征服はおおよそ2008-2014年に起こりました、タイミングはシングルページアプリケーションとモバイル API 時代の台頭と一致しました。今日、ほぼすべての公開 API は JSON で自己ドキュメント化します、XML は主にエンタープライズ統合、ドキュメントフォーマット、設定ファイル、フィードフォーマットで生き延びます。両方のフォーマットは異なるものをよくエンコードするので活発に使用されています、JSON はシンプルな型と予測可能な形を持つ構造化データに適しており、XML は混合コンテンツ、属性、名前空間、厳密なスキーマを持つドキュメントに適しています。

JSON を XML に変換する必要があるとき

JSON 専用クライアントから SOAP web サービスを呼び出す。 SOAP は設計上 XML です(SOAP エンベロープ、WSDL サービス記述、XSD スキーマ)。JSON 形式のデータがあり SOAP リクエストボディを構築する必要がある場合、JSON-to-XML が橋渡しです。現代のマイクロサービスがレガシー SOAP エンドポイント(銀行、政府、保険、医療交換システム)と話す必要がある場合のエンタープライズ統合で一般的です。
JSON データから Office Open XML ドキュメントを生成。 .docx、.xlsx、.pptx フォーマットは XML ファイルの ZIP アーカイブです。JSON で支えられたデータからプログラム的に Office ドキュメントを生成または変更するには、JSON-to-XML 変換がアプリケーションのデータ層とドキュメント生成ライブラリの境界で発生します。
JSON コンテンツから RSS または Atom フィードを生成。 ブログ、ニュースサイト、ポッドキャストプラットフォームはシンジケーションのために RSS/Atom フィードを発行します。CMS が JSON で記事を保存する場合、フィード生成ステップは JSON エントリをフィードリーダーエコシステムが期待する XML フォーマットに変換します。
レガシーアプリケーション用の XML 設定ファイル生成。 多くの古いエンタープライズアプリケーション(Java アプリケーションサーバー、.NET 設定ファイル、Spring XML アプリケーションコンテキスト)は XML で設定を消費します。現代のインフラストラクチャ-as-code ツールは通常 YAML または JSON で動作するので、JSON-to-XML 変換がデプロイメントパイプラインに挟まります。
XSLT 変換へのフィード。 XSLT(XSL Transformations、Michael Kay の仕様、W3C 勧告)は XML 用の標準変換言語で、XML 入力を消費します。データが JSON から始まり、レポーティングエンジンが XSLT ベースの場合、変換は入力境界で発生します。
Android リソースファイル生成。 Android の strings.xml、colors.xml、dimens.xml、レイアウトファイルは XML です。編集の容易さのために JSON で文字列を保存するローカリゼーションパイプラインは、ビルド時に XML に変換します。

変換マッピング、情報が生き残るところと失われるところ

JSON と XML は異なる構造プリミティブを持つので、あらゆる変換は選択をしなければなりません。ほとんどの変換ツール(これを含む)が従う標準 JSON-to-XML マッピングは:

JSON オブジェクトは XML 要素になります。各キーはタグ名としてキーを持つ子要素になります。{"name": "Alice"} は <name>Alice</name> になります。
JSON 配列は繰り返される子要素になります。{"items": [1, 2, 3]} は <items> ラッパー内の3つの子 <item>1</item><item>2</item><item>3</item> になります。(異なる変換ツールは配列要素名に異なる慣習を使います、一部は親名の単数形を使い、他は固定の <item> を使います。)
文字列、数値、ブール値は要素のテキストコンテンツになります。型情報は保持されません、XML はすべてのテキストを文字データとして扱うので、XML → parse → re-serialize to JSON のラウンドトリップは、消費者が型推論を適用しない限り、引用された文字列として数値を出力します。
null は空の自己閉じ要素になります。{"middle_name": null} は <middle_name/> になります。一部の変換ツールは代わりに xsi:nil="true" を使用します。
ルート要素はすべてをラップします。JSON は最上位の配列やスカラーを許可しますが、XML は正確に1つのルート要素を要求します。<root> ラッパー(ここで設定可能)が慣習的な解決策です。

変換で失われる情報:JSON の数値と文字列の区別、JSON の true/false と「true」/「false」文字列の区別、JSON の配列対オブジェクト区別(配列が繰り返される要素になると、ソースが1要素配列か単一値かを XML だけから知ることはできない)。シンプルな変換ツールが使用しないが潜在的に得られる情報:XML 属性(JSON オブジェクトはキーを子要素ではなく属性にマップする可能性がある)、XML 名前空間(JSON には等価物がない)、CDATA セクション(XML 特殊文字を含むテキストを埋め込むため)。型情報を保持するラウンドトリップ安全な JSON-to-XML 変換には、BadgerFish 慣習または Parker 慣習が JSON 型を名前空間付き XML 属性としてエンコードします、このツールはラウンドトリップ安全な形式ではなくシンプルでより読みやすい形式を生成します。

JSON キーが持たない XML タグ名制約

JSON オブジェクトキーは任意の文字列です、任意の Unicode が許可されます。XML 要素名はずっと制限されています、文字またはアンダースコアで始まらなければなりません(数字、ハイフン、ドットではない)、文字、数字、ハイフン、アンダースコア、ドットを含むことができます(スペースなし、ほとんどの句読点なし)、ケース敏感、任意のケースの組み合わせで予約プレフィックス xml で始まることはできません。スペースを含む JSON キー("first name": "Alice")、数字で始まるキー("3rd_choice")、または特殊文字を持つキー("@type"、"$value")は XML 要素名として直接使用できません。ほとんどの変換ツール(これを含む)は無効な文字を静かに歪めます、スペースをアンダースコアに置き換え、数字で始まるキーをアンダースコアでプレフィックス、ほとんどの句読点を削除します。ラウンドトリップで注意してください、XML-非安全キーを持つ JSON ドキュメントは XML を介して同一にラウンドトリップしません。

2026年に XML がまだ君臨する場所

XML は2026年に後退しているわけではありません、特定のニッチに落ち着いただけです。ドキュメントフォーマット: Office Open XML(Microsoft Office)、OpenDocument(LibreOffice)、EPUB ebooks、SVG(W3C 勧告 2001年9月4日)、MathML、XHTML。設定: Java アプリケーションサーバー、Spring XML コンテキスト、Maven POM、Android XML リソース、.NET app.config と web.config ファイル。フィード: RSS 2.0、Atom 1.0(RFC 4287)、ポッドキャストフィード(iTunes RSS 拡張)。医療と政府交換: HL7 v3、FHIR(現在は代替として JSON を提案するが XML 形式は依然として広く使われる)、DocBook、NewsML、ISO 20022 銀行業務。標準団体: ほぼすべての IETF と W3C 仕様の例は XML を使用します。XML の冗長性はこれらの分野では機能です、自己記述的、スキーマに対する検証は確立されている、XML 方言間の XSLT 変換は成熟したツールキットです。フォーマットはどこにも行きません、JSON-to-XML 変換は現代のデータツールとこれらの確立された XML ネイティブシステムの間の橋です。

プライバシー、ブラウザ内のみで変換

変換ツールに貼り付けられた JSON はしばしば実際の本番データを含みます、ユーザー識別子を含む API レスポンス、ビジネス分類を明らかにする内部エンティティ ID、エンドポイント URL と機能フラグを含む設定値、トークン、まだ公開されていないドラフトコンテンツ。サーバー側変換ツールは各入力のコピーをログに取ります。この変換ツールはブラウザ組み込みの JSON.parse() で JSON を解析し、JavaScript で結果のオブジェクトツリーを歩き、文字列として XML を出力します、すべてあなたのブラウザタブ内で。Convert をクリックする間に DevTools の Network タブを確認(リクエストは出ません)するか、読み込み後にページをオフライン(機内モード)にしても変換ツールはまだ動作します。本番 API レスポンス、内部設定、ドラフトコンテンツ、または見知らぬ人のハードドライブにコピーされたくない JSON に安全です。

よくある質問

JSON配列はどのように変換されますか?

JSON配列は、<item>タグでラップされた繰り返しXML要素に変換されます。例えば、[1, 2, 3]は親内の3つの<item>要素になります。

大きな JSON ファイルで動作しますか?

はい、すべてがブラウザで実行されるので、実用的な上限はデバイスの利用可能なメモリです。何万行もの JSON は現代のラップトップで1秒未満で変換されます。非常に大きな入力(数 MB)はパーサーがツリーを歩く間にタブを短時間フリーズさせるかもしれません。大規模データセットのバッチ変換には、サーバー側変換ツール(Node の xml2js、Python の dicttoxml)を使用するスクリプトがより適しています。

JSON はサーバーにアップロードされますか?

いいえ。変換は完全にブラウザで実行されます、貼り付けられた JSON はデバイスを離れません。Convert をクリックする間に DevTools の Network タブを確認(リクエストは出ません)するか、読み込み後にページをオフライン(機内モード)にしてください。本番 API レスポンス、内部設定、または外部に共有したくないデータに安全です。

特定の JSON キーを子要素ではなく XML 属性にできますか?

この変換ツールはすべての JSON キーを属性ではなく子要素として出力します。一部の変換ツールが使う慣習、@ でプレフィックスされたキーが属性になる("@id": 5 → 親の id="5")、は BadgerFish 慣習です。下流の消費者が特定の値を属性として要求する場合、慣習を理解するカスタム変換ツールが必要、または結果の XML を手動で編集する必要があります。

スペースや無効な XML 文字を含む JSON キーはどうなりますか?

XML 要素名は JSON キーよりも厳密なルールを持ちます、文字またはアンダースコアで始まらなければならず、スペースを含むことができず、ほとんどの句読点を禁止します。無効な文字を持つキーはサニタイズされます、スペースはアンダースコアに、先頭の数字はアンダースコアプレフィックスを取得、特殊文字は削除されます。これは JSON → XML → JSON のラウンドトリップが元のキー名を正確には生成しないかもしれないことを意味します。データが珍しいキーを持つ場合、歪みが重要なものを壊さなかったかを出力で検査してください。