XML を JSON に変換

XML は情報を要素名・属性・テキストの 3 か所に持ちますが、JSON にはキーと値しかありません。ですから対応関係には規則が必要で、ここで使われているのは一般的なものです。各要素は子要素のオブジェクトを値に持つキーになり、各属性はそのオブジェクト上に @ を付けたキーになり、要素自身のテキストは、子要素や属性が一緒にある場合、#text というキーに入ります。

テキストしか持たない要素はもっと単純です。ラッパーオブジェクトのない、ただの文字列値になります。この不整合は避けられず、早めに理解しておく価値があります。ある経路にある値が、元の要素が属性を持っていたかどうかによって、あるときは文字列、あるときはオブジェクトになるということだからです。

変換された XML を扱ううえで、これがいちばんコストのかかる点です。XML の文書は、どの要素が繰り返すかを言いません。それを言うのはスキーマだけで、パーサーはそれを読んでいません。ですから 1 個の item 要素を含むチャンネルはオブジェクトを生み、2 個含むチャンネルはオブジェクトの配列を生みます。JSON の形は、ファイルにどれだけのデータがあったかに左右されます。

完全な RSS フィードを前提に書かれたコードは、フィードの項目が 1 件になった日に壊れます。単一のレコードを返す SOAP レスポンスを前提にしたコードは、2 件返ってきた最初の瞬間に壊れます。ここで解決する設定はありません。解決にはスキーマを知る必要があり、パーサーはそれを持っていないからです。両方を受け入れるように受け手を書いてください。他のロジックが触れる前に、まずすべてのコレクションを配列に強制してください。

SOAP のエンベロープは接頭辞をそのままにして届きます。soap:Envelope は文字どおり "soap:Envelope" という名前のキーになり、名前空間の宣言も "@xmlns:soap" のような属性として来ます。何も解決されず、何も取り除かれません。

それは忠実であると同時にもろさもあります。接頭辞は任意のものだからです。あるサービスがある週は soapenv:Envelope を、次の週は soap:Envelope を出せば、同等の 2 つの文書から互換性のない 2 つの JSON 構造が生まれます。受け手を自分で書けるなら、キー全体ではなくコロンのあとのローカル名で照合し、自分で定義していない接頭辞を決め打ちしないでください。

バージョンとエンコーディングの宣言で始まる文書は、その属性を持つ "?xml" というキーをトップレベルに、ルート要素のキーと並べて生成します。これは文書の内容ではなく、それでも JSON の中に存在します。

無視するか削除するかで対処してください。ただしルート要素だけがトップレベルの唯一のキーだとは決して思い込まないでください。オブジェクトの最初のキーを読んでルートを見つけるコードは、宣言を持つほとんどの文書で、代わりにその宣言を見つけてしまいます。

数値に見える値は、属性でも要素のテキストでも JSON の数値になります。1.0 と書かれたバージョン属性は 1 になります。007 と書かれた識別子は 7 になります。0755 と書かれたゼロ埋めの要素値は 755 になります。

これは件数にとっては便利ですが、不透明なトークンとして扱っていたものにとっては破壊的です。注文番号、商品コード、郵便番号、プロトコルバージョン、ファイルモードはどれも同じように失敗し、しかもエラーは出ません。文字列として比較するつもりのすべての属性を、そのコードを書く前に一度出力の中で見ておく習慣が安上がりです。注文 007 と注文 7 が同じ注文だとサポートチケットで気づくよりずっと安く済みます。

コメントは痕跡なく落ちます。ペイロードではたいてい無害ですが、設定ファイルでは本物の損失です。CDATA は展開され、中にあったものは普通の文字列になります。RSS フィードが記事本文を運ぶ普通の方法である、CDATA に包まれた HTML の断片は、山括弧を含むテキストとして届き、XML に戻す変換をすると CDATA セクションを復元するのではなくエスケープされてしまいます。

混在コンテンツは良い答えのない場合です。テキスト、続いて子要素、続いてまたテキストを含む要素は、子要素を自分のキーの下に保ちつつ、2 つのテキストの連なりを 1 つの #text 値に連結し、子要素がその間のどこにあったかを示す印は残りません。散文とマークアップが入り交じる文書——XHTML、DocBook、物語的な内容のものすべて——は、ここで順序を失います。JSON はそもそも単純に不向きな行き先です。

自己終了要素と、本体が空の要素はどちらも空文字列になります。XML もこの二つを区別しないので、何かが失われているわけではありませんが、JSON には null という選択肢があるのに使われていません。空要素は "" であって null ではありません。

消えてしまう区別は、要素が存在しなかった場合と、存在したが空だった場合の間にあります。コードが既定値を適用すればどちらも偽と評価されます。任意フィールドが明示的にクリアされたのか一度も設定されなかったのかが問題になる場面では、値ではなくキーの存在を確認してください。

まとめると、SOAP のレスポンスは入れ子のキーとして読めます。エンベロープのキー、その中にボディのキー、そのあと操作のレスポンス、そのあとペイロード。どの階層も自分の接頭辞を保ち、実際のデータが現れるまでにオブジェクトが 3、4 段重なりますが、それは XML と同じ冗長さで、コードからはたどりやすくなっています。

最初にテストすべきなのは fault（障害応答）です。SOAP の fault は成功時とは異なる要素構造を使うので、エラーの JSON は結果の JSON とまったく違って見え、正常系しか見たことのないクライアントは、もう存在しないパスから undefined を読み取ってしまいます。ここで本物の fault レスポンスを 1 つ変換し、必要になる前にエラー分岐をそれに対して書いておいてください。

出力はスペース 2 個の字下げで書かれるので、レビューでも読みやすく、テストの固定資産にそのまま貼り付けられます。固定資産こそがこの正しい使い道です。実際のレスポンスを 1 つ変換しリポジトリにコミットしておけば、受け手は上記のすべての厄介さも含めて、正直にテストできる対象を得られます。

三つの防御的な習慣が、このページのほとんどの問題を覆います。繰り返しうるものはすべて配列に正規化する。識別子は文字列として比較し、パーサーが数値にしてしまった場合は境界で文字列に戻す。名前空間付きのキーはそのローカル部分で照合する。これらを備えておけば変換は信頼でき、それ以外の挙動もすべて予測できます。