JSON 比對

比對兩份 JSON 的步驟

1. 放進兩份文件. 直接貼上,或在兩個方框下方各選一個 .json 檔案,也可以把檔案拖到方框上。兩份都在這個分頁裡解析。
2. 看路徑. 每一列是一處差異:在哪個路徑、是新增、刪除還是變更,以及兩邊各是什麼值。
3. 寫法差異不會出現. 鍵的順序不同、縮排不同,一列都不會產生。清單上只有真正改變內容的地方。
4. 帶走清單. 下載成 differences.csv,或按複製貼進工單、程式碼審查的留言裡。

為什麼文字比對會把同一份 JSON 判成全部不同

{"b":1,"a":2} 和 {"a":2,"b":1} 是同一個物件。 幾乎每個 JSON 程式庫重新輸出時,鍵的順序都可能變;再加上縮排兩格或四格、檔尾有沒有換行, 用逐行比對的工具去看同一筆資料的兩次匯出,常常整頁都是紅的。

這一頁先把兩邊都解析成資料結構,再比較解析後的值。鍵的順序與格式不會產生任何一列差異, 剩下的才是會讓接收端行為改變的不同。

中文被跳脫成 \uXXXX,也算同一個字

很多後端預設把非 ASCII 字元跳脫輸出,所以 API 回應裡的「台北市」常常長成 "\u53f0\u5317\u5e02",而另一個系統匯出的同一筆資料寫的是原本的中文。 純文字比對會說這兩行不同。這裡解析之後兩者是同一個字串,不會被列成差異; 結果表裡顯示的也是解開後的中文,不是一串跳脫碼。

反過來,真正不同的字元一定會被列出來。全形數字 "１２３" 和半形 "123"、 「台」和「臺」,在 JSON 裡都是不同的字串,這個工具不會替你把它們視為相同。

陣列看順序,物件不看

JSON 物件的鍵是一個集合,順序沒有意義;陣列的元素是一個序列,順序本身就是意義。 所以 [1,2,3] 對 [3,2,1] 會回報兩個位置有變更,而上面那兩個物件被判定為相同。 在陣列尾端多加一個元素,只會出現一列 path[2] 的新增,不會把後面全部判成改寫。

型別照實比,不幫你轉換

5 和 "5" 不同,false 和 0 不同, null 和「這個鍵不存在」也不同。這幾組正是 API 在小改版時最常悄悄改掉、 而寬鬆比對會藏起來的東西,這裡全部會列出來。

每一處差異都有地址

結果是一張清單,不是左右兩欄讓你自己對。每一列都帶著路徑,用 / 分隔層級、 陣列索引寫在中括號裡,例如 billing/regions[2],可以直接貼進工單,或拿去原始檔搜尋。 比較大的子樹會摘要成 {4 fields}、[9 items] 這種形式, 告訴你形狀變了,底下的列再告訴你怎麼變。

這個工具不做的事

• 不合併。它只回報差異,不會產生第三份文件。
• 不依 id 對應陣列元素。陣列一律依位置比。兩份檔案裡是同一批紀錄、但排序不同時,先依鍵排序再比; 如果資料本來就是表格,比較兩個 Excel 可以用鍵欄對應列。
• 不修復壞掉的 JSON。解析失敗時會顯示解析器指出的位置,不會猜。尾端多一個逗號、用了單引號,都會被這樣擋下來。
• 超過 16 位數的數字不保證精準。瀏覽器的 JSON 解析把數字讀成雙精度浮點數, 19 位數的訂單編號如果是以數字(沒有引號)寫的,兩個只差最後幾位的值可能被判成相同。用字串寫的編號不受影響。
• 選檔案時一律以 UTF-8 讀取。JSON 的標準編碼本來就是 UTF-8;如果手上有 Big5 存的 .json, 請先在編輯器裡另存成 UTF-8,或直接把內容貼進方框。

資料留在這個分頁

會被拿去比對的 JSON,通常是 API 回應、設定檔或匯出資料 —— 裡面常有金鑰、權杖和客戶紀錄。 兩份文件都由你電腦上執行的 JavaScript 解析與比較,沒有任何請求帶著它們送出。

如果同一個介面每個月都要拿新舊兩份回應核對一次,那就不只是一次比對了。TableDI 2 是一套桌面軟體，專做每期都要重來一遍的表格工作：來源、規則和交付方式存成一個作業，下個月把新檔案放進去再跑一次。全部在你自己的電腦上執行。