日本語

開発者ツール · 構文コンバーター

JSON から XML への変換: ルート要素、配列、および無効なタグ名

· 仕組み

json XML データ形式

繰り返される項目の子を持つ 1 つの XML ラッパーに入るルートレス JSON 配列
オリジナル ToolAcre ベクトル イラスト

JSON は、数字で始まるキーまたはスペースを含むキーを持つ裸の配列にすることができますが、XML ではいずれも許可されません。この投稿では、出力を予測できるように、コンバーターがルート、配列、名前に関して行う必要がある決定について説明します。

名前のない配列 — 単一ルートの XML ドキュメントになる必要がある最上位の JSON 配列、および表示されるラッパー要素

JSON は `[1,2]` で始めることができます。 XML を 2 つのピア文書要素で始めることはできません。したがって、ToolAcre は、選択されたルート名でルート配列をラップし、各メンバーを繰り返しの `<item>` 子として書き込みます。ラッパー名と項目名がソースに存在しないため、警告ではその規則に名前が付けられます。

`numbers` を選択すると、2 つの item 要素を含む 1 つの `<numbers>` ドキュメント要素が生成されます。変換は決定的ですが、正規的ではありません。別のシステムでは `<number>` または属性を持つコレクションが必要になる場合があります。ルートを意図的に設定し、その結果を受信者の必要な XML コントラクトと比較します。

XML にはルートが 1 つだけ必要です — すべての変換でルート要素名が作成または要求される理由

XML ドキュメントにはルート要素が 1 つだけ必要です。通常の最上位キーが 1 つだけある JSON オブジェクトは、そのキーを直接使用できます。マルチキー オブジェクト、配列、スカラー、または null には単一の名前が指定されていないため、ユーザーが別の有効な名前を指定しない限り、作成者はそれを `root` で囲みます。

ラッパー ルールはシリアル化の前に実装され、警告として表示されます。これはスキーマによって検出されず、`<root>` が従来のサービスに対して意味を持つとは主張しません。エンベロープの名前付けは統合設計の一部ですが、コンバーターは独自のマッピングの下で​​適切な構造を保証するだけです。

配列には XML に相当するものはありません。項目ごとに要素を繰り返し、スカラーの配列と配列の配列がどのように表現されるかについて説明します。

配列は繰り返し要素になります。ドキュメントルートでは、メンバーはラッパーの下で `<item>` を使用します。オブジェクト内では、`line` の下に格納されている配列は、繰り返される `<line>` 兄弟になります。オブジェクトの配列は、子フィールドを持つ繰り返し要素を作成します。ネストされた配列にはドメイン名がなく、ビルダーによって生成された一般的な構造を継承します。

これにより、後の XML ~ JSON の読み取り後に、1 つの配列メンバーと同じ要素名を持つスカラーとの区別が失われます。 XML は、独立した配列マーカーではなくオカレンスを提供します。安定したカーディナリティが重要な場合は、スキーマまたはアプリケーション マッピングがそれを提供する必要があります。汎用シリアライザーは、JSON の形をした要素名だけからそれを証明することはできません。

要素名にできないキー — 数字で始まる名前、スペースや句読点を含む名前、または「xml」で始まる名前、およびコンバーターがそれらの名前を変更またはエスケープする方法

アウトラインでは、コンバーターが不正なキーの名前を変更したり、エスケープしたりする可能性があることを示唆しています。 ToolAcre はそれらを明示的に拒否します。スペースを含むキー、数字またはハイフンで始まるキー、または予約文字 `xml` で始まるキーは、`UNSUPPORTED_SHAPE` をトリガーし、問題のあるパスに名前を付けます。サイレント名前変更では、合意されたスキーマに一致しない XML が生成されます。

有効な名前は、文字、アンダースコア、または名前空間スタイルのプレフィックスで始まり、先頭の後に数字、ピリオド、アンダースコア、コロン、ハイフンを含めることができます。属性キーは、JSON 規則としてのみ `@` を使用します。残りの属性名も同じチェックに合格する必要があります。ソースキーの名前を意図的に変更するか、別のターゲット形式を選択してください。

要素名にできないキーは拒否され、名前変更やエスケープは行われません

数値とブール値は要素テキストとしてシリアル化されるため、それらの JSON 型は XML によって宣言されなくなりました。したがって、デフォルトの逆リーダーは文字列を返します。ここでは Null には XML 表現がありません。Null は空の要素になり、空の文字列と区別できなくなり、ライターはその変更を受けた値の数を報告します。

これは、`{ "a": null, "b": "" }` が同じように読み取られる 2 つの空の要素を生成できることを意味します。この往復をロスレスと呼ぶのは間違いです。属性 `#text` および `#cdata` はコンバーターの構造規則を保持しますが、一般的な XML 型システムは追加しません。

型は XML テキストになり、null は空要素の曖昧さが認められるようになります

`{"order":{"@id":"A-7","customer":"Ada","line":[{"sku":"P1","qty":2},{"sku":"P2","qty":1}],"note":null}}` を使用します。単一の `order` キーはルートになり、`@id` は属性になり、各行オブジェクトは繰り返される `<line>` になり、null は警告付きの空の `<note></note>` になります。

推論を無効にして出力を読み取ります。属性の id、数量、テキスト値は文字列であり、line は 2 回出現するため配列です。これは、失われた null 型と数値型を公開しながら、サポートされている正確な逆を示しています。受信順序スキーマでは、他の名前または順序付けが要求される場合がありますが、この例では検証されていません。

これでカバーされないもの — 手動でマッピングを記述する必要がある、指定された XSD または名前空間に一致する XML の生成

ライターは、XSD を使用したり、名前空間 URI を割り当てたり、ビジネス スキーマから要素の順序を決定したりしません。 XML 宣言を書き込み、DOCTYPE を発行しません。名前空間プレフィックスを含むキーは文字通りに保存されますが、それは名前空間解決ではなく、プレフィックスが正しく宣言されていることの証明でもありません。

特定のサービスによって受け入れられる XML を生成するには、属性、シーケンス制約、選択グループ、および修飾名が必要になる場合があります。現在のスキーマまたはドキュメントを使用して、そのマッピングを構築します。汎用変換は検査や単純なデータ中心のドキュメントに適しており、契約を意識したシリアル化の代替にはなりません。

要点: 形状に依存する前に形状を予測すること、および JSON ドキュメントが生成する XML 構造を構文コンバーター パネルに表示する方法

結果に依存する前に、エンベロープ、項目名、および型の損失を予測します。 ToolAcre は、ルートが 1 つ欠けている値をラップし、配列を繰り返し、`@` キーを属性にマップし、null を空のテキストに置き換え、置換を推測するのではなく不正な名前を拒否します。明白でない変更はすべて、出力または警告に表示されます。

最上位の配列、繰り返されるレコード、null、数値テキスト、扱いにくいキーを含む最小のオブジェクトをテストします。拒否は、手動マッピングが必要であることを示す有用な証拠となります。適切な形式の XML とスキーマが有効な XML は異なるクレームであるため、成功したファイルでも実際の受信者による検証が必要です。

受信者が標本を受け入れた後、マッピングが存続すると予想される場所にのみ逆検査を追加します。属性と繰り返される子は、ToolAcre 独自の規則に基づいてラウンドトリップできますが、null 型とスカラー型はラウンドトリップできません。この違いを記録すると、成功したハッピー パスの例が、統合によって生成されるすべての注文ドキュメントに一般化されるのを防ぐことができます。