XML → JSON 変換

属性には自然な置き場所がない

XML は属性と子要素をはっきり区別します。<user id="7"><name>Ada</name></user> と <user><id>7</id><name>Ada</name></user> は別のことを述べており、多くのアプリケーションが同じように扱っていてもそれは変わりません。JSON にこの区別は存在しないため、変換器は属性を捨てるか、置き場所を発明するかのどちらかを選ぶことになります。

広く使われていて本ツールも採用している約束は、属性キーに @ を付け、要素が属性とテキストの両方を持つ場合はテキストを #text キーに格納する方式です。先ほどの例は {"user": {"@id": "7", "name": "Ada"}} になります。この接頭辞はどの標準にも定められていませんが、十分に一般的で多くの後段コードが認識しますし、変換を可逆に保てます。属性が不要なメタデータだと分かっている場合は、オフにすればより素直な出力になります。

1 件なのか、1 件だけのリストなのか

これは正解の存在しない問題です。XML では <item> を 1 つだけ持つ親と 5 つ持つ親は構造上よく似ていますが、前者はオブジェクトに、後者は配列になるべきです。しかもスキーマがどちらを意図したかは文書自身からは分かりません。スキーマを持たないツールは、見えているものから推測するしかありません。

ここでの規則は、同じ名前の兄弟要素は配列にまとめ、単独の要素は単一の値のままにする、というものです。読むぶんには直感的ですが、出力を扱うコードは両方の形を処理しなければなりません。今日たまたま 1 件しかないリストは、単一要素の配列ではなくオブジェクトとして現れるからです。受け側を自分で書けるなら、反復の前に [].concat(value) のような形で正規化しておくとよいでしょう。

XML の中身はすべて文字列

スキーマのない XML 文書に型は存在しません。<count>42</count> も <sku>0042</sku> も等しくただのテキストで、前者が数値、後者がゼロを保つべき識別子だと知っているのは人間か XSD だけです。

だからこそ型変換は既定動作ではなくチェックボックスになっています。有効にした場合でも、往復が完全に一致する値だけが変換されます。数値文字列は再び文字列化して元と同一になるときだけ数値になるため、0042、+7、1e999 は守られます。true、false、空要素は真偽値と null になります。無効のままならすべて文字列のままで、識別子・電話番号・郵便番号、そして 2^53 を超える整数のように JavaScript の数値精度が黙って値を壊してしまうケースではこちらが安全です。