JSON 出錯了，該修改哪裡？

使用工具

• 開啟此工具: JSON 格式化與驗證

先看右括號前面

開啟 JSON 格式化與驗證，輸入以下內容，保留最後的逗號後執行。先重現錯誤，再只改一個位置，確認失敗原因。

{"name":"Ada","count":2,}

count 值後面的逗號表示後面還有成員，但接著卻關閉了物件。因此右括號附近報錯，不一定是括號本身有問題，應檢查它前面的分隔符。

{"name":"Ada","count":2}

再次執行後，檢查 name 是否仍為 Ada，count 是否仍為數字 2。不要只看成功提示，還要確認修復過程中保留了應有的資訊。

一次只改一處，反而更快

長設定出現多個錯誤時，很容易想批次取代引號與逗號。但一個未閉合的引號就可能改變後面整段的剖析方式。應先從最前面的報錯開始，檢查附近少量字元。

1. 自行保留原始資料的工作副本。
2. 檢查第一個錯誤及其前面的引號、分隔符與括號。
3. 只做一處不改變意義的最小修改，再次執行。
4. 成功後檢查數值與筆數，必要時比較修改前後。

看起來相似的引號也可能不同

{"name":"Ada"}
{'name':'Ada'}
{“name”:“Ada”}

第一個使用 JSON 的雙引號，第二個是單引號，第三個是排版用彎引號。它們外觀相近，卻不是同一字元。經文件或訊息複製後失效時，值得先檢查這裡。

不要把全文單引號盲目取代為雙引號。O'Reilly 中的撇號屬於內容，不是分隔符。必須區分字串邊界與字串本身，否則會破壞正確資料。

修復語法時，是否把數字改成了字串？

{"count":2,"enabled":false}
{"count":"2","enabled":"false"}

加引號後能剖析，不代表接收程式就接受：它可能要求數字或布林值。字串 false 不等於布林值 false。格式化成功不能證明符合應用的型別與業務要求。

相反，00123 這樣的會員編號可能應以字串保留前導零。應判斷它是用於運算的數量，還是用於識別的名稱。改型別前先查介面約定，比猜測更可靠。

格式化讓結構更容易看清

{"items":[{"name":"pen","quantity":2},{"name":"book","quantity":1}],"currency":"JPY"}

以兩空格縮排格式化後，可以清楚看到 items 的兩個元素。每個 name 與 quantity 屬於同一商品，currency 在陣列之外。縮排只是呈現原有關係，並未新增欄位。

壓縮會減少字串之外多餘的空白與換行。名稱內部的空格仍是資料，不能一起刪掉。檢查時用格式化，需要精簡表示時用壓縮，兩者都不等於修改實際值。

長編號要核對到最後一位

{"id":9007199254740993}

這個範例用於找出肉眼容易忽略的精度問題。SheepDev 的格式化使用保留精度的剖析器，會保留末尾的 3。但交給試算表軟體或其他程式後，仍需再次核對所有位數。

數字已被改動後再格式化，無法恢復遺失的原始位數，這也是保留原文的原因。改成字串可能適合某些約定，但是否允許更改接收規範，需要另外判斷。

值裡面需要換行或引號時

{"message":"He said \"hello\".\nNext line."}

句子裡包含引號時，容易弄不清值在哪裡結束。這裡的反斜線讓後面的引號成為內容，而非字串結束符。反斜線加 n 表示換行。編輯器中可見的兩個字元與讀取後的換行，是不同的表示方式。

不要把跳脫換行與直接在帶引號的 JSON 字串內貼入實際換行混為一談。為消除錯誤而刪掉換行，可能改變原文意義或顯示效果。格式化只是整理表示方式，不代表可以改寫內容。

貼上的內容真的只有 JSON 嗎？

複製整行紀錄時，可能連時間與 INFO 前綴一起複製。開發者主控台也可能顯示物件的說明形式，而非回應本文。剖析失敗不代表 API 已損壞，應先確認複製的是 JSON 本身還是外層顯示。

從聊天或文章複製範例時，還可能帶上程式碼區塊標記或「輸入範例」標題；也可能沒有選到最後一個括號。先重新選取本文並檢查首尾，再修改內容，可避免修復一個只由複製造成的問題。

連續貼上兩個物件，會自動成為陣列嗎？

{"id":1}
{"id":2}

每行單獨可以有效，但合在一起不一定是一份 JSON 文件。JSON Lines 等逐行儲存形式採用不同的組織規則。SheepDev 的 JSON 格式化不會自動把獨立文件合併成新結構。

[{"id":1},{"id":2}]

陣列需要方括號與元素間的逗號。但應因接收端要求陣列才轉換，而不是只為消除報錯。逐行紀錄可能應保留原格式。修復語法與改變資料結構，是兩項不同工作。

格式化成功後，還要檢查什麼？

能讀取的 JSON 不一定是正確設定。quantity 為負數，或欄位誤寫成 quantitiy，語法上仍可能有效。必填欄位與範圍必須對照接收系統的規範檢查。

交付修復時，可以說明「刪除了最後的逗號，name 與 count 未變」，而不只是「可以格式化了」。明確原因與檢查範圍，能避免下一位同事重複排查。

參考資料

• RFC 8259 — JSON (在新分頁開啟)
• MDN — JSON.parse() (在新分頁開啟)

使用工具

• JSON 格式化與驗證