XML から JSON: すべてのコンバータが行う必要がある決定

コンバーターが回避できない曖昧さ

`<items><item>x</item></items>` を考えてみましょう。 `item` は文字列であるべきですか、それとも文字列のリストであるべきですか? XML には何も書かれておらず、その違いはコードを作成した瞬間に重要になります。コンシューマは単一要素の応答で常に配列が中断されることを期待し、コンシューマは 2 番目の項目が到着したときにオブジェクトが中断されることを期待します。成熟したコンバータでは、実稼働環境に到達するのに十分なだけ推測が正しいことが多いため、黙って推測するのではなく、既知のリスト要素の配列を強制できます。

属性には命名規則が必要です

JSON には属性がないため、属性は兄弟キーまたはネストされたオブジェクトになる必要があります。広く使用されている規則では、属性名に `@` が付けられます (`<image src="a.png"/>` は `{"@src": "a.png"}` になります)。一方、要素に属性とコンテンツの両方がある場合、要素テキストは `#text` などの予約キーに入ります。コンバーターがどのような規則を使用する場合でも、その規則を一貫して適用する必要があります。これは、半分変換された XML は未変換の XML よりも悪いためです。

                <rss version="2.0"><channel><title>Feed</title></channel></rss>
→ {
  "rss": {
    "@version": "2.0",
    "channel": { "title": "Feed" }
  }
}
              

名前空間

名前空間付きドキュメント - SOAP サービス、サイトマップ、Office 形式 - 要素名は `ns:element` として修飾されます。 JSON に相当するものがないため、コンバータはプレフィックスを削除するか、それをキーの一部として保持するか、名前空間 URI を中心にドキュメントを再配置します。 2 つの名前空間が同じローカル名を使用している場合、これを削除するのが一般的ですが、場合によっては悲惨な結果になることがあります。ドキュメントで名前空間が使用されている場合は、出力を信頼する前に衝突がないか確認し、キーにプレフィックスを保持することを優先します。

この変換が実際に使用される場所

• RSS および Atom フィード — 変換後は、JavaScript でフィードを読むことがはるかに簡単になります。
• SOAP とレガシー API — 応答を最新のクライアントが消費できるものに変換します。
• サイトマップと構成ファイル — スキーマを理解できるエディターを使用せずに構造を検査します。
• データ移行 — XML 時代のシステムから JSON ベースのシステムにレコードを移動します。

往復の忠実性は神話です。 XML を JSON に変換したり、その逆に変換したりすると、宣言順序、空白、コメント、CDATA が存続しないため、元のドキュメントのバイト単位が返されることはほとんどありません。バックアップ戦略としてではなく、他の場所でデータを使用する必要がある場合に変換します。

まず検証してから変換する

XML パーサーは、閉じられていないタグと無効なエンティティに対して厳密であり、エラー メッセージは通常正確です。変換する前にドキュメントを修正してください。保持する価値のある JSON 構造を取得するには、整形式の入力が唯一の方法です。変換はブラウザ内でローカルに実行されます。これは、XML が顧客のエクスポートまたは内部サービスの応答である場合に重要であり、オフラインでも動作し続けます。