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"}}。這個字首並不屬於任何標準，但足夠常見，多數下游程式碼都認得，而且它讓轉換保持可逆。如果你確定這些屬性只是用不上的後設資料，關掉它可以得到更乾淨的輸出。

是一個條目，還是隻有一項的列表？

這是一個沒有正確答案的問題。在 XML 裡，只有一個 <item> 子元素的父節點和有五個的父節點結構上看起來差不多，但它們分別應該變成一個物件和一個數組——而文件本身完全沒有透露 schema 的本意。沒有 schema 的工具只能從看到的內容去猜。

這裡的規則是：同名的兄弟元素摺疊成陣列，孤零零的元素保持為單個值。閱讀時這符合直覺，但也意味著消費輸出的程式碼必須同時處理兩種形態，因為一個今天恰好只有一條記錄的列表會產出物件而不是單元素陣列。如果消費端在你手裡，遍歷前先用 [].concat(value) 之類的寫法歸一化。

XML 裡的一切都是字串

沒有 schema 的 XML 文件裡不存在型別。<count>42</count> 和 <sku>0042</sku> 都只是文本，只有人或者一份 XSD 才知道前者是數字、後者是必須保留前導零的編號。

這正是型別推斷做成核取方塊而不是預設行為的原因。開啟後，只有往返完全一致的值才會被轉換——數字字串只有在重新格式化後文本完全相同時才轉成數字，這就保護了 0042、+7 和 1e999。true、false 和空元素會變成布林值和 null。關閉時所有值保持字串，這對編號、電話號碼、郵編以及任何超過 2^53 的整數都更安全，否則 JavaScript 的數字精度會悄悄改掉這些值。