JSON 常見錯誤大全：原因、範例與修復方法

JSON 看似簡單，但一個引號、逗號或反斜線放錯位置，就可能讓整份文件無法解析。解析器通常只會回報無法繼續的位置，而那裡不一定是真正出錯的地方。

本指南整理 API 串接、設定檔與日誌中常見的 JSON 問題。每一類都包含原因、錯誤範例、正確寫法與安全的修復建議。你可以先用 JSON 驗證器 定位第一個錯誤；若輸入只是接近 JSON，可用 JSON 修復工具 產生候選結果，再逐項複核。所有處理都在瀏覽器本機完成。

快速原則：保留原始輸入，從第一個錯誤開始修復；每修一處就重新驗證。

一、先確認內容是不是標準 JSON

合法 JSON 只支援物件、陣列、字串、數字、布林值與 null。物件鍵和字串必須使用雙引號；註解、undefined、NaN、函式和日期物件都不是 JSON。

二、鍵名或字串沒有使用雙引號

JavaScript 物件允許單引號和未加引號的鍵，但標準 JSON 不允許。

{ name: 'Alice', 'role': 'admin' }

應改為：

{ "name": "Alice", "role": "admin" }

不要直接將全文的單引號全部取代為雙引號；字串內的撇號和跳脫字元可能因此損壞。

三、屬性或陣列元素之間少了逗號

{
  "name": "Alice"
  "active": true
}

正確寫法是在前一個值後加入逗號：

{
  "name": "Alice",
  "active": true
}

看到 Expected ',' 時，先檢查錯誤位置前面的完整值，而不只是被標示的字元。

四、物件或陣列末尾多了逗號

標準 JSON 不允許最後一個成員後保留逗號。

{
  "name": "Alice",
  "active": true,
}

刪除 true 後的逗號即可。接著可使用 JSON 美化工具 重新解析並統一縮排。

五、缺少右括號、右方括號或結束引號

Unexpected end of JSON input 表示解析器讀到結尾時，物件、陣列或字串仍未關閉；也可能代表網路回應或複製的日誌遭到截斷。

{
  "user": {
    "name": "Alice",
    "tags": ["admin", "editor"]
}

外層物件還少一個右大括號。但若資料來自 API，不要立刻猜測並補上括號；先確認傳輸是否完整。工具能補語法符號，卻無法還原遺失的欄位。

六、字串包含非法跳脫字元

JSON 以反斜線表示跳脫。雙引號、反斜線、換行和定位字元應寫成 \"、\\、\n 與 \t。

錯誤：

{
  "path": "C:\new\reports",
  "message": "He said "hello""
}

正確：

{
  "path": "C:\\new\\reports",
  "message": "He said \"hello\""
}

字串也不能直接跨行；需要換行時應使用 \n。

七、JSON 中含有註解

標準 JSON 不支援 // 或 /* ... */ 註解。請移除註解，或將必要說明轉為明確欄位。不要用簡單的正規表示式刪除所有 // 後內容，否則可能誤刪 https:// 網址。

八、使用 JSON 不支援的值

布林值與空值只能寫成小寫的 true、false 和 null。Python 的 True、False、None，以及 JavaScript 的 undefined、NaN、Infinity 都不合法。

{ "active": True, "nickname": None, "score": NaN }

可能的候選修復是：

{ "active": true, "nickname": null, "score": null }

但 NaN 應變成 null、字串或直接移除，必須依業務規則決定。

九、一份文件串接了多個物件

日誌常使用每行一個 JSON 物件的 NDJSON／JSON Lines 格式。每行合法，不代表全文是一份合法 JSON。

{"id": 1, "status": "ok"}
{"id": 2, "status": "failed"}

若目標系統需要標準 JSON，應轉為陣列，並在物件之間加入逗號：

[
  {"id": 1, "status": "ok"},
  {"id": 2, "status": "failed"}
]

十、JSON 被重複編碼

若解析成功後得到一整段充滿反斜線的字串，資料可能被序列化了兩次：

"{\"name\":\"Alice\",\"active\":true}"

第一次解析得到字串，第二次才得到物件。通常應從資料產生端修正為只序列化一次，但也要先確認 API 契約是否刻意以字串儲存 JSON。

十一、重複鍵：語法可能合法，結果卻不可靠

{
  "role": "user",
  "role": "admin"
}

許多解析器會保留最後一個值，但不同語言和安全元件的行為可能不同。應在輸入階段拒絕重複鍵，並修正資料產生端。普通 JSON.parse 完成後，遭覆寫的值通常已經遺失。

十二、超大整數發生精度遺失

JavaScript 的 Number 無法精確表示所有大於 9007199254740991 的整數。資料庫 ID 或雪花 ID 可能在解析後改變。

{ "userId": 9007199254740993 }

識別碼較安全的傳輸方式是字串：

{ "userId": "9007199254740993" }

已經失去精度的數字再轉為字串，也無法恢復原始數字。

十三、可靠的排查順序

1. 保存原始文字，不要覆蓋唯一副本。

1. 確認複製、日誌或傳輸沒有截斷內容。

1. 用 JSON 驗證器 找到第一個錯誤。

1. 檢查錯誤位置之前的引號、逗號和括號。

1. 每修一處就重新驗證。

1. 用 JSON Diff 比較原始內容與候選結果。

1. 用 JSON 樹狀檢視器 檢查巢狀結構和型別。

1. 語法通過後，繼續驗證必填欄位與業務規則。

付款、權限、醫療、稽核或資料庫遷移資料不應在無人確認時自動改寫。工具可以處理明確的語法錯誤，不能猜測遺失值或業務含義。

總結

多數 JSON 解析錯誤來自引號、逗號、括號、跳脫字元和非標準值。保留原文、從第一個錯誤開始，並在每次修改後重新驗證。語法通過後，仍要檢查重複鍵、大整數、型別與資料語意。你可以先使用 JSON 修復工具，再透過 JSON 驗證器 和 JSON Diff 獨立複核。