開發者工具 · JSON 格式化程式和驗證程序
為什麼尾隨逗號會中斷 JSON 以及驗證器指向的位置
· 工作原理
json 開發人員工作流程 驗證
尾隨逗號是最常見的 JSON 錯誤，而且錯誤永遠不會落在逗號本身上。了解逗號後語法的要求以及如何閱讀所報告的位置。
需要十分鐘才能找到的單字元錯誤
需要十分鐘才能找到的單字元錯誤 - 手動編輯的配置，最後一個屬性後留下的逗號，以及失敗的構建。嚴格的解析器遵循檔案中實際存在的標記序列。考慮一個以 `'enabled': true,` 結尾的物件和一個以 `'blue',` 結尾的陣列：即使下一個標記關閉容器，兩個分隔符號都承諾另一個項目。
ToolAcre 不會從瀏覽器引擎訊息中取得位置。 JSON.parse 首先判斷有效性；僅在失敗後，儲存庫掃描器才會遍歷文字並報告第一個不可接受的字元。對於尾隨逗號，該字元是右大括號或方括號，原因明確為「尾隨逗號」。在物件中，缺少另一個帶有引號的成員名稱；在陣列中，缺少另一個完整值。
JSON 語法在逗號後表示什麼
JSON 語法在逗號後表示的內容 — RFC 8259 使用逗號分隔數組中的值和物件中的成員。因此，分隔符號的每一側都需要一個有效的項目。在物件逗號之後，解析器需要一個雙引號名稱、一個冒號和一個值。在陣列逗號之後，它需要任何有效的 JSON 值。結束定界符不滿足這兩種產生式。
分隔符號屬於兩個成員或元素之間，而不是在最後一個成員或元素之後。刪除最後一個逗號不會改變任何值或順序；它恢復在其最終值之後直接關閉容器的語法。這也是為什麼逗號可以毫無問題地出現在每個較早的項目之後：每個逗號後面都跟著它所承諾的下一個項目。
為什麼錯誤出現在右括號上
為什麼錯誤出現在右括號上 - 容器中間的逗號是合法的，因此解析器不能僅僅看到它就拒絕它。它使用分隔符號並更改狀態以期望另一個名稱或值。 The contradiction becomes certain only when `}` or `]` arrives instead.即使前面的逗號導致了狀態轉換，該分隔符也是所承諾的項目被證明不存在的地方。
報告的分隔符號是有關解析器狀態的證據，而不是刪除大括號或方括號的建議。讀取左側的一個標記。如果該標記是逗號並分隔符號關閉同一個容器，則刪除逗號並保留關閉。 ToolAcre 的掃描器命名尾隨逗號條件並在 JSON.parse 拒絕檔案後提供來源位置。
JavaScript、Python 和現代 linter 允許這樣做，JSON 不允許
JavaScript、Python 和現代 linter 允許這樣做，JSON 不允許——源語言文字通常允許在最後一項後面使用逗號，因為它使重新排序的行和將來的添加更容易檢查。格式化程式甚至可以插入或保留該樣式。這些便利性屬於每種語言的語法。 `.js` 物件文字或 Python 字典可以是有效來源，而相同的可見標點符號在 RFC 8259 JSON 檔案中仍然無效。
當貼上的片段以逗號結尾時，為 JavaScript 配置的編輯器可能不會顯示任何警告。目標解析器仍然控制接受。對 `.json` 文字使用 JSON 語言模式，並驗證傳送至 API 或設定欄位的確切負載。原始檔、linter 或 JSON5 解析器中的寬大處理並不是關於嚴格 JSON 消費者的可轉移證據。
工作範例：一個檔案中的三個尾隨逗號
工作範例：一個檔案中的三個尾隨逗號 — 假設 `features` 以 `"beta",` 結尾，其包含物件以 `"enabled": true,` 結尾，第二個根成員也有同樣的錯誤。第一次驗證在 `beta` 之後的右括號處停止。刪除該逗號允許解析繼續，直到 `true` 之後的右大括號，並修復第二個位置顯示剩餘的根級物件錯誤。
此序列是預期的，因為解析器通常報告不可能繼續的第一個點，而不是每個後續缺陷。將每一行和每一列對應到其結束分隔符，檢查其前面的分隔符，進行一項有意更改並再次執行驗證。不要批量刪除所有逗號：實際鄰居之間需要分隔符號。重複驗證可將同一檔案中的三個無效終端逗號與有效逗號區分開來。
產生相同錯誤的變體
產生相關分隔符錯誤的變體 - 一個前導逗號、一行中的兩個逗號以及根值後面的一個逗號都誤用了相同的字符，但違反了不同的解析器狀態。前導逗號的左側沒有完成的項目。連續的逗號在分隔符號之間不提供任何項目。在 JSON 文字已經到達有效結尾之後，完整根值後面會出現一個逗號。
這些情況不應自動標記為尾隨逗號。確切的原因取決於位置和容器狀態。在 `{"a":1,,"b":2}` 內部，第二個逗號是意外的，應該在引用的成員名稱開始處出現。在 `[ ,1]` 中，第一個逗號出現在需要值的位置。檢查診斷和周圍的標記，而不是在結束分隔符號模式之外應用通用的「刪除前一個逗號」規則。
這不包括什麼
這不包括 - JSON5 和一些 JSON-with-comments 工作流程故意允許尾隨逗號。為這些語法之一編寫的檔案應該使用其宣告的解析器、副檔名和工具。將其視為嚴格的 JSON 將產生反映格式不符的錯誤，而不一定是創作錯誤。相反，使用寬鬆的解析器接受它並不能使來源安全地傳送到嚴格的 JSON 端點。
僅為了沉默此診斷而更改解析器會更改可接受的語言，並可能隱藏與最終消費者的不相容性。註釋、不帶引號的名稱和單引號字串可能會在擴展格式中伴隨尾隨逗號，從而在文字跨越邊界時產生額外的失敗。首先確認目的地合約。如果顯示 JSON，請刪除擴充語法；如果顯示 JSON5 或 JSONC，請使用實作該確切格式的工具進行驗證。
重點：查看報告位置左側的一個標記
重點：查看報告位置左側的一個標記 - 當插入符號位於 `}` 或 `]` 下方時，前面的逗號可能已承諾從未到達的成員或元素。保留結構上必要的結束分隔符號並僅刪除該終端分隔符號。然後再次驗證整個文件，因為第一個修復的位置可能會在稍後的容器中發現另一個尾隨逗號。
ToolAcre 縮小了職責範圍：JSON.parse 決定檔案無效，本地掃描器在失敗後提供穩定的結構原因以及行和列。使用該座標來檢查解析器上下文，而不是孤立地指責突出顯示的字元。尾隨逗號是單字元編輯，但了解為什麼錯誤出現在以下分隔符號上可以使跨物件、陣列和深度嵌套配置的相同診斷變得可靠。