XML 到 JSON:比看起來更難

你有 XML 資料。你的 JavaScript 應用程式需要 JSON。轉換它並繼續,對吧?

除了轉換產生意外結果。應該存在的陣列不存在。屬性最終出現在奇怪的地方。單個項目隨機變成陣列。

XML 和 JSON 對資料建模的方式不同。在它們之間轉換需要決策。

基本不匹配

JSON 有:物件、陣列、字串、數字、布林值、null。

XML 有:元素、屬性、文字內容、命名空間、註解、CDATA。

沒有 1:1 映射。

陣列問題

XML 沒有陣列。它有重複的元素。

<users>
  <user>Alice</user>
  <user>Bob</user>
</users>

這應該可能變成:

{"users": {"user": ["Alice", "Bob"]}}

但是這個呢:

<users>
  <user>Alice</user>
</users>

一個元素。它是一個有一個項目的陣列,還是只是一個字串?不同的轉換器有不同的決定。

一致性很重要。如果 user 有時是陣列有時是字串,你的程式碼會損壞。

屬性問題

XML 有屬性。JSON 沒有。

<product id="123">Widget</product>

常見的轉換策略:

{"product": {"_id": "123", "_text": "Widget"}}
{"product": {"@id": "123", "#text": "Widget"}}
{"product": {"$": {"id": "123"}, "_": "Widget"}}

每個慣例都不同。知道你的轉換器產生什麼。

命名空間問題

XML 命名空間創建像 soap:Envelope 這樣的限定名稱。JSON 沒有命名空間的概念。

轉換器要麼:

• 在屬性名稱中包含前綴:"soap:Envelope"
• 去除前綴:"Envelope"
• 為命名空間處理創建巢狀結構

每種方法都有權衡。

實用技巧

保持一致。 選擇一個轉換函式庫並堅持使用它。混合轉換器會產生不一致的結構。

強制陣列。 如果元素可以有多個實例,配置轉換器總是產生陣列,即使對於單個元素也是如此。

測試邊緣情況。 轉換真實資料,而不僅僅是樣本。生產資料中的邊緣情況會讓你驚訝。

考慮替代方案。 如果你控制兩端,考慮從一開始就使用 JSON。來回轉換會失去資訊。

JSON 到 XML 挑戰

反向也有問題。

沒有陣列表示。 JSON 陣列變成重複元素。你需要命名這些元素。

{"items": [1, 2, 3]}

變成什麼?<items><item>1</item>...</items>?「item」從哪裡來?

數字類型。 JSON 區分數字和字串。XML 不區分。123 可能變成 <value>123</value>——那是數字還是字串?

何時轉換

與舊系統整合。 SOAP API 和舊企業系統使用 XML。在邊界處轉換。

處理 XML 資料。 JavaScript 處理 JSON 比 XML 好得多。轉換,處理,如果需要轉換回去。

一次性遷移。 從基於 XML 的系統移動到基於 JSON 的系統。

何時不轉換

往返要求。 XML → JSON → XML 通常會失去資訊。屬性、命名空間、順序。

模式驗證。 XML 有強大的模式語言(XSD)。JSON Schema 不太成熟。

文件處理。 XML 的混合內容模型(帶有嵌入元素的文字)無法乾淨地映射到 JSON。

---

XML 和 JSON 以不同的方式表示資料。轉換需要關於陣列、屬性和命名空間的選擇。理解你的轉換器的行為並用真實資料測試。