資料格式與結構化資料

大型 ID 的末位變了，如何檢查 JSON 精度？

使用工具

訂單號沒有計算，只複製後末位就變了。解析成數字本身就可能遺失精度。應區分原 JSON 的數字字元與解析後數值，先用兩個相鄰虛構 ID 檢查能否區分。

必須區分的兩個數字

{"first":9007199254740992,"second":9007199254740993}

直接貼入 JSON 整形工具，保精度解析器會保留末位 2 與 3。不是只檢查無報錯，還要檢查輸出完整值不同，不要只看縮略標籤或分組顯示。

其他程式回傳的 second 也變成末位 2 時，流程某處已遺失資訊。本工具正確不保證前後應用也正確。分別比較原始回應、解析後、顯示值與儲存重讀值，定位首次變化。

以字串傳遞 ID

{"first":"9007199254740992","second":"9007199254740993","code":"00123"}

長 ID 與 00123 都是字串，適合保留識別碼的各位與前導零。但只改發送端可能違反接收端數字型別要求，應統一 API 與儲存契約，並把型別變化與格式化分開說明。

把 00123 寫成 JSON 數字不是保留補零識別碼的有效辦法。一旦轉成 123，就無法推斷原寬度。固定寬度是契約的一部分，應先決定欄位是數量還是精確匹配代碼。

左右各輸入一個物件

{"id":9007199254740993}
{"id":9007199254740992}

左右各放一個物件，不要兩行合成一個輸入。確認 ID 變化，再把一側改成帶引號 ID 比較型別。保精度內部表示可能顯示 value 等輔助路徑，不能當成 API 原欄位。

1 與 1.0 數學值相同但寫法不同，結構差異報告取決於比較規則。若要求精確識別碼文字，僅數值相等不夠，應同時檢查固定字串與 JSON 型別。

CSV 可含正確數字，但試算表可能讀成不精確數值。其他格式轉換的支援範圍也不同於 JSON 整形。應逐步用虛構邊界值測試，不能把一個工具的保證擴展到整個流程。

已捨入的一般數字再轉 BigInt 也無法恢復尾數。兩個原值合成一個後，輸出無法判斷來源，恢復需要捨入前資料。應修正入口而非手改顯示識別碼。

除 123 外，還測相鄰大數、字串大識別碼、前導零代碼。數字欄位應註明上限與拒絕範圍。全部改字串並非通用答案，參與運算的數量可能必須是數值，應按欄位語意選擇。

分享時同時給出原 JSON、操作、結果與預期型別。「遺失精度」不能區分顯示截斷與儲存變化。若僅標籤縮略，應檢查顯示層。具體觀察能幫助找準修復位置。