驗證 JSON 檔案的意思是，將其文字內容透過嚴格的剖析器執行，檢查它是否符合 IETF 為 JSON 資料交換格式所制定的規範 RFC 8259 中定義的語法。當每個鍵與字串都被雙引號包裹、方括號與大括號成對匹配，且註解、尾端逗號或無法表示的值（例如 NaN）沒有出現在剖析器不預期的地方時，該檔案即通過驗證。判定結果是非黑即白的：JSON 要能被標準剖析器解析，不然就是無法解析；而當這個二元結果附帶解析失敗的精確行號與欄位時，就變得格外實用。具備位置資訊的驗證工具，會把含糊的「unexpected token」（未預期的字符）抱怨，轉換成你能在編輯器中直接跳轉的座標。針對這種以語法為先的聚焦檢查，免費的 JSON Validator 會執行瀏覽器內建的原生 JSON 剖析器，並回傳綠色的「Valid JSON」結果，或是一則紅色訊息，標明失敗發生所在的行號與欄位。

how to validate json file
How to Validate a JSON File in Your Browser

JSON 驗證工具實際檢查的內容

JSON 由 RFC 8259 定義，並沿用 ECMA-404 的語法，而該語法刻意設計得相當嚴格。驗證工具本質上就是一個剖析器，嘗試將你的文字讀取為一個完整的 JSON 值——物件、陣列、字串、數字、true、false 或 null——要嘛成功，要嘛在第一個無法解析的字符處停下來。最常見的錯誤，都來自於那些看起來可有可無、實際上卻是強制性的規則：

  • 物件的鍵必須以雙引號包裹；未加引號或使用單引號的鍵會被拒絕。
  • 字串值同樣必須使用雙引號，絕不能使用單引號，且每個控制字符都必須經過跳脫處理。
  • 陣列或物件最後一個元素之後不允許出現尾端逗號。
  • 任何形式的註解，包括 // 與 /* */，都不屬於 JSON 語法的一部分。
  • NaN、Infinity 與 -Infinity 都不是有效的 JSON 數字。
  • 每個開方的方括號、大括號與引號，都必須依正確順序對應關閉。

由於這些規則與所有標準剖析器強制執行的規則一致，驗證工具通過語法檢查的結果，會與你的 JavaScript 執行環境、Node.js 以及大多數 JSON 函式庫在正式環境中能接受的內容相符。這裡沒有寬鬆的猜測，也沒有自動修復——驗證結果精確反映你的下游程式碼將套用的語法。

破壞 JSON 檔案的常見語法錯誤

大多數「invalid JSON」的回報，都源自少數反覆出現的錯誤模式。下表將每個模式與其違反的規則，以及剖析器會產生的錯誤訊息類型相互對照。

檔案所包含的內容RFC 8259 的要求剖析器常見的訊息
{ name: "Alice" }物件的鍵必須使用雙引號。Unexpected token n
{ 'name': 'Alice' }字串與鍵只能使用雙引號。Unexpected token '
[1, 2, 3,]陣列最後一個元素之後不能有尾端逗號。Unexpected comma in array
// a note註解不屬於 JSON 的一部分。Unexpected token /
{"x": NaN}僅允許有限的十進位數字。Unexpected token N
{"a": 1每個開方的大括號都必須有對應的關閉大括號。Unexpected end of JSON input

這六種模式佔了絕大多數的驗證失敗案例。用肉眼辨識它們能加速除錯；當你無法辨識時，驗證工具所回報的行號與欄位訊息會代勞。

如何在瀏覽器中驗證 JSON 檔案

這個驗證工具的設計目的，是為了快速且精準地回答一個問題：這份 JSON 是否實際有效？若無效，確切是在哪個位置發生錯誤？三個步驟即可涵蓋大多數工作流程。

  1. 將你的 JSON 貼上或在輸入框中輸入。檔案內容只會保留在頁面中——不會上傳到任何遠端服務。
  2. 立即讀取驗證結果。綠色的「Valid JSON」訊息代表文字解析無誤。紅色訊息則會回報剖析器放棄解析時所在的行號與欄位，例如「Invalid JSON at line 3, column 7.」。
  3. 若 JSON 有效，請檢視結構報告。驗證工具會顯示頂層類型、最大巢狀深度、鍵的總數、物件與陣列的數量，以及字元數，協助你對資料結構進行健全性檢查。

典型的工作流程是：貼上、讀取結果、修正，再重複此過程，直到檔案解析無誤為止。由於驗證工具僅專注於正確性與結構診斷，它會刻意保持你的文字內容不變——若你需要經過美化排版或最小化的輸出，則屬於另一項獨立任務，可交由像 JSON Formatter 這類的工具處理。

解讀結構報告

綠色的結果代表檔案可被解析，但無法告訴你該檔案是否符合你程式碼所預期的結構。結構報告以五項數值補足這項缺口，值得你一覽：

  • 頂層類型——物件、陣列、字串、數字、布林值或 null。這是最快速確認你貼上的是正確檔案的方式。
  • 最大巢狀深度——檔案中陣列或物件最深的層級。有助於發現意外造成的失控巢狀。
  • 鍵的總數——每個巢狀物件中所有鍵的總和。若數字突然飆升，通常代表資料集發生重複或擴增。
  • 物件與陣列的數量——檔案中各包含多少個這類容器。
  • 字元數——檔案的精確長度，在你需要控管承載量大小時相當實用。

在大多數除錯情境中，深度與鍵的數量是能真正抓出問題的兩項數值：某個回應的深度從 4 跳到 14，或鍵的數量暴增了一個數量級，通常代表你開啟了錯誤的端點，或是不小心重複了某個段落。

為何在瀏覽器本地進行檔案驗證很重要

JSON 檔案經常包含你不太願意與遠端服務分享的內容——API 權杖、工作階段 cookie、客戶資料、內部設定檔。JSON Validator 完全在瀏覽器內執行，使用引擎內建的 JSON.parse，因此檔案內容絕不會離開你的裝置。這讓它適合用於驗證正式環境的承載資料、匯出的使用者資料，或是你不會貼進任何雲端工具的測試環境設定檔。

當你正在除錯一份從記錄檔封存或同事分支中抽取出來的單一可疑檔案時，這項特性同樣有所助益。你可以貼上內容、讀取結果、在編輯器中修正、再次貼上，並在過程中反覆執行，完全不需要任何網路往返。若經過驗證的檔案最終需要以更小、單行的形式發布，你可以在驗證後將其交給本地最小化工具；該工作流程的逐步說明收錄在 這份於瀏覽器中壓縮 JSON 檔案的指南。

JSON 驗證的限制與注意事項

語法的有效性是個二元且範圍明確的檢查，了解它的界線相當重要。在實務上有三項值得注意的事項：

  • 龐大的整數會喪失精度。JSON 數字會以 IEEE-754 雙精度浮點數讀取，僅能精確表示至 2^53 為止的整數。通過「驗證」僅代表這些數字能被解析，無法保證 19 位數的識別碼仍保持完整。
  • 結構描述的有效性是另一個層面的問題。語法的有效性代表檔案可以被解析；而結構描述的有效性，則代表解析後的值符合預期的結構。若你的下游程式碼預期接收帶有特定欄位的物件，語法檢查無法發現該欄位是否遺漏。
  • 深層巢狀的檔案會被回報，而非導致當機。病態的巢狀結構會被攔截並顯示出來，而不會讓瀏覽器陷入停滯，因此即使是面對惡意輸入，你依然能取得驗證結果。

這個驗證工具的判定依據，與正式環境中剖析器所實作的 RFC 8259 語法完全一致，因此當它判定檔案有效時，這個結果與你在 Node 中使用 JSON.parse、Python 的 json 模組，或是命令列中的 jq 所得到的答案相同。完整規範值得一讀，如果你想確切了解哪些字符會被接受、哪些不會——它以 RFC 8259: The JSON Data Interchange Format 為名公開發布。

延伸閱讀：Properties to JSON: Escape Rules and Duplicate Key Handling。