這兩個模型不對齊: RFC 8259 定義了六種沒有屬性的 JSON 類型,而 XML 1.0 具有屬性、命名空間和有序混合內容。朝這個方向走意味著選擇如何處理差異。
當我第一次必須將 JSON 資料傳送到只講 XML 的系統中時,我做了一件天真的事情:我在文字編輯器中手寫了尖括號。這是一個供應商提要,期望有一個 SOAP 風格的信封,而我的來源是一個來自 Laravel API 的整潔的 JSON 數組。二十分鐘後,我在第四十筆記錄附近的某個地方的結束標籤不匹配,接收解析器拋出了一個 "在文件元素和引用之後垃圾;這個錯誤沒有告訴我任何事情 在哪裡. 那天晚上給了我一個教訓,我已經應用於此後的每次整合:JSON 和 XML 之間的轉換並不是一個創造性的行為。這是一個映射問題,規則數量很少,當你寫下這些規則的那一刻,整個事情就變得機械化了。
本指南是我希望 I'd 擁有的映射的版本。我建立了 [toolz。dev](/,其中一個工具是基於瀏覽器的 JSON 到 XML 轉換器 這完全適用於下面的約定。但這篇文章的重點不是按鈕 - it's 理解 為什麼 鍵變成元素,為什麼a @- 前綴鍵變成屬性,以及為什麼數組變成重複標籤而不是編號清單。一旦點擊這三個想法,您就可以手動將任何 JSON 轉換為 XML(如果需要),並且當下游系統拒絕輸出時,您可以調試輸出。
TL;DR: 若要將 JSON 轉換為 XML,請將每個物件金鑰對應到一個元素
@- 其父元素上屬性的前綴鍵,以及#text元素'的密鑰;文字內容。將每個陣列展開為共享密鑰的重複兄弟元素's 名稱。逃脫&,<, 和>在文字中(加"在屬性值中),並清理任何屬於 't 合法 XML 名稱的金鑰。在瀏覽器中執行此操作,以便帶有令牌或客戶資料的有效負載永遠不會離開您的電腦。
為什麼要先將 JSON 轉換為 XML?
JSON 幾年前贏得了 Web API 戰爭,如果您在 React、Laravel 或 Node 度過日子,您可能會合理地問您何時'根本不需要 XML。答案是:不斷地,只是不在你看的地方。 XML 是 JSON 時代之前龐大的系統安裝基礎的通用語言,並且不會去任何地方。 SOAP Web 服務 - 仍然是銀行、保險、物流和政府整合的支柱 - 以 XML 形式承載其有效負載。 RSS 和 Atom 提要是 XML。網站地圖是 XML。 Android 佈局, .docx 和 .xlsx 內部結構(office Open XML)、SVG、RSS 播客來源和無數 B2B EDI 風格的交換都是 XML。
所以現實世界的場景幾乎總是相同的形狀:你有數據 在 JSON 因為那'是你的堆疊產生的,你需要它 在 XML 因為那'這是另一邊的要求。也許你'正在將產品資料推送到只接受 XML 提要的市場。也許你'將 API 回應包裝在 SOAP 主體中。也許你'從 JSON 內容匯出產生 RSS 提要。在每種情況下,您都選擇 '每次都不想重新發明序列化 - 您想要一個可預測的規則,將任何 JSON 結構變成有效的 XML,這樣您就可以自動化它並停止思考它。
There'還有一個更安靜的原因:偵錯期間的可讀性。當你'我們盯著一個深度嵌套的 JSON blob 試圖理解層次結構,將其轉換為縮排的 XML 有時會使樹結構跳出,因為 XML's 開啟/關閉標籤使嵌套以 JSON's 大括號 don't。的方式明確。我保留 JSON 到 XML 轉換器 反之亦然 XML 到 JSON 轉換器 在相鄰選項卡中開啟的頻率比 I' 更頻繁。
JSON 究竟如何對應到 XML?
這是它的核心。只有四個規則,其他一切都是細節。
規則 1:物件鍵變成元素。 JSON 物件 { "book": { "title": "..." } } 成為 <book><title>...</title></book>. 鍵是標籤名稱;值就是裡面的值。
規則2: @- 前綴鍵成為屬性。 XML 元素可以攜帶屬性,而 JSON 沒有它們的本機概念,因此我們需要一個約定。廣泛使用的字元(也是我的工具使用的字元)是前綴字元 @ 預設情況下。所以 { "book": { "@id": "bk101", "title": "..." } } 成為 <book id="bk101"><title>...</title></book>. 屬性只能保存原始值(字串、數字、布林值),不能保存嵌套結構,這與 XML 屬性的實際工作方式相符。
規則 3: #text 密鑰變成文字內容。 當一個元素需要的時候 兩者 屬性和文字-思考 <title lang="en">Hello</title> - 你可以用一個簡單的字串值來表達它,因為字串沒有為屬性留下空間。約定是保留鍵, #text: { "title": { "@lang": "en", "#text": "Hello" } }. 如果元素只有文字而沒有屬性,則可以跳過 #text 只需使用一個簡單的字串值即可。
規則 4:數組成為重複元素。 這是人們最常犯錯的一個。 XML 沒有數組類型。事物清單表示為具有相同標籤名稱的重複兄弟元素。所以 { "tags": { "tag": ["computer", "web"] } } 成為 <tags><tag>computer</tag><tag>web</tag></tags> - 不是 <tag>0</tag> 或任何基於索引的廢話。數組's 鑰匙 提供重複的標籤名稱。
將它們放在一個真實的物件上,輸出正是下游 XML 解析器所期望的:
{
"catalog": {
"book": [
{ "@id": "bk101", "author": "Gambardella, Matthew", "price": 44.95 },
{ "@id": "bk102", "author": "Ralls, Kim", "price": 5.95 }
]
}
}
成為
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<book id="bk101">
<author>Gambardella, Matthew</author>
<price>44.95</price>
</book>
<book id="bk102">
<author>Ralls, Kim</author>
<price>5.95</price>
</book>
</catalog>
請注意,單一頂級密鑰, catalog,成為文件's 根元素。 That's 故意:格式良好的 XML 文件必須只有一個根。當您的 JSON 已經有一個包裝鍵時,該鍵 是 根。當它沒有't - 當您向轉換器提供多鍵物件或裸數組時 - 該工具將所有內容都包裹在可配置的根元素下((root 預設情況下)因此輸出保持良好格式。
轉義名稱和無效名稱怎麼樣?
有兩件事悄悄地打破了比任何嵌套錯誤更多的轉換:未逃脫的特殊字元和非法元素名稱。
逃跑。 XML 保留了一些字元。元素內文本, &, <, 和 > 必須寫成 &, <, 和 >。 在雙引屬性值內,您還必須轉義雙引屬性值 "。 如果您的 JSON 字串包含 Tom & Jerry 然後將其放入 XML 原始中,裸露的 ampersand 會使文件格式錯誤,解析器就會死亡。正確的轉換器會自動逃脫,所以 "a < b & c" 成為 a < b & c 在輸出和解析時回傳到原始文字。這不是可選的拋光 - it'有效和無效 XML 之間的差異。
元素名稱。 XML 對於標籤名稱可能包含的內容有嚴格的規則。名稱 can't 包括空格,can't 以數字、連字符或句點開頭,並排除大多數標點符號。 JSON 鍵沒有這樣的限制 - "first name", "123", 和 "total($)" 都是完全合法的 JSON 金鑰和所有非法的 XML 名稱。忽略此的轉換器會產生解析器不會接受的文件。務實的修復方法以及我的工具的作用是清理:用底線替換非法字符,並在名稱以數字開頭時添加下劃線。所以 "123 bad" 成為 <_123_bad>. It'雖然不迷人,但它保證了輸出的解析,這就是全部點。
如何使用基於瀏覽器的轉換器?
工作流程開啟 Toolz.dev/tools/json-to-xml 反映了上述規則,針對實際邊緣情況提供了一些選項。
將您的 JSON 貼到輸入中並按轉換。如果您的 JSON 格式錯誤,您會收到明顯的解析錯誤,而不是靜音垃圾 - 我依靠瀏覽器'自己的 JSON.parse'd 在您的控制台中看到的內容與錯誤訊息相符。當您需要查看人類可讀文件時,選擇 2 或 4 個縮排空格,或在您' 時選擇 Minify 將整個內容折疊到一行;透過電線和每個位元組計數(特別是 SOAP 請求和饋送有效負載)傳輸它。為 JSON 沒有單一包裝金鑰的情況設定根元素名稱。切換 XML 聲明(<?xml version="1.0" encoding="UTF-8"?>) 開啟或關閉取決於消費者是否期望序言。並決定空節點是否應該自關閉 <tag/> 或擴展至 <tag></tag> - 一些嚴格的消費者關心。
一切都運行客戶端。轉換器是一個用 TypeScript 編寫的無依賴序列化程序,而不是遠端 API 周圍的包裝器。這比聽起來更重要:API 回應和設定檔通常包含存取令牌、客戶記錄和內部標識符,以及 "免費線上轉換器和報價;將您的有效負載發佈給某人'伺服器是一個等待發生的資料外洩。因為這個永遠不會進行網路調用,所以您可以安全地轉換敏感數據,並且它可以在沒有任何連接的情況下繼續工作。如果瀏覽器工具中的隱私是您考慮的事情 - 如果您處理其他人'數據,它應該是 - 我在 中寫了更多關於它的內容 資料隱私工具指南.
JSON 與 XML:快速比較
它有助於保留兩種格式'考慮到權衡,因為 原因 映射需要諸如此類的約定 @ 和 #text XML 可以表達事物 JSON can't,反之亦然。
| 方面 | 傑森 | XML |
|---|---|---|
| 屬性 | 沒有本土概念 | 一流(<tag attr="v">) |
| 數組/列表 | 本土的 [ ] 類型 |
重複的兄弟姊妹元素 |
| 評論 | 不允許 | <!-- ... --> 支持的 |
| 命名空間 | 沒有 | 完整的命名空間支援 |
| 混合內容(文字+元素) | 尷尬 | 本土的 |
| 模式/驗證 | JSON 模式(附加) | XSD、DTD、RELAX NG(成熟) |
| 冗長 | 緊湊 | 更冗長(結束標籤) |
| 今天的典型用途 | Web API,配置 | SOAP、來源、文件、企業 |
的 @ 存在前綴來橋接 "屬性&引用;行;重複標記規則橋接 "數組&引用;行;和 #text 橋接"混合內容"行。一旦您將映射視為跨越這些特定間隙的橋樑,它就不再感覺任意了。
JSON 到 XML 的往返是否乾淨?
大多數情況下,是的 - 以及#39;s 由設計。我的 json 到 xml 和 XML 到 JSON 工具共享相同 @ 屬性前綴和 #text 內容鍵,因此轉換 XML → JSON 並返回通常會複製原始文件。如果您'正在建立一個必須雙向移動資料的管道,那麼這種對稱性值得依賴。
往返變得模糊的地方是同一個地方,每個 JSON/XML 映射變得模糊:順序和混合內容。 JSON 物件是正式無序的,因此轉換器可能無法保留不同名稱元素的確切兄弟順序。 XML 將文字和子元素交織在一起(<p>Hello <b>world</b>!</p>)沒有'沒有乾淨的 JSON 表示,並且以近似形式返回。有時出現一次、有時多次出現的元素是不明確的 - 它是單一值還是一個值的數組?這些是 '任何特定工具中的錯誤;他們'這是兩個資料模型 don't 完美重疊這一事實所固有的。了解接縫的位置可以讓您設計 JSON,以便轉換保持無損:在事物是否始終是數組方面保持一致,並儘可能避免混合內容。
如果您經常使用 JSON,它'值得在整個轉換系列中建立流暢性 - 我收集了我在轉換中達到最多的那些 JSON 工具終極指南,而且更廣泛 編碼工具指南 涵蓋格式轉換器適合日常工作流程的位置。對於相反方向和相鄰格式, JSON 到 YAML 轉換器 還有一個平原 JSON 格式化程式 完善集合。
將 JSON 轉換為 XML 時常見的錯誤
一些陷阱 I'擊中或看著其他人擊中:
將數組索引視為標籤名稱。 如果你看到 <item0>, <item1> 在某人's輸出中,他們錯誤地建構了轉換器。數組變成 重複 標籤與 相同的 名稱,取自數組's 鍵。
忘記只能有一個根。 將多鍵物件直接遞送到序列化器而不進行包裝,會產生多個頂級元素,這不是一個格式良好的文件。包裹它。
跳過轉義&引用;因為資料看起來很乾淨。&引用; 它看起來很乾淨,直到一個產品描述包含一個&號或一個 <. 永遠逃避;永遠不要假設。
將結構化資料放入屬性中。 屬性保留原語。如果您嘗試將嵌套物件推入 @- 前綴鍵,正確的轉換器將(並且應該)刪除它或忽略它,因為那裡'沒有有效的 XML。而是將其建模為子元素。
高級:為消費者選擇縮排和聲明
讓我免於的一個習慣是與整合合作夥伴反覆反覆討論:匹配輸出 完全正確 達到消費者的期望,然後停止。一些 SOAP 端點拒絕包含位元組順序標記或意外序言的文件;其他人則需要 <?xml ... ?> 聲明和 415 你沒有它。一些提要驗證器想要漂亮的列印、縮排的 XML 供自己調試;大多數生產運輸希望將其縮小。我不想爭論,而是產生規範要求的任何變體。 That'為什麼轉換器會暴露縮排(包括縮小選項)、聲明切換和自關閉行為作為一流的控制 - 它們'不是裝飾,它們'是決定挑剔的消費者是否第一次接受您的文件的旋鈕。
問號
如何將 json 轉換為 xml？
將 JSON 貼到編輯器中,然後按轉換。物件鍵變成 XML 元素,陣列變成重複標籤,結果看起來可以複製或下載。沒有上傳 - 轉換發生在您的瀏覽器中。
json 屬性在 XML 中是如何表示的？
按照慣例,任何以 " 開頭的物件鍵;@"前綴寫為其父元素上的屬性,而不是子元素。例如,{"book":{"@id": "bk101", "標題&引用;: "..."}} 成為
轉換器如何處理 JSON 陣列？
數組的每個元素都作為共享鍵's 名稱的重複兄弟元素發出。所以{"tags":{"tag": ["a", "b"]}}產生
#text 密鑰是做什麼用的？
當元素同時需要屬性和文字內容時,文字會儲存在 "#text" 鍵。 {"標題&引用;:{"@lang": "en", "#text": "你好&引用;}} 成為
我可以獲得縮小的 XML 而不是縮排的輸出嗎？
是的。 將縮排設為 0（Minify），轉換器在單行中發出整個文件，標籤之間沒有空格。 這對於有效載荷大小很重要的 SOAP 請求或提要很有用；當您需要可讀的文件時，切換回 2 或 4 個空格。
不有效的 XML 元素名稱的鍵會發生什麼事？
XML 元素名稱不能包含空格,不能以數字、連字符或句點開頭,並且排除大多數標點符號。違反這些規則的鍵將被清理 - 無效的字元將成為下劃線,並在需要時添加前導下劃線 - 因此輸出始終解析,即使您的 JSON 鍵不支援 XML。
JSON 是否使用 XML 到 JSON 工具往返 XML？
對於常見的結構,它確實如此。此工具和 XML 到 JSON 工具共享相同的 "@"屬性前綴和"#text"內容鍵,因此將 XML 轉換為 JSON 並返回通常會再現相同的文件。與任何 XML/JSON 映射一樣,與順序無關的細節和混合內容是微小差異的常見來源。
在這裡轉換敏感的 JSON 是否安全？
是的。轉換器是普通的 JavaScript,完全在您的瀏覽器中運行 - 您貼上的任何內容都不會傳輸到伺服器、記錄或儲存。這使得 API 回應、設定檔和包含令牌或個人資料的記錄變得安全,並且它可以在沒有網路連線的情況下繼續運作。
