若要檢查你的 JSON 格式是否正確，可使用瀏覽器型的 JSON 驗證工具，立即驗證語法、精準指出錯誤的行列位置，並檢視資料結構。 JSON（JavaScript Object Notation）是一個輕量級的資料格式，常用於設定檔、API 回應與資料儲存。它的簡潔性使其廣受歡迎，但即使是小型的語法錯誤——例如缺少逗號、鍵未加引號，或結尾多餘的逗號——都可能導致解析失敗。與 XML 或 YAML 不同，JSON 並沒有內建的錯誤恢復機制，因此單一錯誤就可能讓整個應用程式當機。例如，設定檔中若缺少一個右大括號，可能導致應用程式無法啟動；而 API 回應中若有未加引號的鍵，則可能讓前端崩潰。手動檢查 JSON 錯誤既耗時，特別是在大型檔案中；像 JavaScript 的 JSON.parse() 或 Python 的 json.loads() 這類工具只能告訴你 JSON 是否無效，但無法說明錯誤的位置或原因。這時，專屬的 JSON 驗證工具便不可或缺。
JSON 驗證工具能立即提供回饋以解決這個問題。你不必再猜測錯誤可能出現在哪裡，只需將 JSON 貼入工具，即可看到明確的結果：「Valid JSON」，或是一則紅色錯誤訊息，標示出解析失敗的精確行列位置。例如，若你在兩個陣列項目之間忘了加逗號，驗證工具會反白標示該行，並告知缺少了什麼部分。部分驗證工具還提供結構報告，顯示巢狀物件的深度、鍵的數量，以及值的資料型別。這有助於你確認 JSON 不僅符合語法規則，也符合預期的結構。例如，若你的 API 預期接收一個物件陣列，卻不小心送了帶有巢狀陣列的物件，結構報告便會標示出這個不相符之處。驗證工具還能抓出常見的錯誤，例如使用單引號而非雙引號，或是加入標準 JSON 並不允許的註解。
為什麼會發生 JSON 語法錯誤
JSON 語法錯誤通常源於對格式規則的小疏忽或誤解。以下是最常見的原因：
- 未加引號的鍵： JSON 要求所有鍵都必須以雙引號包裹。例如，
{ name: "Alice" }是無效的，但{ "name": "Alice" }是正確的。 - 結尾的逗號： JSON 不允許在物件或陣列最後一個項目之後加上逗號。例如，
{ "a": 1, "b": 2, }是無效的。 - 單引號： JSON 字串僅允許使用雙引號。
{ 'name': 'Alice' }會失敗，但{ "name": "Alice" }是有效的。 - 缺少的逗號： 物件或陣列中的項目必須以逗號分隔。例如，
{ "a": 1 "b": 2 }是無效的。 - 註解： JSON 不支援註解，這與 JavaScript 物件不同。任何
//或/* */語法都會導致錯誤。 - 不正確的資料型別： JSON 僅支援字串、數字、布林值、陣列、物件，以及
null。像undefined、函式或日期等型別是不被允許的。
這些錯誤可能在手動編輯時悄悄出現，特別是在從文件、API 或程式碼片段複製 JSON 時。即使是經驗豐富的開發人員，也可能漏看一個結尾的逗號或未加引號的鍵，尤其是在大型或深度巢狀的 JSON 檔案中。例如，一個數百行的設定檔中，可能在某處中埋藏著一個漏掉的引號，造成整個檔案在生產環境中靜默失敗。JSON 驗證工具能透過精準標示錯誤位置，省去這種憑空猜測的工作。
如何在瀏覽器中驗證 JSON
使用像 JSON Validator 這類瀏覽器型工具來驗證 JSON，是一個相當簡單的流程。請依照下列步驟檢查你的 JSON 格式並修正任何錯誤：
- 開啟 JSON 驗證工具： 在瀏覽器中前往 /dev/json-validator/。此工具可離線運作，因此在初次載入之後，你不需要持續連網。
- 貼上或輸入你的 JSON： 從檔案、API 回應或程式碼編輯器中複製 JSON，並貼入輸入框中。如果你想測試小型片段，也可以直接輸入。
- 檢視驗證結果： 若你的 JSON 符合正確語法，驗證工具會立即顯示綠色的「Valid JSON」訊息。若有錯誤，則會看到紅色訊息，並標示出解析失敗的行列位置。例如，若你忘記加上右大括號，錯誤訊息可能顯示為：
Expected '}' at line 5, column 1。 - 修正錯誤： 透過行列編號找出 JSON 中的問題。常見的修正方式包括補上缺少的逗號、引號或大括號。若錯誤訊息不夠明確，可參考工具的結構報告以取得更多線索。
- 查看結構報告： 對於有效的 JSON，驗證工具會提供一份結構報告，內容包含：
- 型別（Type）： 根層級為物件或陣列。
- 深度（Depth）： JSON 的最大巢狀層級。深度巢狀的 JSON 較難以除錯，因此這個資訊有助於你評估其複雜度。
- 鍵的數量（Key count）： 根物件或陣列中的鍵總數。這對於確認 JSON 是否包含預期數量的項目非常實用。
- 複製或儲存驗證過的 JSON： JSON 通過驗證後，你可以將其複製回檔案或應用程式中。部分驗證工具也允許你將驗證過的 JSON 下載成檔案。
這個流程只需數秒鐘，省去了手動除錯的需求。例如，若你正在處理的 API 回應傳回了無效的 JSON，你可以將其貼入驗證工具，修正錯誤後重新送出修正過的資料，整個過程完全不需撰寫任何程式碼。該驗證工具也相當適合用於設定檔，例如 Node.js（package.json）或 Docker（compose.json）所使用的設定檔，這些檔案中的語法錯誤可能會讓應用程式無法啟動。
何時該使用 JSON 驗證工具
JSON 驗證工具在從開發到生產的多種情境中都相當實用。以下是一些常見的使用案例：
| 情境 | 為何驗證工具有幫助 | 範例 |
|---|---|---|
| API 開發 | API 經常回傳 JSON，無效的回應可能導致用戶端應用程式當機。驗證工具能確保你的 API 回傳格式正確的資料。 | 你正在建立一個回傳使用者資料的 REST API。在部署前，你會先驗證 JSON 回應，確認其符合預期的結構描述。 |
| 設定檔 | 許多工具（例如 Docker、Node.js、Kubernetes）皆使用 JSON 作為設定格式。單一語法錯誤就可能導致工具無法執行。 | 你的 package.json 檔案無法安裝相依套件。驗證工具標示出 dependencies 物件中缺少的一個逗號。 |
| 資料遷移 | 在不同系統間搬移資料時，JSON 是常見的格式。驗證工具能在匯入新系統前，確保匯出的資料是有效的。 | 你正在將顧客資料從舊系統匯出到新的 CRM 系統。驗證工具在匯入前確認 JSON 檔案沒有錯誤。 |
| 除錯前端應用程式 | React 或 Angular 等前端框架經常會解析來自 API 的 JSON。無效的 JSON 可能導致應用程式崩潰或顯示錯誤的資料。 | 你的 React 應用程式無法正確渲染使用者資料。驗證工具顯示 API 回應中含有一個結尾的逗號，因而導致 JSON 解析失敗。 |
| 測試 LLM 輸出 | 大型語言模型（LLM）有時會產生帶有語法錯誤的 JSON，例如缺少引號或鍵未加引號。驗證工具能在這些問題造成影響前先行攔截。 | 某個 LLM 為聊天機器人產生了 JSON 回應。驗證工具標示出缺少的右大括號，讓你能在回應送出給使用者前先行修正。 |
在上述每個情境中，JSON 驗證工具都能節省時間並減少挫折感。你不必手動掃描檔案，也不必依賴反覆試錯的除錯方式，而是能立即獲得回饋，並在錯誤影響應用程式前將其修正。
常見的 JSON 錯誤與修正方式
即使是經驗豐富的開發人員也會遇到 JSON 錯誤。以下列出一些最常見的問題及其修正方式：
- 未加引號的鍵： JSON 要求所有鍵都必須以雙引號包裹。例如，
{ name: "Alice" }是無效的。加上引號即可修正：{ "name": "Alice" }。 - 結尾的逗號： JSON 不允許在物件或陣列最後一個項目之後加上逗號。例如，
{ "a": 1, "b": 2, }是無效的。請移除結尾的逗號：{ "a": 1, "b": 2 }。 - 單引號： JSON 字串僅允許使用雙引號。例如，
{ 'name': 'Alice' }是無效的。將單引號替換為雙引號：{ "name": "Alice" }。 - 缺少的逗號： 物件或陣列中的項目必須以逗號分隔。例如，
{ "a": 1 "b": 2 }是無效的。請加上逗號：{ "a": 1, "b": 2 }。 - 註解： JSON 不支援註解。請將任何
//或/* */語法從 JSON 中移除。 - 不正確的資料型別： JSON 僅支援特定的資料型別（字串、數字、布林值、陣列、物件，以及
null）。例如，{ "date": new Date() }是無效的。請將該值轉換為字串：{ "date": "2024-01-01" }。 - 未跳脫的特殊字元： 含有引號、反斜線或控制字元的字串必須進行跳脫。例如，
{ "text": "He said, "Hello"" }是無效的。請跳脫引號：{ "text": "He said, \"Hello\"" }。
這些錯誤可能難以察覺，特別是在大型或複雜的 JSON 檔案中。JSON 驗證工具能自動標示出錯誤的精確位置並建議修正方式。例如，若你正在處理一個深度巢狀的 JSON 物件，卻忘了加上右大括號，驗證工具會告訴你是哪一行缺少了大括號，省去你手動計算大括號或中括號的麻煩。
JSON 驗證器 vs. 程式碼編輯器 Linter
許多程式碼編輯器（例如 VS Code 或 Sublime Text）內建 JSON linter，能即時標示語法錯誤。雖然這些工具很有幫助，但與專門的 JSON 驗證器相比，它們有以下限制：
| 功能 | JSON 驗證器 | 程式碼編輯器 Linter |
|---|---|---|
| 錯誤精確定位 | 會標示出解析失敗的確切行數與欄位，並附上清楚的錯誤訊息。 | 可能只會標示出錯誤的大致範圍，不會顯示具體的欄位編號。 |
| 結構報告 | 提供 JSON 結構的詳細報告，包含深度、鍵數與資料型別。 | 不會提供結構報告，僅檢查語法。 |
| 離線存取 | 在初次載入後即可離線運作，確保你的資料隱私。 | 部分擴充功能或外掛需要網際網路連線。 |
| 跨平台 | 可在任何現代瀏覽器中運作，不受作業系統或編輯器影響。 | 綁定特定編輯器或 IDE；並非所有平台皆可使用。 |
| 其他工具 | 通常會整合相關工具，例如 JSON 格式化工具或差異比對工具，提供完整的工作流程。 | 僅提供 lint 功能；格式化或比對 JSON 需要另外的工具。 |
雖然程式碼編輯器的 linter 方便進行即時回饋，但專門的 JSON 驗證器能提供更詳盡的錯誤報告與額外功能，例如結構分析。舉例來說，如果你正在處理一個大型 JSON 檔案，而編輯器的 linter 只能標示錯誤的大致範圍，驗證器則能精確指出錯誤的所在行數與欄位，幫你節省時間。此外，結構報告能協助你確認 JSON 是否符合預期的結構綱要，這對於 API 回應或設定檔特別有用。
進階 JSON 驗證技巧
熟悉基本的 JSON 驗證後，你可以運用以下進階技巧來簡化工作流程：
- 驗證 JSON 結構綱要：如果你需要處理 API 或設定檔，可以使用 JSON 結構綱要驗證器來確保你的 JSON 符合預先定義的結構。這對於強制 API 回應或設定檔的一致性很有幫助。例如，你可以定義一個綱要，要求 API 回應必須包含特定欄位，例如
id、name和email，然後據此驗證你的 JSON。 - 在 CI/CD 中自動化驗證：將 JSON 驗證整合到持續整合／持續部署（CI/CD）流程中，在錯誤進入正式環境前就先行攔截。GitHub Actions 或 GitLab CI 這類工具可以在每次提交時執行 JSON 驗證器，確保無效的 JSON 永遠不會進入線上環境。
- 使用格式化工具提升可讀性：驗證完 JSON 之後，使用JSON 格式化工具將其美化排版，以便除錯。這對於大型或複雜的 JSON 檔案特別有幫助，因為手動格式化非常耗時。例如，你可以將 JSON 貼到格式化工具中、設定縮排層級，然後把格式化後的輸出複製回檔案。
- 比對 JSON 檔案：如果你有多個版本的 JSON 檔案，可以使用差異比對工具逐行進行比對，協助你找出編輯過程中所造成的變更或錯誤。例如，當你更新設定檔時，可以比對新舊版本，確保沒有不小心刪除或修改重要的欄位。
- 批次驗證 JSON：如果有多個 JSON 檔案需要驗證，可以使用腳本或工具來批次處理。例如，你可以寫一個簡單的 Node.js 腳本，讀取目錄中所有的 JSON 檔案，使用像是
ajv的函式庫進行驗證，並回報所有錯誤。
這些技巧能幫助你在開發過程的更早階段就抓到錯誤，減少除錯所花費的時間。例如，在 CI/CD 流程中自動化 JSON 驗證，可以確保無效的 JSON 永遠不會進入正式環境；而使用格式化工具與差異比對工具，則能讓你更輕鬆地檢視與比對 JSON 檔案。
相關指南：如何格式化 JSON 以提升可讀性與除錯效率。
如果你正在權衡各種選項，無需程式碼、在瀏覽器中解碼 JWT 權杖對此有詳細說明。
如果你正在權衡各種選項，如何在程式設計與資料處理任務中使用 ASCII 碼對此有詳細說明。
如果你正在權衡各種選項，在 Excel 中直接將 CSV 轉換為 JSON 且不遺失資料對此有詳細說明。