JSON 格式化工具

格式化、壓縮和驗證 JSON。可選擇縮排方式使內容更易讀,或壓縮為單行。語法錯誤也可即時檢查。

JSON 輸入
格式化結果 有效的 JSON 無效的 JSON
{{ result.lines }} 行 / {{ result.bytes.toLocaleString() }} 位元組
{{ result.error }}

什麼是 JSON 格式化工具

JSON 格式化工具可把擠在一行、難以閱讀的 JSON 重新整理為帶縮排的形態,也可反過來去除空白、壓縮為一行。由於在解析輸入的同時也會判定語法是否正確,因此只需貼上 API 回應或設定檔,即可一併完成格式化、壓縮與驗證三件事。縮排可從2個空格、4個空格與定位字元中選擇。

判定使用瀏覽器自身的 JSON 解析器,因此不會出現「本工具能通過、執行環境卻報錯」的落差。處理全部在您所使用的裝置內完成,貼上的 JSON 不會被傳送至伺服器。即便是含有認證權杖或個人資訊的 API 回應,也能在不外洩內容的前提下加以格式化。

JSON 格式化工具的使用方式

  1. 貼上 JSON 把 JSON 貼到左側的輸入框。若手邊沒有可試的資料,可用「範例」按鈕載入樣本。
  2. 選擇縮排的寬度 從2個空格、4個空格與定位字元中選擇。配合專案的格式規範,即可原樣貼回。
  3. 查看有效與無效的標示 隨輸入即時切換「有效的 JSON」「無效的 JSON」標記。無效時會原樣顯示解析器回傳的錯誤訊息,可據以追查在第幾行的哪個字元處受阻。
  4. 選擇格式化版或壓縮版複製 「複製格式化結果」把帶縮排的結果、「複製壓縮結果」把去除空白後的單行結果放入剪貼簿。
  5. 確認行數與位元組數 行數計的是格式化後的結果,位元組數計的是壓縮後的結果並以 UTF-8 計量。估算傳輸量時請看後者。

用好本工具的小技巧

  • JSON 的鍵必須用雙引號括起來,單引號無效。
  • 末尾逗號(如 {"a":1,})在 JSON 規範中是無效的。
  • 數字可使用科學計數法(e 表示),但 NaN 和 Infinity 是無效的。
  • 字串中的雙引號需轉義為 \",換行符用 \n,製表符用 \t。
  • 壓縮可有效減小檔案體積。API 傳輸推薦使用壓縮版,配置檔案建議使用格式化版。

JSON 格式化工具的應用情境

閱讀 API 回應的內容

把以一行回傳的回應加以格式化,巢狀的深度與陣列的元素數便能以肉眼追蹤。這是開發中的動作確認與排查缺陷時最常見的用法。

查明設定檔的語法錯誤

當應用程式無法讀取設定檔時,貼上並驗證即可當場鎖定尾隨逗號、引號未閉合等原因。

為減少傳輸量而壓縮

把格式化後的 JSON 直接作為 API 回應或內嵌資料回傳,會因縮排的空白而白白增加傳輸量。用於發布時請使用壓縮版。

整理要貼到文件或 Issue 的程式碼範例

可把要放進規格書或缺陷報告的請求範例、回應範例,改成縮排整齊、易於閱讀的形態。

轉換為其他格式之前的前置處理

先確認語法無誤,在把資料交給JSON 轉 TypeScript 型別定義或JSON 轉 XML等轉換工具時,便不必為轉換端難以判明原因的報錯而煩惱。

與 JSON 相關的用語

JSON
JavaScript Object Notation 的縮寫,是 RFC 8259 所定的資料交換格式。僅由物件、陣列、字串、數值、布林值與 null 六種構成,因不限語言皆可讀寫,遂成為 Web API 的標準格式。
格式化(美化輸出)
依照巢狀深度加入縮排與換行,重新排成便於人閱讀的形式。本工具會原樣保留輸入中的數字、字串與跳脫寫法,只改變空白與換行,因此像 9007199254740993 這樣的大整數或 1.0 這樣的寫法都不會改變。
壓縮(minify)
去除所有與語意無關的空白與換行,彙為一行。位元組數減少故可壓低傳輸量,但不適合人來閱讀。
驗證(validation)
確認輸入是否合乎 JSON 的文法。本工具交由瀏覽器的解析器解析,並在失敗時原樣顯示其錯誤訊息。
跳脫序列
指在字串中,用反斜線表示那些無法直接書寫之字元的寫法。雙引號寫作 \",換行寫作 \n,定位字元寫作 \t。
鍵的順序
JSON本身並未規定物件中鍵的順序。經由JavaScript物件進行格式化時,像 "1"、"2" 這樣能讀作整數的鍵會依升冪重新排列,重複的鍵也會遺失其中一個;而本工具不重新解讀輸入就進行格式化,因此所有鍵(包括重複的鍵)都會保持書寫時的順序。
UTF-8
RFC 8259 規定 JSON 所應使用的字元編碼方式。中文等 ASCII 以外的字元每字占多個位元組,故字元數與位元組數並不一致。

常見問題

JSON 的鍵必須使用雙引號,不允許末尾逗號,也不能使用 undefined、函式、NaN 和 Infinity。

不可以。JSON 規範中不存在註釋語法。JSON5 和 JSONC 可作為替代方案。

RFC 8259 要求必須使用 UTF-8。出於互操作性考慮,推薦使用 UTF-8。

根據 JSON 規範,所有數字均為 number 型別。較大的整數在 JavaScript 中超過 MAX_SAFE_INTEGER 時可能會丟失精度。
工具君

閒話 ― JSON 勝過 XML 的原因

2000 年代初期 XML 曾是主流,但 Douglas Crockford 於 2001 年提出 JSON 後,憑藉其輕量、易用、易讀的特性,2010 年代以後 JSON 已成為標準格式。

同等資料下,JSON 的位元組數通常比 XML 少 30~50%,在行動通訊時代直接影響應用的響應速度。

RFC 8259 規定鍵重複為"SHOULD NOT",並非禁止。{"a":1,"a":2} 在語法上有效,但行為未定義。