針對 OIC 整合工作，XML 轉 JSON 最可靠的預覽方式是使用瀏覽器內的轉換器，該工具會接收一份格式良好的 XML 文件，套用明確的物件結構，然後在不將酬載傳送到伺服器的情況下複製結果。XML 轉 JSON 轉換器會使用瀏覽器原生的 XML DOMParser 來解析貼上的標記，一開始就會拒絕任何 DOCTYPE 宣告，並序列化出可重現的 JSON 字串，讓您可以與 OIC adapter 範例一起閱讀。由於轉換完全在用戶端進行，文件從不離開這個頁面，這在您處理設定片段、內部端點回應或不應經由第三方服務傳遞的整合測試固定資料時，使工作流程變得相當實用。解析層與接收端的 OIC mapping 之間的這種分離，在您稽核為什麼某筆酬載在生產環境被拒絕時也很有用：您可以在本機重現結構，而無須重建整合，然後將輸出與 adapter 預期的結構描述進行 diff 比對。
每個 XML 轉 JSON 工具都帶有對於如何攤平屬性、文字與重複兄弟節點的既定立場。本工具採用明確的約定，而不是宣稱遵循某個通用標準，且該約定已被記錄下來，因此您可以判斷輸出是否符合 OIC 流程在另一端所預期的契約。根元素會成為最上層的 JSON 鍵，屬性會被收集在一個 @attributes 物件下，而結構化元素內的直接文字則會被擷取在 #text 下。重複的兄弟節點名稱會依照文件順序變成陣列；單一子節點則保持為單一值。命名空間前綴會保留在元素與屬性名稱上，因此一個名為 soap:Body 的元素會維持為 "soap:Body" 而不會被剝除。這些選擇都不是推斷出來的，而是轉換器契約的一部分；同一份 XML 貼上兩次會產生位元組完全相同的輸出，這正是您在比對參考固定資料時所想要的結果。
轉換器產生的物件結構
輸出是一份純粹的 JSON 文件，其最上層對應到 XML 的根元素。在該文件內部，四條小規則就能涵蓋您從 OIC adapter、傳入的網路服務或範例 WSDL 訊息所貼上的幾乎所有酬載：
- 根元素作為最上層鍵。 根元素名稱會成為唯一的最上層欄位，因此根元素為 <order> 的文件會產生 { "order": ... }。
- 屬性置於 @attributes 之下。 元素上的每個屬性都會被歸入一個以 @attributes 為鍵的物件；該元素的其他子節點則保持在與一般欄位相同的層級。
- 文字置於 #text 之下。 純文字的元素會變成字串。當元素同時具有屬性或子節點時，直接的文字會被移入 #text，以便結構性的子節點仍可依名稱被定址。
- 重複的兄弟節點作為陣列。 兩個以上共用名稱的相鄰元素會依照來源順序合併成 JSON 陣列；僅出現一次則會保持為單一物件或字串。
命名空間會保留為本地名稱的一部分，因此 <ns:customer ns:id="42">Alice</ns:customer> 會讀取為 { "ns:customer": { "@attributes": { "ns:id": "42" }, "#text": "Alice" } }。不會刪除任何前綴、不會將任何命名空間提升為獨立的欄位，也不會擷取任何命名空間 URI —— 轉換器不會解析任何外部結構描述，這對於那些引用僅供內部使用之命名空間 (不應由線上工具回傳以解析) 的文件來說，是最安全的行為。
準備 XML 文件以進行轉換
在貼上任何內容之前，請將文件精簡為單一格式良好的酬載。請移除任何 <!DOCTYPE> 宣告，因為轉換器會明確拒絕它，以避免解析外部實體或 DTD。註解與處理指令不會被帶入 JSON，因此保留它們並不會改變結果，但清理來源能讓您更輕鬆地將轉換後的 JSON 與原始內容進行比對。背後使用的瀏覽器解析器 —— 如 MDN DOMParser 文件 所述 —— 遵循 XML 1.0 所定義的規則，因此命名空間前綴、CDATA 區段以及解析為單一字元的實體參考，都會在轉換器走訪樹狀結構之前由解析器處理。
轉換器每次轉換最多接受 200,000 個字元的來源。任何超過此限制的內容都應予以修剪、分塊，或在版本控制的應用程式中透過串流解析器進行處理，而不是貼進瀏覽器欄位。如果您的 XML 來自被最小化的單行字串或螢幕擷取匯出而難以閱讀，請先將其送入 XML 格式化工具，以便在進行 JSON 轉換前確認其結構，同時也讓您在清理過程中刪除的任何一行都能一目了然。
為 OIC 範例在本機將 XML 轉換為 JSON
轉換本身是一段簡短且嚴謹的步驟序列。每個步驟的存在都有其原因，因為轉換器不會對格式錯誤的輸入、外部資源或部分輸出進行猜測。
- 在新的瀏覽器分頁中開啟 XML 轉 JSON 轉換器，並閱讀欄位層級的提示，以便了解哪個控制項負責縮排、哪個會觸發轉換。
- 將一份格式良好的 XML 文件貼入來源欄位。如果文件開頭是 <!DOCTYPE> 一行，請刪除該行並再次確認其餘部分仍可解析為 XML。
- 選擇一種縮排樣式 —— 若要將酬載貼入請求主體，請使用 compact；若希望 JSON 與 XML 對齊以便檢閱，則使用四空格縮排。
- 選取 Convert to JSON。若解析器回報錯誤，請修正 XML 並重試；對於格式錯誤的輸入，轉換器不會傳回部分文件。
- 檢查輸出是否符合 @attributes 與 #text 的約定，並確認重複的兄弟元素已依照文件順序轉為 JSON 陣列。
- 複製 JSON 並將其貼入您的 OIC 範例、請求 stub 或測試固定資料中。過程中沒有任何資料被上傳 —— 解析與序列化都在頁面內完成。
特定 XML 特性如何對應至 JSON
若您確切知道每個 XML 建構會變成什麼，瀏覽轉換結果會更加輕鬆。下表摘要說明了在 OIC adapter 範例中最常出現之情況的約定。
| XML 建構 | JSON 表示法 | 備註 |
|---|---|---|
| 僅含屬性的元素 | 僅含 @attributes 的物件 | 若沒有字元資料，則不會新增 #text 欄位。 |
| 空元素 <tag/> | 空字串 "" | 若存在屬性，則會出現在 @attributes 下，該元素本身則無字串值。 |
| CDATA 區段 | 納入 #text | CDATA 文字會被視為字元資料；分隔符號不會保留。 |
| 註解與處理指令 | 會被捨棄 | 它們永遠不會出現在 JSON 輸出中。 |
| 重複的兄弟元素 | 依來源順序的陣列 | 順序很重要且會被精確保留。 |
| 單一兄弟元素 | 單一值，而非陣列 | 單一出現的元素絕不會被包裝成只有一個元素的陣列。 |
| 混合內容 (文字加上子元素) | #text 加上具名子元素 | 文字與子元素之間的精確交錯不會被保留。 |
| 含命名空間前綴的名稱 | 逐字保留 | 前綴與本地名稱以冒號連接為欄位名稱。 |
針對 OIC 準備工作的關鍵在於：沒有任何內容會被默默地從一種 JSON 型別改寫為另一種。諸如 007 的識別碼會保持為字串 "007"；諸如 01234 的郵遞區號不會變成整數 1234；XML 中以文字呈現的 true/false 值也不會被強制轉型為 JSON 布林值。這種詞彙層級的紀律是有意為之的，因為 XML 對文字的型別沒有標準，而大多數接收端的系統都依賴原始字串來處理識別碼、代碼列表與參考編號。
轉換器不適合的情境
瀏覽器工作流程對於小型、範圍明確的轉換是一把利器，但它無法取代完整的 XML 管線。下表對比了適合使用瀏覽器內轉換器的情況，與應交由版本控制的解析器、結構描述驗證器或隨整合程式碼一同出貨的 ETL 作業來處理的情況。
| 以下情況請使用瀏覽器轉換器 | 以下情況請使用版本控制的解析器 |
|---|---|
| 文件在 200,000 字元的輸入上限以內 | 文件經常超過上限，或是會以串流形式持續送入 |
| 您僅需要用於檢閱或測試資料的結構性外觀 | 您必須依據 XSD、Schematron 或業務規則進行驗證 |
| XML 由您團隊界定範圍或由已知來源產生 | XML 來自不受信任的外部系統，需要進行淨化處理 |
| 不需要保留無損的混合內容 | 接收端的系統要求精確的文字對元素順序 |
| 您想要可重現的參考輸出，以便與 OIC mapping 進行比對 | 您需要可在無人值守下執行的測試涵蓋轉換路徑 |
若適用右欄的任何情況，相同的 XML 仍屬於您的專案，但應交由行為受您掌控的程式庫來處理，而轉換器的輸出則應作為測試用的參考結構，而非實際執行的路徑。XML 轉 JSON 轉換器絕不會擷取結構描述、DTD、外部實體、命名空間、樣式表或遠端資源，因此即便它是不適合的工具，它也不會是那種在您不知情的情況下代替您執行網路呼叫的工具。
對接收端系統驗證 JSON
一旦取得 JSON，請將其送入 JSON 驗證器 以捕捉任何結構上的疏漏；此外，若接下來需要的是可讀性，請將同一份文件交給 JSON 格式化工具 進行美化排版，然後再將各欄位與 OIC mapper 進行比對。瀏覽器的解析器與轉換器都可能成功，但仍產生與您整合預期不符的結構，因此對 @attributes、#text 與陣列邊界進行最終的視覺檢視，是工作流程的一部分，而非可選步驟。當您確實發現不符之處 —— 例如，接收端系統要求每個重複的子節點即使僅出現一次也必須為陣列 —— 請調整您自家 mapping 層的約定，而不是期望轉換器為它所遇到的每個結構描述做出讓步。
若要深入了解，請參閱 以 JavaScript 將 CSV 轉換為 HTML 表格：安全的工作流程。
若要深入了解，請參閱 在 GST 離線工具之外將 Excel 轉換為 JSON 的方法。