JSON 轉 XML
在瀏覽器裡把 JSON 轉換成格式良好的 XML。可自定義根元素名稱，選擇是否輸出 XML 宣告，縮排支援 2 空格、4 空格或不縮排。
把 JSON 樹安全地對映成元素。 貼上 JSON 即可得到格式良好的 XML。陣列會展開成重複元素，非法的鍵名會被修正為合法元素名，宣告和縮排則完全由你決定。
XML 輸出
如何把 JSON 對映成 XML 而不把自己繞進去
兩套模型本來就對不齊
JSON 有六種值型別——物件、陣列、字串、數字、布林和 null——而且每一種都自帶型別資訊。XML 只有一種原始型別：文本。其餘一切都是由元素和屬性搭出來的結構。兩者之間並不存在官方對映規則，這也是你遇到的每個轉換器行為都略有不同的原因。
這裡採用的是最常見、也最可預期的一套約定。物件變成一個元素，它的鍵成為子元素。字串、數字和布林值變成包含其文本形式的元素。null 變成空元素。剩下的就是陣列，而 XML 里根本沒有對應物：通行的做法是把父元素按條目數重複一遍，於是 {"item": [1, 2]} 變成 <item>1</item><item>2</item>，而不是憑空造一個接收方 schema 並不預期的包裝元素。
不是每個 JSON 鍵都能當元素名
XML 元素名要滿足 NCName 規則：以字母或下劃線開頭，之後可以是字母、數字、連字元、句點和下劃線。不能有空格，不能有斜槓，不能以數字開頭，也不能以任意大小寫的 xml 開頭——那是規範保留的字首。
JSON 鍵則沒有這些限制，它就是任意字串，真實場景裡到處都是 "user name"、"2024" 和 "@type"。原樣輸出這些名字，得到的文件任何解析器都不會接受。因此非法字元會被替換成下劃線，以數字開頭的名字前面會補一個下劃線。這一步是有損的，所以如果下游真的在意元素名，請先在 JSON 裡把鍵改好，而不是交給轉換器去猜。
宣告、縮排，以及什麼改動是安全的
對 UTF-8 文件來說 <?xml ... ?> 宣告是可選的，預設時解析器就按 UTF-8 處理。當檔案要落盤、要通過 HTTP 提供、或者要交給嚴格的企業流水線時，就帶上它；當這段內容要嵌進一份更大的文件時就去掉，因為第二個宣告是致命錯誤。
縮排是更微妙的選擇。和 JSON 不同，XML 元素內部的空白屬於內容本身，所以美化在技術上確實改變了文件：原本內容是 Ada 的元素，現在裝的是換行、若干空格、Ada、換行和更多空格。大多數 schema 會忽略這些差異，但簽名校驗、xml:space="preserve" 區塊以及對空白敏感的格式不會。自己閱讀時用縮排，交給機器消費時切回壓縮輸出。
常見問題
我的 JSON 會被上傳嗎？
不會。整個解析和序列化過程都用瀏覽器內建的 JSON 函式在本地完成，不會向任何伺服器傳送資料。
JSON 陣列怎麼表示？
把父元素按條目數重複一遍。{"item": [1, 2]} 變成 <item>1</item><item>2</item>，這也是多數 XML schema 預期的寫法。
鍵名不是合法元素名時會怎樣？
非法字元會替換成下劃線，以數字開頭則在前面補一個下劃線。如果元素名必須精確，請先在 JSON 裡改好鍵名。
為什麼輸出裡沒有 XML 宣告？
它是可選項，由核取方塊控制。沒有宣告時解析器預設按 UTF-8 處理；而且當輸出要嵌入另一份文件時，宣告必須去掉。
值會被寫成屬性嗎？
不會。所有值都輸出為元素文本。屬性無法從純 JSON 推斷出來，要做這個判斷需要本工具並不具備的 schema 資訊。
縮排會改變文件含義嗎？
嚴格說會，因為元素內部的空白屬於內容。大多數 schema 會忽略，但涉及簽名或對空白敏感的 XML 請使用壓縮輸出。