JSON 是 API payload、設定檔與日誌匯出的預設格式，但你第一次見到它時，通常是一行完全讀不下去的字串。這篇指南涵蓋大家真正需要的三件事——格式化到人能看懂、驗證到上線前就抓到問題、壓縮到payload 盡量小——以及解釋為什麼解析器一直退貨的那些語法規則。

每個步驟都在 UrsaKit 的 JSON 工作區完成，而且完全在瀏覽器裡執行，你可以直接貼上真實 payload 邊做邊查。沒有任何資料會被上傳。

01JSON 到底允許什麼

JSON 由 RFC 8259 與 ECMA-404 定義。它刻意比 JavaScript 的物件實字更小，這也是「看起來沒問題」卻仍然解析失敗的幾乎所有原因。

值得記住的規則：

• 鍵與字串值一定要用雙引號。name: 與 'name' 都不合法。
• 不能有尾隨逗號，[1, 2,] 與 {"a": 1,} 都是語法錯誤。
• 不能有註釋。// 與 /* */ 不屬於 JSON，即使檔案看起來像 JavaScript。如果檔案確實需要註釋，那它是 JSONC 或 YAML——請改用 JSON 轉 YAML，不要硬丟給 JSON 解析器。
• 值只允許物件、陣列、字串、數字、true、false 與 null。NaN、Infinity、undefined 都不是合法值。
• 數字不能有前置 +，也不能只有小數點：寫 0.5，不要寫 .5。
• 檔頭若有 UTF-8 BOM，嚴格解析器會直接失敗——第一個字元必須是 { 或 [。

02格式化、驗證與壓縮 JSON

工作區只有一個編輯器加一組能力切換，所以下面三個步驟同時涵蓋格式化、驗證與壓縮。

1. 貼上或拖入 JSON — 把 payload 貼進左側編輯器，或上傳 .json 檔。工作區會邊打邊解析，狀態列會顯示「有效」，或直接指出第一個錯誤的行與欄位。
2. 修掉狀態列標出的問題 — 點一下回報的位置就能跳到出錯的行。如果文件裡有不合法的跳脫序列或原始控制字元，按 Fix escapes 就地修好。
3. 選 2 或 4 個空白後格式化 — 按 Beautify 重新縮排，效果和獨立的 JSON 格式化工具 相同。設定檔慣例是兩個空白，四個空白則和多數編輯器一致。Sort keys 會把物件鍵依字母排序，比對差異前很好用。
4. 要傳輸時就壓縮 — 按 Minify 移除所有不影響語意的空白與換行，行為等同專門的 JSON 壓縮工具。除了空白之外，鍵、值、數字精度與順序都不變。
5. 不想改、只想看 — 切換其它能力：Visual 會畫出可折疊的樹狀結構，JSONPath 可用 $ 運算式查詢，Convert 可輸出 YAML / XML / CSV / TypeScript，Schema 會推導出 JSON Schema，JWT 則用來解碼權杖。
6. 複製或下載結果 — Copy 把目前輸出放進剪貼簿，Download 存成檔案。因為解析都在本機，這兩個動作都不會碰到網絡。

03前後對照

把壓縮過的 API 回應變回可讀，以及修好大多數非法文件的兩個編輯動作。

壓縮回應 → 可讀

輸入

{"id":42,"user":{"name":"Ada","roles":["admin","billing"],"active":true},"meta":{"page":1,"total":128}}

輸出

{
  "id": 42,
  "user": {
    "name": "Ada",
    "roles": [
      "admin",
      "billing"
    ],
    "active": true
  },
  "meta": {
    "page": 1,
    "total": 128
  }
}

尾隨逗號 → 不合法

輸入

{
  "name": "Ada",
  "roles": [
    "admin",
  ]
}

輸出

Unexpected token } in JSON
→ line 5, column 3 (the comma after "admin")

刪掉尾隨逗號後重新驗證即可。物件也一樣：} 或 ] 前面不能有逗號。

傳輸前壓縮

輸入

{
  "timeout": 30,
  "retries": 3,
  "region": "eu-west-1"
}

輸出

{"timeout":30,"retries":3,"region":"eu-west-1"}

在美化過的文件裡，空白常佔 40–70% 的體積，所以壓縮是最划算的瘦身手段。

尾隨逗號是最常見的原因

JSON 不允許 } 或 ] 前面有逗號。如果一段 payload 在瀏覽器 console 當成 JavaScript 物件可以跑，驗證卻失敗，通常就是這個字元造成的。

04最常遇到的語法錯誤

幾乎每一份「invalid JSON」回報都是這七種原因之一。

05JSON 與常被搞混的格式

如果檔案裡有註釋或未加引號的鍵，它就不是 JSON，而是下面其中一種；這個區別會影響你該拿哪個解析器出來。需要在兩者之間搬資料時，可以用 JSON 轉 YAML 或 JSON 轉 CSV。

06排查失敗的 API 回應

最快的流程是：複製原始回應內容，記下驗證器回報的行與欄位，修好、重新驗證，最後才格式化。要複製的是原始文字，不是解析後的物件——瀏覽器的物件預覽會藏掉真正的語法，還會讓你看到一份「乾淨」但根本沒在網絡上存在過的物件。

當回應很大、工作區開始變慢時，那是瀏覽器在解析與繪製，不是網絡來回。超過大約 10 MB 的 payload 建議拆開，或改用 JSONPath 只取出需要的那個分支，而不是把整份文件畫出來。

注意：鍵的順序會被保留 依規範 JSON 物件是無序的，但除非你主動開啟 Sort keys，工作區會保留原始順序。

提示：比對前先格式化 兩份只差縮排的 payload 會產生一堆噪音。先把兩邊都格式化，或在 Diff 比對工具 裡打開忽略空白。

警告：什麼都不會上傳 格式化、壓縮、驗證、轉換與 Schema 產生全都在瀏覽器分頁裡執行，payload 不會離開你的裝置。