JSON 驗證器

為什麼需要 JSON 驗證器？

JSON (JavaScript Object Notation) 雖然語法簡單，但它的規定非常「嚴格」。在寫程式時，只要少了一個逗號、多了一個引號，或者不小心使用了單引號，整個 JSON 檔案就會無法解析 (Parse Error)，導致網頁掛掉或 API 請求失敗。

瀏覽器的錯誤訊息通常只會冷冷地告訴你 Unexpected token at position 154，讓你在一大片程式碼中大海撈針。這款 JSON 驗證器 就像是資料的拼字檢查機，它能精準地用紅字標示出錯誤發生在哪一行，並告訴您該如何修正。

核心原理：比 JavaScript 更嚴格的標準

很多人誤以為「JavaScript 物件」就是 JSON，其實兩者有微妙但致命的差異。驗證器的核心工作就是檢查是否符合 RFC 8259 標準。

三大常見語法地雷

大部分的驗證失敗都源自於以下三個習慣差異：

1. 引號限制 (Quotes)：

   • 錯誤： { name: "John" } (Key 沒引號) 或 { 'name': 'John' } (用單引號)。

   • 正確： { "name": "John" }。在 JSON 中，Key 和 String 都必須用雙引號。

2. 尾隨逗號 (Trailing Commas)：

   • 錯誤： [1, 2, 3, ]

   • 正確： [1, 2, 3]。陣列或物件的最後一個項目後面，絕對不能有逗號（這在 JS 中是被允許的，但在 JSON 中不行）。

3. 數值格式：

   • 錯誤： 0123 (禁止開頭補零) 或 NaN。

   • 正確： JSON 不支援八進位或 undefined, NaN 等特殊值。

常見的應用場景

1. 修正 "Unexpected token" 錯誤

當您的網頁主控台 (Console) 跳出這個紅字錯誤，通常代表後端回傳的 JSON 爛掉了。

• 將那串爛掉的字串貼進驗證器，它會立刻告訴您：「第 5 行缺少一個 }」或「第 10 行出現了非法的單引號」。

2. 設定檔除錯 (Config Linting)

許多專案設定檔 (如 .eslintrc, package.json, tsconfig.json) 都是 JSON 格式。

• 如果您手動修改了設定，存檔後專案卻跑不動，通常是因為不小心破壞了 JSON 結構。

3. API Payload 測試

在使用 Postman 或 cURL 發送 POST 請求前，先用驗證器檢查您的 Request Body 格式是否正確，可以避免伺服器回傳 400 Bad Request 錯誤。

常見問題 (People Also Ask)

Q1：這跟 JSON Formatter 有什麼不同？

• Validator (驗證器)： 重點在**「找錯誤」**。它會告訴您「格式對不對」。

• Formatter (格式化)： 重點在**「變漂亮」**。它會幫您縮排，但如果您格式有錯，它通常無法運作。

• 本工具通常結合了兩者功能：先驗證，通過後再美化。

Q2：為什麼 { key: "value" } 驗證失敗？

因為 Key 必須加雙引號。

• 這是在 JavaScript 程式碼中合法的寫法 (Object Literal)，但在 JSON 資料交換格式中是不合法的。

• JSON 要求嚴格的 { "key": "value" }。

Q3：驗證器會幫我自動修復錯誤嗎？

視情況而定。

• 對於簡單的錯誤（如單引號變雙引號、移除多餘逗號），有些工具可以嘗試自動修復 (Auto-fix)。

• 但對於結構性錯誤（如缺少半個括號），工具通常只能「指出位置」，因為它無法猜測您的原本意圖。

Q4：註解 (Comments) 是合法的嗎？

不合法。

• 標準 JSON 不支援 // 註解 或 /* 註解 */。

• 如果您的檔案包含註解，驗證器會報錯。

• (註：VS Code 的 settings.json 支援註解，那是因為它使用的是 JSONC - JSON with Comments，非標準 JSON)。