開發者工具·語法轉換器
JSON 到 XML 轉換：根元素、陣列和無效標記名稱
· 工作原理
json xml 資料格式
JSON 可以是一個裸數組，其鍵以數字開頭或包含空格，而 XML 不允許。這篇文章解釋了轉換器必須對根、陣列和名稱做出的決定，以便您可以預測輸出。
沒有名稱的數組 - 頂級 JSON 數組，必須成為單根 XML 文件，以及出現的包裝元素
JSON 可以以 `[1,2]` 開頭； XML 不能以兩個對等文件元素開頭。因此，ToolAcre 將根數組包裝在選取的根名稱中，並將每個成員寫入重複的 `<item>` 子項。警告命名了該約定，因為來源中不存在包裝器和項目名稱。
選擇 `numbers` 會產生一個包含兩個專案元素的 `<numbers>` 檔案元素。轉換是確定性的，但不是規範的：另一個系統可能需要 `<number>` 或包含屬性的集合。故意設定根並將結果與接收者所需的 XML 合約進行比較。
XML 只需要一個根 - 為什麼每次轉換都會發明或要求一個根元素名稱
XML 檔案必須只有一個根元素。僅有一個普通頂級密鑰的 JSON 物件可以直接使用該密鑰。多鍵物件、陣列、標量或 null 沒有提供單一名稱，因此編寫者將其括在 `root` 中，除非使用者提供另一個合法名稱。
包裝器規則在序列化之前實現並作為警告出現。它不是由模式發現的，也不宣告 `<root>` 對舊服務有意義。命名包絡是整合設計的一部分，而轉換器僅保證其自身映射下的格式良好的結構。
陣列沒有 XML 等效項 - 每個項目重複一個元素，以及如何表示標量數組和數組數組
數組成為重複元素。在文件根目錄中，成員在包裝器下使用 `<item>` 。在物件內部，儲存在 `line` 下的陣列將成為重複的 `<line>` 同級陣列。物件數組創建帶有子欄位的重複元素；嵌套數組沒有域名，並繼承構建器產生的通用結構。
在稍後的 XML 到 JSON 讀取之後，這將失去一個陣列成員和具有相同元素名稱的標量之間的區別。 XML 提供出現次數，而不是獨立的陣列標記。如果穩定的基數很重要，則架構或應用程式映射必須提供它；通用序列化程式無法僅從 JSON 形狀的元素名稱來證明這一點。
不能是元素名稱的鍵 - 以數字開頭、包含空格或標點符號、或以“xml”開頭的名稱，以及轉換器如何重新命名或轉義它們
大綱建議轉換器可以重新命名或轉義非法鍵。 ToolAcre 明確拒絕了他們。帶有空格的鍵、以數字或連字符開頭的鍵或以保留字母 `xml` 開頭的鍵會觸發 `UNSUPPORTED_SHAPE` 並命名有問題的路徑。靜默重命名會產生 XML ，它不符合任何商定的模式。
有效名稱可以以字母、底線或命名空間樣式前綴開頭，並可以在開頭後包含數字、句點、底線、冒號和連字符。屬性鍵僅使用 `@` 作為 JSON 約定；其餘屬性名稱必須通過相同的檢查。有意重命名來源金鑰或選擇其他目標格式。
不能是元素名稱的鍵將被拒絕，從不重命名或轉義
數字和布林值被序列化為元素文字，因此它們的 JSON 類型不再由 XML 宣告。預設反向讀取器因此傳回字串。 Null 在這裡沒有 XML 表示：它變成一個空元素，與空字串無法區分，並作者報告有多少值經歷了該更改。
這意味著 `{ "a": null, "b": "" }` 可以產生兩個讀回類似的空元素。稱該往返過程為無損是錯誤的。屬性 `#text` 和 `#cdata` 保留轉換器的結構約定，但它們不會加入一般 XML 類型系統。
類型變成 XML 文字，而 null 變成承認的空元素歧義
使用 `{"order":{"@id":"A-7","customer":"Ada","line":[{"sku":"P1","qty":2},{"sku":"P2","qty":1}],"note":null}}`。單一 `order` 鍵變成根，`@id` 變成屬性，每個行物件變成重複的 `<line>`，null 變成帶有警告的空 `<note></note>`。
在禁用推理的情況下讀回輸出。屬性 id、數量和文字值是字串，而 line 是數組，因為它出現了兩次。這展示了精確支援的逆，同時暴露了遺失的 null 和數字類型。接收順序模式可能需要其他名稱或順序，本範例未對此進行驗證。
這不包括什麼 - 產生與給定 XSD 或命名空間匹配的 XML ，這需要手動編寫映射
編寫者不使用 XSD、分配命名空間 URI 或根據業務模式決定元素順序。它寫入 XML 宣告，並從不發出 DOCTYPE。包含名稱空間前綴的鍵按字面意思保留，但這不是名稱空間解析或前綴宣告正確的證明。
產生特定服務接受的 XML 可能需要屬性、序列約束、選擇群組和限定名稱。使用其當前架構或檔案來建立該映射。通用轉換適用於檢查和簡單的以資料為中心的文件，不能取代合約感知序列化。
重點：在依賴它之前預測它的形狀 - 以及語法轉換器面板如何顯示 JSON 檔案產生的 XML 結構
根據結果預測信封、項目名稱和類型損失。 ToolAcre 包裝缺少一個根的值、重複數組、將 `@` 鍵映射到屬性、用空文字替換 null 並拒絕非法名稱而不是猜測替換。每個不明顯的變化都會出現在輸出或警告中。
測試包含頂級數組、重複記錄、空值、數字文字和尷尬鍵的最小物件。拒絕是需要手動映射的有用證據。成功的檔案仍然需要實際接收者的驗證，因為格式正確的 XML 和模式有效的 XML 是不同的宣告。
接收者接受樣本後，僅在映射預計保留的地方添加反向檢查。屬性和重複子項可以根據 ToolAcre 自己的約定進行往返，而 null 和標量類型則不能。記錄這種差異可以防止將成功的快樂路徑範例推廣到您的整合可能產生的每個訂單檔案。