SheepDev

資料格式與結構化資料

修改設定後,哪些值改變了?

使用工具

修改者說只改了逾時時間,審查頁面卻顯示數十行變化。格式化或匯出時重新排列鍵,就可能出現這種情況。逐行追蹤所有變化,反而容易漏掉真正需要檢查的設定。

JSON 結構比較會讀取兩份輸入,列出欄位的新增、刪除與修改。但「相同」有多種意義:文字一致、鍵與值一致,或應用行為一致。以下用虛構的小設定觀察這些界線。

兩份輸入描述的是同一範圍嗎?

比較前,確認輸入對應的時間、環境與範圍。完整設定與局部更新比較時,可能出現大量刪除,因為工具無法知道欄位是省略還是刪除。擷取子樹時,兩份輸入應選擇相同上層,並記錄範圍。

API 回應還可能帶有每次變動的時間或識別碼。應判斷它們是否屬於本次調查,而不是為了減少差異就刪除。只有時間變化與問題無關時才適合排除。保留原始工作副本,並記錄排除欄位與理由,方便說明檢查範圍。

空白也有兩種角色:值外的縮排不改變結構,"test " 結尾的空白卻屬於字串。接收端是否移除它是另一回事,不要為了消除差異就統一 trim。工具也可能報告數字表示差異,應區分將 1 與 1.0 視為相同金額,與檢查儲存形式是否相同。

先比較沒有改變設定的範例

左側放修改前,右側放修改後,將以下兩段分別貼到對應輸入欄。文字排列不同,但都包含相同的三個設定。這個範例交換左右不影響結論,實際審查新增與刪除時則應保持方向一致。

左側:修改前
{"timeout":30,"region":"test","enabled":true}
右側:只調整鍵順序
{"enabled":true,"region":"test","timeout":30}

執行後差異總數為 0。只改變值外面的縮排或空白,結果也不變。這表示結構比較沒有找到變化,不代表檔案逐位元組相同,因此雜湊仍可能不同。審查設定與確認檔案完全一致,應使用不同工具。

只改一個值,觀察變化方向

將右側輸入替換為此內容
{"enabled":true,"region":"test","timeout":60}

這裡只發生一次變化:30 變為 60。查看 before 與 after,確認方向。結果路徑可能包含數值內部表示產生的層級,因此不要只憑結尾判斷欄位名稱,應結合上層 timeout 與前後值閱讀。診斷路徑不一定就是原 JSON 中可直接修改的文字。

交換左右後,變化就成為 60 到 30,新增與刪除也會反轉。如果想找修改後消失的欄位,卻把版本放反,就會誤讀為新增。分享結果時註明左右分別是哪一版,可減少誤解。

欄位不存在,不等於值為 null

左側輸入
{"label":"demo","note":null}
右側輸入
{"label":"demo","memo":""}

note 被刪除,memo 被新增。空字串、null、欄位不存在,即使介面都顯示空白,也不是同一狀態。應用可能在省略設定時使用預設值,而在 null 時關閉功能。工具能找出差別,但不能決定哪種行為符合你的需求。

同樣,把 true 改為字串 "true" 不是單純改寫外觀。差異少不代表移轉安全:一次型別變化可能比數十行重排更影響行為。重點是接收應用如何解讀該欄位。

陣列開頭只加一項,為什麼出現多個差異?

左側:原清單
{"steps":["build","test","deploy"]}
右側:開頭新增一項
{"steps":["prepare","build","test","deploy"]}

考慮陣列順序時,會比較相同位置的元素。索引 0 從 build 變為 prepare,索引 1 從 test 變為 build,索引 2 從 deploy 變為 test,最後再新增 deploy。人看起來是插入一項,位置比較卻得到三次修改與一次新增,不能把四處差異理解成四次編輯操作。

這不是自動依 id 配對商品或使用者的紀錄比較工具。大量位置變化時,先檢查前段是否有插入或刪除。應結合原資料的識別碼與相鄰元素,而不是把陣列索引當成穩定身分。

忽略順序前,先想想順序的意義

左側:標籤
{"tags":["blue","green"]}
右側:相同標籤反向排列
{"tags":["green","blue"]}

考慮順序時有兩次修改,忽略順序後差異為零。只關心有哪些標籤時很有用,但處理步驟或優先順序陣列使用同一設定,就可能隱藏重要變化。先 test 再 deploy 與先 deploy 再 test,元素相同,流程卻不同。

忽略順序並不會去重,同一標籤出現兩次仍不同於一次。目前選項也會排序巢狀陣列,無法只忽略外層、保留內層流程。包含多個陣列時,建議先查看有序比較,再把無序比較當成補充。

零差異不代表行為得到保證

相同設定在不同應用版本、環境變數或外部檔案下,也可能產生不同行為。未輸入的資訊不在比較範圍內,工具也不會依差異數量評估風險。它回答的是較窄的問題:在所選比較條件下,這兩份 JSON 有哪些差別?

結束審查前,記錄修改的值、新增與刪除的欄位,以及是否忽略陣列順序。遇到意外差異,可以先格式化兩份輸入,再檢查對應部分。若還需檢查必填欄位或型別,應確認支援範圍後使用 JSON Schema 驗證。找出差異與決定是否接受變更,是兩項不同判斷。

參考資料

使用工具

指南 →