常見問題

常見問題

可以在線上格式化無效的 JSON 嗎？

可以。把損壞的 JSON 貼進來，點擊 Repair & Format。工具會先嘗試修復單引號、尾隨逗號、JSON 鍵缺少引號、註解和 Python 風格的值，再格式化輸出。

怎麼格式化損壞的 JSON？

從能安全貼上的最小片段開始：先修復語法，再用嚴格的 JSON 解析器驗證結果。如果資料裡有尾隨逗號，工具會先把最後那個逗號去掉，再把合法結果格式化輸出。

「Unexpected token」是什麼意思？

意思是解析器在當前位置遇到了嚴格 JSON 語法中不應該出現的字元。常見的元兇是單引號、斜線、尾隨逗號、或大寫的 True —— 這些通常代表文字是從 JavaScript、Python 或 AI 回覆裡複製過來的「近似 JSON」。

可以把 JSON 轉成 JavaScript 物件嗎？

可以。一旦輸入是合法 JSON，在 JavaScript 裡呼叫 JSON.parse(jsonText) 即可。如果文字本身是 JavaScript 物件字面值，先把它修復成嚴格 JSON 再解析。

我的資料安全嗎？

安全。工具完全在你的瀏覽器中以 JavaScript 執行，不會把資料上傳到任何伺服器。

Repair 與 Validate 有何不同？

Repair 會容忍常見錯誤，嘗試產出合法 JSON；Validate 用嚴格解析器，回報錯誤的精確行列。

完整使用指南

多數 JSON 格式化工具一遇到解析錯誤就停下。這個工具是為「格式化之前的一步」設計的：它把近似 JSON 轉成嚴格 JSON，然後再美化輸出，讓你能審視結構。所以它適合「怎麼格式化損壞 JSON」這類問題，而不只是「怎麼美化合法 JSON」。

從能安全貼上的最小損壞 JSON 開始。當文字來自 JavaScript 物件字面值、Python 片段、Markdown 回覆、手改過的設定，或類 JSON 的記錄時，點擊 Repair & Format。修復階段會把常見語法錯誤歸一化成合法 JSON，再以可預測的縮排印出，方便檢視巢狀陣列與物件。

修復完成後再點 Validate。驗證走嚴格解析，應該是把輸出複製到 API 客戶端、應用程式設定、資料庫遷移、測試樣本或命令列範例之前的最後一關。驗證失敗時看清行列、檢查反白的 token，並比對原文與修復後的版本。修復負責語法層面的清理，並不負責判斷值在業務語義上是否正確。

JSON 合法之後再用 Minify。壓縮後的 JSON 適合放進環境變數、查詢參數、緊湊記錄與文件中的小範例；做程式碼審查、除錯或 API 測試時，格式化輸出通常更安全，因為每個鍵、陣列項與巢狀值都在可預測的行上。

JSON 錯誤字典

尾隨逗號

在 } 或 ] 之前的最後一個逗號被許多 JavaScript 工具接受，但 JSON 解析器會拒絕。去掉最後一個屬性或陣列項後的多餘逗號即可。

JSON 鍵缺少引號

像 name 和 active 這樣的鍵必須用雙引號包住。把 { name: "Ada" } 改成 { "name": "Ada" }。

單引號

JSON 字串只能用雙引號。把 'Ada' 改成 "Ada"，同時小心字串內部的撇號。

Unexpected token

解析器在嚴格 JSON 語法不允許的位置遇到了一個字元。可能是逗號、斜線、單引號、大寫的布林值，或文件結尾後的多餘文字。

Python 字面值

Python 使用 True、False 和 None；JSON 使用 true、false 和 null。

註解

註解在 JavaScript 和 JSONC 裡很常見，但不屬於合法 JSON。在把資料交給 JSON 解析器之前，去掉 // 行註解和 /* 區塊註解 */。

Markdown 程式碼圍欄

LLM 回覆常把 JSON 包在 ```json 圍欄裡。在解析或發送到 API 之前，先把圍欄標記去掉。

各工具相關問題

JSON Fix —— 怎麼修復無效的 JSON？

把損壞的 JSON 貼到 JSON Fix，點擊 Repair & Format。它會一次修復尾隨逗號、單引號、未加引號的鍵、Python 字面值、註解和 Markdown 程式碼圍欄。

JSON Validate —— 驗證和解析 JSON 有什麼差別？

解析是把 JSON 變成可用的值；驗證只是確認它能被解析。成功的 JSON.parse 本身就是一次驗證 —— 詳見 JSON Validator。

JSON Viewer —— 為什麼樹狀檢視是空的？

樹狀檢視只能從可解析的 JSON 建立。先用 JSON Fix 修復常見錯誤，再把清理過的結果載入 JSON Viewer。

JSON Diff —— 為什麼排序前後被視為完全相同？

JSON 物件在規範上是無順序的。JSON Diff 在比較前會先歸一化鍵名，所以只顯示真正的值差異。

JSON to TypeScript —— 產生的型別會在執行階段驗證嗎？

不會。JSON to TypeScript 產生的是編譯時介面。執行階段驗證請搭配 Zod，或用 JSON Schema 描述結構。

JSON Minify —— 壓縮能節省多少？

在 HTTP 壓縮之前通常能節省 15–50%。如果你的伺服器已經傳送 Content-Encoding: gzip 或 br，再用 minify 的邊際效益就很小。

JSON Stringify —— 怎麼解碼被兩次序列化的 JSON 字串？

在 JSON Stringify 裡點擊 Unstringify；如果輸入以跳脫引號開頭，也可以連續呼叫兩次 JSON.parse。

JSON ⇄ CSV —— 巢狀物件怎麼表示？

每個巢狀的物件或陣列都會以 JSON 文字寫入儲存格，保持轉換可逆。詳見 JSON to CSV。

JSON ⇄ XML —— 怎麼把一個值變成 XML 屬性？

在鍵名前加 @（例如 @id）；元素文字放在 #text；陣列會變成重複元素。詳見 JSON to XML。

YAML —— 為什麼我的 YAML 解析不過？

幾乎總是縮排問題 —— 一個 tab 字元（YAML 禁止 tab）或同層縮排對不齊。用 YAML 格式化器 跑一次，會暴露並規範化這兩個問題。

Base64 —— Base64 與 Base64url 有什麼差別？

標準 Base64 用 + 和 /，並以 = 作為填補；URL 安全的 Base64url 把它們替換成 - 和 _，並去掉填補，這樣值在 URL 與 JWT 裡也安全。詳見 Base64。

URL Decode —— 為什麼 + 沒被解碼成空白？

在查詢字串裡，空白可能寫成 +（表單編碼）或 %20。decodeURIComponent 不會把 + 轉成空白 —— 如果是表單編碼的資料，請先自行替換。詳見 URL Decode。

JWT Decode —— 會驗證簽章嗎？

不會。JWT Decode 只讀取 claim，不檢查簽章。一定要在伺服器端驗證，並把函式庫設定為你預期的演算法（絕不接受 alg: none）。

我該看哪一篇錯誤文章？

如果你手上有完整的錯誤訊息，可以直接跳到對應文章：

• 「Unexpected token < in JSON at position 0」 → fetch 回傳的是 HTML
• 「Unexpected token u in JSON at position 0」 → 你把 undefined 拿去解析了
• 「Unexpected token o in JSON at position 1」 → 物件被 stringify 成 [object Object]
• 「Unexpected end of JSON input」 → 結構被截斷或未封閉
• 「Unexpected non-whitespace character after JSON data」 → 完整值之後還有額外資料（可能是 NDJSON？）
• 「Unterminated string in JSON」 → 字串開了但沒關
• 「Bad escaped character in JSON」 → 無效的反斜線跳脫（如 \x、Windows 路徑）
• 「Bad control character in string literal in JSON」 → 字串裡有原始 tab/換行/控制位元組
• 「Expected double-quoted property name…」 → 尾隨逗號
• 「[object Object] is not valid JSON」 → 物件在解析前被 stringify 了
• 不確定是哪一個？ → 從總覽文章開始：如何修復 JSON.parse Unexpected Token 錯誤

本地處理如何保護隱私

修復、驗證、格式化、壓縮與複製操作都在你的瀏覽器分頁裡執行。工具不需要上傳端點來處理你的 JSON。這對含有私人識別碼的 API 樣本、Webhook 內容、內部設定片段或除錯輸出尤其重要。貼到任何網站之前你仍應移除機密，但本工具的核心 JSON 流程是「本地優先」設計的。

本網站可能會在頁面周圍使用代管記錄、分析等指令稿，詳情見隱私政策。這些系統不應收到你貼到編輯器裡用於修復的內容。如果資料包含憑證、存取權杖、客戶記錄或正式環境機密，請在除錯前用安全佔位符替換。

JSON 是什麼、為什麼這麼嚴格

JSON 代表 JavaScript Object Notation，但現代 JSON 已與語言無關。Python、Go、Java、PHP、Ruby、Rust、資料庫、訊息佇列、記錄系統與瀏覽器程式碼都能讀同一份 JSON 文件，因為它的語法被刻意做得很小。這種嚴格性是有用的：JSON 解析器不會執行函式、建構式、日期、註解或運算式 —— 它只接受資料。

代價是：從 JavaScript 物件字面值、Python 字典、TypeScript 設定或 Markdown 答覆裡複製出來的文字看起來很像 JSON，卻仍然無效。修復功能幫你把這些「近似 JSON」轉成嚴格解析器能接受的資料。

使用修復後的 JSON 之前

修復成功只代表文字能被轉成合法的 JSON 語法，並不代表資料對你的端點或應用程式是正確的。在把修復後的 JSON 用於正式環境前，請檢查必填欄位、未知鍵、值型別、陣列長度、日期格式、列舉值、null 處理，以及識別碼應該是字串還是數字。

如果資料控制權限、計費、資料刪除或面向客戶的行為，修復後請與已知良好樣本或 schema 比對。在 API 工作中，先驗證語法，再驗證業務契約。