兩者之間沒有標準映射。 XML 1.0 具有屬性、命名空間、有序混合內容和註解; RFC 8259 有六種類型,沒有屬性。每個轉換器都會發明自己的橋,這就是為什麼其中兩個不同意的原因。
教導我尊重 XML 到 JSON 轉換的整合是運輸承運商's API。堆疊中其他地方都有現代休息,然後是這個傳統端點,它講 SOAP 並返回我需要折疊到 JSON 管道中的 XML 信封。 &引用;它'只是 XML 到 JSON,&引用;我想到了,並伸手去拿單行轉換器。然後邊緣案例到達:a <Package> 有時是單一物件、有時是清單的元素,取決於順序中有多少個包。一個 id 我的樸素轉換器完全放棄了屬性,因為它只查看元素文字。 A <Description> 包裹在 CDATA 中,因為它包含一個&符號。每一個都默默地損壞了資料--JSON 看起來似乎合理,而且是錯誤的,只顯示下游的三個服務。
XML 和 JSON 看起來應該簡單地相互轉換,並且它們會 don 't,因為它們使用不同的基元對資料進行建模。 JSON 有物件、陣列、字串、數字、布林值和 null - 一個小而乾淨的集合。 XML 具有元素、屬性、文字節點、混合內容、命名空間、CDATA、註解和處理指令,最重要的是它具有 沒有數組 和 沒有類型。 因此,轉換器必須做出無損格式不會做出的決定't:當 JSON 沒有屬性的概念時,屬性會走向何方?當 XML 以相同的方式標記單一元素時,您如何從單一項目清單中區分單一元素?同時具有屬性和文字的元素會發生什麼變化?
一個 XML 到 JSON 轉換器 故意且一致地做出這些決定的是乾淨整合和下游調試一周之間的區別。我為toolz。dev 構建的映射將屬性歸因於前綴鍵,因此不會丟失任何東西,將重複的標籤折疊到JSON 數組中,從而保留結構,將混合內容文本保留在專用鍵下,並逐字讀取CDATA。它透過瀏覽器中運行的無依賴性解析器來完成所有這些操作,這很重要,因為整合有效負載正是您應該'上傳到陌生人和#39;s 的資料類型伺服器。
本指南介紹了轉換如何處理 XML'當重複的元素變成數組時,如何處理屬性和命名空間,以及不斷發生這種轉換的 SOAP 和 RSS 工作流程的結構怪癖。
TL;DR: 將 XML 貼到 toolz。dev XML 到 JSON 轉換器,選擇縮進,然後清除屬性變為的 JSON
@- 前綴鍵,重複標籤變成數組,混合內容文字位於下方#text,並且逐字讀取 CDATA。可選類型解析輪流"44.95"進入實數。它使用無依賴解析器,100% 客戶端運行,因此 SOAP 和整合有效負載永遠不會上傳,並與之配對 JSON 到 YAML 和 json 格式化程式 用於管道中的下一步。
為什麼 Isn't XML 到 JSON 是一個簡單的一對一映射?
XML 和 JSON 可互換的直覺來自於它們的共享工作(表示結構化資料)以及不同構建塊的中斷。不匹配出現在四個特定位置,並且有一個轉換器'品質完全取決於它如何處理它們。
屬性沒有 JSON 等效項。 <book id="bk101">War and Peace</book> 有一個屬性(id)和文字內容(War and Peace). JSON 沒有屬性的概念;一切都是鍵值對。轉換器必須發明一種約定,而廣泛使用的約定是前綴屬性鍵 - { "book": { "@id": "bk101", "#text": "War and Peace" } }. 放棄屬性,就像樸素的轉換器所做的那樣,然後你'默默地遺失資料。
JSON有數組; XML 沒有't。 在 XML 中,清單只是重複相同的標籤:三個 <item> 父級之一下的元素。但單身 <item> 在結構上看起來與列表相同。 JSON 需要知道是發射物件還是數組,唯一可用的訊號是發生 - 因此重複的標籤變成數組,單一標籤保留物件。
混合內容。 元素可以容納子元素和鬆散文字。 JSON 物件可以't 自然地表示 "該物件還具有裸字串值 "因此文字位於保留鍵下,例如 #text.
類型 don'不存在於 XML 中。 XML 中的每個值都是文字。 <price>44.95</price> 是字串 "44.95",不是一個數字,除非轉換器選擇強制它 - 這個選擇可能是錯誤的,因為 <zip>08544</zip> 必須保留字串或失去前導零。
的 轉換器 明確地處理每一個,而不是假裝它們不存在'不存在。 That'這就是為什麼輸出保持忠實於來源,而不是悄悄刪除 JSON 沒有插槽的 XML 部分。
重複的元素什麼時候變成陣列?
這是 XML 到 JSON 轉換中最令人困惑的部分,它'值得理解而不是感到驚訝。規則 轉換器 使用是基於出現的:在給定的父級中,如果標籤名稱出現多次,其值就會崩潰為 JSON 陣列;如果它只出現一次,則它保持單一物件或值。
所以a <catalog> 和兩個 <book> 孩子們生產 { "catalog": { "book": [ {...}, {...} ] } } - 一個陣列。但一個 <catalog> 與一 <book> 產生 { "catalog": { "book": {...} } } - 一個普通的對象,沒有數組。
計劃的結果: 一個項目的清單沒有'看起來像一個清單。 如果您的下游程式碼有期望 catalog.book 要始終是一個數組並在它上面迭代,單本書的回應會破壞它,因為 book 將是特定時間的物件。這是't 轉換中的錯誤 - it'是 XML 不標記清單的不可避免的後果 - 但它是'是項目數量變化的整合中真正的陷阱。我的運輸承運商災難正是這樣的:單包訂單傳回一個對象,而多包訂單傳回一個數組,而我的程式碼假定數組。
消耗程式碼中的防禦模式是標準化:如果欄位可以是其中之一,則在迭代之前將其強制到數組(([].concat(catalog.book)).知道 為什麼 形狀的變化讓你寫下那個守衛而不是被它燒傷。
如何處理屬性和命名空間?
屬性轉換為帶有 的物件鍵 @ 前綴。 <user role="admin" active="true"> 成為 { "user": { "@role": "admin", "@active": "true" } }. 前綴使屬性在視覺上與子元素不同,並防止屬性和子元素共享名稱的衝突。如果您 don'根本不需要屬性 - 您只需要元素資料 - 轉換器 具有 "忽略屬性"完全放棄它們以獲得更乾淨結果的選項。
命名空間作為標籤名稱的一部分出現。 <soap:Body> 成為按字面命名的密鑰 "soap:Body", 和 xmlns:soap="..." 是與其他屬性一樣的屬性,落在下面 @xmlns:soap。 這是務實的選擇:將命名空間完全解析為其 URI 將產生笨重的金鑰,並且很少匹配整合程式碼實際想要的(即尋址) soap:Body 透過其熟悉的前綴名稱。如果您'正在處理 SOAP 或 SVG 或任何命名空間的詞彙表,您從 XML 中知道的前綴是您在 JSON 中獲得的鍵。
CDATA 部分 - <![CDATA[ ... ]]> 讓 XML 攜帶帶有特殊字元的原始文字的區塊 - 是逐字讀取的,沒有實體解碼,這正是它們的目的。 A <script> 或者 <description> 包裹在 CDATA 中以保護其&符號和尖括號,這些字元完好無損。 CDATA 之外,標準實體 (<, &,還有朋友)和數字參考(é, é) 被解碼為它們的實際字元。
如何使用工具將 XML 轉換為 JSON?
第 1 步:貼上您的 XML
任何格式良好的 XML 都可以工作 - 有或沒有 <?xml ?> 聲明,有或沒有命名空間。聲明、DOCTYPE、註釋和處理指令被識別和跳過,因此您可以直接從 API 回應或檔案貼上完整的文件。載入範例按鈕為您提供包含屬性、嵌套元素和重複標籤的目錄,以便您可以立即看到每個轉換行為。
第 2 步:選擇您的選項
選擇 JSON 的 2 或 4 空間縮排。決定是否包含屬性或刪除它們。並選擇是否解析類型:將其關閉,每個值保持字串(安全、無損);打開它,明確的數字和布林值就會變成真正的 JSON 數字和布林值。當郵遞區號或 ID 等值可能有您需要保留的前導零時,Off 是正確的預設值。
第三步:轉換和審查
轉換器首先解析並報告格式錯誤的標記 - 不匹配的結束標籤、未關閉的元素、未終止的 CDATA 區塊 - 具有特定訊息,而不是產生垃圾 JSON。成功後,JSON 會顯示行數和位元組數。瀏覽它以確認數組與物件的決策符合您的期望。
第四步:複製或下載
將 JSON 複製到剪貼簿以貼上到程式碼中,或將其下載為 .json 文件。從這裡開始,它會進入請求正文、資料儲存或管道的下一階段。如果下一步是配置格式,則 JSON 到 YAML 轉換器 更進一步。
此轉換的常見工作流程是什麼?
整合舊版 SOAP API
SOAP 仍然存在於企業、銀行、物流和政府系統中,並且只講 XML。當現代 JavaScript 或 Node 服務需要使用 SOAP 回應時,將 XML 信封轉換為 JSON 是第一步。命名空間保存轉換意味著 soap:Body 和 soap:Envelope 保留它們熟悉的名稱,屬性處理保留 SOAP 喜歡掛斷元素的元資料。這是所涵蓋的同一類別的膠水工作 API調試指南.
讀取 RSS 和原子源
RSS 和 Atom 提要是 XML,將它們拉入 JavaScript 應用程式意味著將它們轉換。提要's <item> 元素是教科書上的重複標記案例 - 它們成為 JSON 數組項目,正是您想要的 .map() 渲染列表。屬性如外殼's url 和 type 保留在前綴鍵下,因此播客和媒體來源保持其音訊連結完好無損。
遷移配置和資料檔
較舊的應用程式將配置和資料儲存在 XML 中 - think .config 文件、網站地圖、匯出資料集、office Open XML 片段。將這些轉換為 JSON 是現代化系統或將遺留資料匯入 JSON 本機儲存時的第一步。當您使用時,類型解析選項非常有用 知道 數字欄位是真正的數字,並且希望在目標中輸入它們。
測試和原型設計
當你'重新佈線資料流,只需要將 XML 有效負載的形狀視為 JSON - 設計 TypeScript 介面、模擬回應、檢查欄位路徑 - 瀏覽器中的快速轉換會擊敗編寫一次性解析器程式碼。轉換、讀取結構、根據它寫入類型。
XML 與 JSON:每種格式何時適合?
| XML | 傑森 | |
|---|---|---|
| 主要時代&生態系 | 企業、SOAP、文件 | Web API、JavaScript、config |
| 屬性 | 一流 | 無 - 映射到前綴鍵 |
| 數組 | 無 - 重複標籤意味著清單 | 一流 |
| 類型 | 所有文字 | 字串、數字、布林值、空 |
| 評論 | 支持 | 不在規格中 |
| 命名空間 | 一流 | 無 - 保留為前綴鍵名 |
| 冗長 | 更高 - 關閉標籤、屬性 | 下部 - 大括號 |
| 自然棲息地 | SOAP、RSS/Atom、Office 格式、設定 | REST API、前端資料、 package.json |
表格背後的模式:XML 是為文件和企業交換而構建的,其中結構、驗證和自我描述很重要; JSON 是為網路而建構的,其中輕度和 JavaScript 物件的直接映射很重要。轉換方向絕大多數是 XML 到 JSON,因為行業中的運動是從舊的基於 XML 的系統轉向 JSON 本機前端和服務 - you'正在滿足其所在位置的傳統資料並將其帶入現代管道。該管道的更廣泛的格式工具集就在其中 編碼工具指南.
轉換包含敏感資料的 XML 是否安全?
整合有效負載與您所擁有的東西密集'不想洩漏:SOAP 回應攜帶客戶記錄、具有內部端點和憑證的設定檔、帶有個人資訊的資料匯出。這些正是貼到線上轉換器中的內容,通常是在整合過程中,通常是匆忙的。
的 toolz。dev 轉換器 使用無依賴解析器在瀏覽器中完全解析和轉換 - 不 DOMParser,沒有伺服器呼叫,沒有資料離開頁面。頁面載入後斷開網路並且仍然有效。那'是關於工具如何建構的架構事實,而不是策略文件中的承諾,它'這是整個工具箱背後的瀏覽器優先原則,詳見 資料隱私指南.
標準警告適用:客戶端轉換保護轉換步驟。之後您如何處理 JSON(將其貼到何處、發送到何處)是一個單獨的決定。但轉換本身會將您的 XML 保留在您的電腦上。
問號
如何將 XML 轉換為線上 JSON？
將 XML 貼上到 XML 到 JSON 轉換器,然後按一下「轉換」。該工具解析 XML,將其轉換為帶有您選擇的縮排和選項的 JSON,並允許您複製或下載結果。處理是 100% 瀏覽器內 - 沒有上傳任何內容。
XML 屬性在 JSON 輸出中是如何表示的？
屬性變成以@為前綴的物件鍵,因此帶有id="bk101"的書本元素轉換為"@id"鑰匙。這使得屬性與子元素不同。如果您只需要元素數據,您可以使用忽略屬性選項完全關閉屬性輸出。
為什麼有些 XML 元素變成陣列，而有些則保持物件？
JSON 無法標記元素可以重複,因此轉換器使用 increase:如果標籤在同一父級下出現多次,則它變成數組,如果它出現一次,則它保留單一物件。這忠實地反映了來源,儘管這意味著包含一個項目的清單看起來像一個物件而不是一個陣列。
轉換器是否處理 CData 部分和 XML 實體？
是的。 CDATA 區塊是逐字讀取的,無需實體解碼,這就是它們的目的。在 CDATA 之外,標準實體如 <,>,&,&引用;和'以及數字字元引用,如 é和é被解碼為其實際字元。
我可以將 SOAP 回應或 RSS 提要轉換為 JSON 嗎？
是的。 SOAP 信封和 RSS 或 Atom 提要是普通的 XML,因此它們像任何其他文件一樣進行轉換。命名空間標籤在鍵名中保留前綴 - soap:Body 變成 "soap:Body"鍵 - 和重複的元素(例如 RSS 項目)成為您可以映射的 JSON 數組。
轉換後數字和布林值會保持文字嗎？
預設情況下,是的,因為 XML 沒有類型系統和值,例如 "007"或"1.10"作為文字可能有意義。啟用類型解析選項,將明確的數字和布林文字轉換為真實的 JSON 數字和布林值(當這是您想要的時)。
轉換包含敏感資料的 XML 是否安全？
是的。解析器在瀏覽器中完全使用 JavaScript 運行 - 沒有網路請求攜帶您的數據,沒有任何記錄或存儲,並且該工具離線工作。帶有客戶記錄、內部識別碼或整合機密的 XML 永遠不會離開您的電腦。
XML 和 JSON 有什麼不同？
XML 是一種帶有開頭和結尾標籤、屬性、命名空間和註解的標記語言,專為文件和企業資料交換而設計。 JSON 是一種由物件、陣列和原始值建構的更輕格式,是現代 Web API 的預設格式。當將較舊的 SOAP 或基於 feed 的系統與 JavaScript 前端整合時,將 XML 轉換為 JSON 很常見。
XML 和 JSON 看起來可以互換,aren't,因為 JSON 沒有屬性,沒有重複數組,也沒有文字和子級 - 確切地說,樸素的轉換會默默地丟失資料。專門處理這些情況的轉換器會為您提供 JSON that'忠實於來源: 貼上您的 XML,檢查它如何映射屬性和重複標籤,並將乾淨的資料帶入您的管道,而不是看似合理的損壞。
