JSON と XML は構造そのものが異なる
JSON にはオブジェクト、配列、文字列、数値、真偽値、null があります。XML には名前付きの要素、属性、テキストノード、順序のある文書ツリーがあります。あらゆる JSON 値をあらゆる XML 文書へ損失なく対応付ける普遍的な規則はありません。変換ツールはルート名、属性、繰り返される子要素の表現を選ぶ必要があります。MultiVerto では、プロパティが1つの JSON オブジェクトを XML 文書のルートとし、そのプロパティ名を要素名にします。特別な @attributes オブジェクトには属性を入れ、配列から繰り返しの子要素を書き出します。これはこのツールの取り決めであり、XML 規格が定めた名前ではありません。実運用のデータに適用する前に、目的のスキーマを把握してください。
注文レコードを往復変換する
埋め込み例を使います。order オブジェクトには、文字列 7 を id の値とする @attributes、ペンと本 を含む item 配列、数値 2 の count があります。JSON→XML ツールは1つの order ルート、id 属性、2つの item 要素、count 要素を作ります。XML→JSON ツールでこの単純な文書を読み戻せます。繰り返しの item 要素は配列にまとめ、属性は @attributes の下に格納します。ただし要素内のテキストは文字列として読まれます。元は JSON の数値 2 だった count が文字列の 2 として戻るのです。見える数字は同じでも型は異なります。ページの見た目だけでなく、解析後のデータ構造を比較してください。 埋め込みコンバーターの例: 入力 {"order":{"@attributes":{"id":"7"},"item":["ペン","本"],"count":2}}、結果 <order id="7"> <item>ペン</item> <item>本</item> <count>2</count> </order>。
- JSON：count は数値 2、item は配列
- XML：count は要素のテキスト、item 要素は二つ
- JSON に戻すと count は文字列の 2：スキーマを確認
情報が変化する場所
XML では属性と子要素は異なりますが、JSON オブジェクトは、対応付けの規則で一部を予約しない限りプロパティを使います。同名要素が繰り返されると配列になっても、1回しか現れなければ単一値になる場合があり、常に配列を期待するコードには意外な結果です。JSON の null、数値の精度、真偽値については、XML のテキストだけでは区別できないため、スキーマ上の判断を明示する必要があります。アプリケーションが JSON オブジェクトのメンバーを順不同と扱っても、XML の受け手には順序が重要な場合があります。MultiVerto は意味のあるテキストと子要素が混在する XML 文書を意図的に拒否し、すべての XML 構造には対応しません。複雑な混合コンテンツを持つ任意の文書ではなく、単純なレコード向けです。
変換前に対応付けの規則を決める
2つのサービスを連携するときは、文書の例と受け手のスキーマを入手します。フィールドを属性にするか子要素にするか、配列をどう表すかを決めます。数値、真偽値、空文字列、欠落したフィールドを受け手がどう解釈するかも指定してください。元データが XML なら、軽量な対応付けツールを使う前に名前空間と混合コンテンツを調べます。専用の XML パーサーが必要かもしれません。元データが JSON なら、このツール用にルートが名前付きのオブジェクト1つで、キーが有効な XML 要素名であることを確認します。代表的な小例を双方向に変換し、見た目が似ているだけで互換性を決めず、実際の受け手で結果を試してください。
目的を決めて往復の結果を調べる
例の出力をリンク先の XML→JSON 変換ツールにコピーし、再構築されたデータと元の JSON を比較します。型、繰り返し要素、属性の配置、空の値に注目してください。item 配列を1要素に変え、後続のソフトウェアがなお配列を期待するか確認します。スキーマで許される場合に限り、先頭にゼロのある count も試してください。テキストと数値では意味が違います。監査のため元データを変換後の成果物と一緒に残します。XML を整形すると入れ子を確認しやすくなりますが、対応付けの誤りは直りません。解析に成功しても、それはパーサーが構文を受け入れたというだけで、別のアプリケーションが期待する業務上の意味を表している証拠ではありません。