文字與資料格式 指南
JSON 尾端逗號與解析錯誤：用格式化工具定位問題
標準 JSON 不允許物件或陣列最後一項後面再放逗號；但錯誤也可能來自單引號、未跳脫換行或括號不成對。格式化工具可縮小範圍，不能代替理解資料。
更新日期:
要解決的問題
設定檔在 JavaScript 中能執行，貼到 API 或其他語言卻解析失敗；錯誤訊息指向下一行，讓人誤刪正確內容。這通常是把寬鬆的程式語法與嚴格的 JSON 格式混在一起。
適合誰使用
適合處理 API 回應、設定檔、匯入資料與需要在不同程式語言間交換 JSON 的開發者、分析師與內容編輯。
公式與概念
先把 JSON 複製到格式化工具，保留原始檔不直接覆蓋。RFC 8259 定義 JSON 語法；尾端逗號不是標準 JSON 的一部分，即使某些語言或編輯器會寬容接受，也不代表 API 或資料庫會接受。
錯誤位置常落在真正問題的下一個 token。看到「unexpected character」時，回看前一個逗號、引號或括號；不要只刪掉錯誤訊息指出的那一行。格式化成功後，再用語法高亮檢查鍵和值是否仍屬於預期結構。
JSON 的字串要使用雙引號，換行、反斜線與控制字元需要正確跳脫。註解、`undefined`、`NaN` 與函式不是標準 JSON 值；若來源是程式碼，先序列化或移除程式專用語法。
格式化只是語法檢查，不會確認欄位名稱、數字單位或個資是否正確。通過後仍要對照 API schema、資料筆數與必要欄位；若 JSON 要交給別人，附上版本和來源。
若檔案很大，先縮小到能重現的區段，但不要只保留錯誤行而破壞上下文。修正後用完整檔再驗證一次，並以唯讀副本保存修正前後差異，方便回溯。
修正後用實際 API 或匯入器做少量整合測試，保存回應與測試資料版本，以區分語法和型別問題。
若錯誤只在某個編輯器出現，確認它是否使用 JSON5；交付標準應以真正接收資料的解析器為準。
對外分享前移除測試個資與秘密值，確認跳脫後的換行與反斜線仍代表原意；格式化工具不會替你做安全審查。
最後用接收端的錯誤處理與少量真實資料做回歸測試，確認鍵名、順序依賴與數字精度未被改變，再替換正式檔。
把修正後檔案交給第二位使用者重新格式化一次，確認工具不再報錯且輸出一致，再提交正式環境。
操作步驟
- 複製 JSON 並記下來源、版本與解析錯誤訊息。
- 用 JSON 格式化工具定位第一個語法錯誤。
- 從錯誤位置向前檢查尾端逗號、雙引號與括號。
- 移除註解、單引號、未跳脫控制字元與程式專用值。
- 格式化後對照 schema、筆數與必要欄位。
- 用目標 API 或匯入器做一次小範圍測試，再保存完整版本。
實際範例
API 設定在 JavaScript 中能讀取，但服務端回報第 18 行錯誤。格式化工具顯示第 17 行陣列最後一項後多了一個逗號；修正後又發現一個單引號字串，團隊依序改成雙引號並跳脫換行，最後用測試 endpoint 驗證必要欄位。
常見錯誤
- 只刪除錯誤訊息指出的行，沒有回看前一個 token。
- 把 JavaScript 物件或帶註解設定檔當成標準 JSON。
- 使用單引號、`undefined` 或未跳脫換行。
- 格式化成功就直接交付，沒有驗證 schema 與必要欄位。
- 直接覆蓋原始檔，失去修正前後的可追溯差異。
推薦工具
相關指南
常見問題
- JSON 最後一項後面可以加逗號嗎？
- 標準 JSON 不允許物件或陣列最後一項後的尾端逗號。某些程式語言接受寬鬆寫法，但跨系統交換時應移除。
- 為什麼錯誤行號通常不是問題所在？
- 解析器常在讀到下一個無法理解的 token 才報錯，因此要回看前一個逗號、引號或括號。格式化工具能協助縮小範圍，但仍要理解結構。
- JSON 可以寫註解嗎？
- 標準 JSON 不包含註解語法。若設定工具支援 JSON5 或自訂格式，輸出給 API 前要轉成標準 JSON 並重新驗證。
下一步
把 JSON 複製到格式化工具定位語法，再用目標 API 和 schema 驗收，不直接覆蓋原始檔。