Notepad++ 並未內建 JSON 格式化工具 — 開箱即用時，開啟 .json 檔案只會看到基本的語法高亮，但沒有美化按鈕、沒有壓縮動作，也沒有錯誤回報。若要在 Notepad++ 內格式化 JSON，你必須安裝第三方外掛，例如 JSTool、JSONViewer，或是由 Mark Hesketh 開發、較舊的「JSON」外掛，重新啟動編輯器，而且即便如此，驗證回饋通常也僅限於一則沒有行列號的通用訊息。這個落差正是為什麼每當 API 回應看起來有問題時，許多開發者最後都會在 Notepad++ 和瀏覽器之間反覆複製貼上 JSON。更快的做法是：把 JSON 留在剪貼簿，再用一個在本地端處理的瀏覽器型格式化工具來處理它。免費的 JSON Formatter 會讀取你貼上的任何 JSON，以 2 個空格、4 個空格或 tab 縮排進行美化排版，視需要可再壓縮回單行，並在 JSON 損壞時，直接指出第一個語法錯誤所在的行與欄。
為何 Notepad++ 無法在沒有輔助的情況下格式化 JSON
Notepad++ 是基於 Scintilla 的文字編輯器，於 2003 年首次發布,刻意以精簡的核心發行：分頁介面、regex 搜尋取代、巨集錄製，以及從一長串使用者定義 lexer XML 檔案衍生出、具語言感知能力的語法高亮。JSON 也在那份 lexer 清單中,這就是為什麼你一打開檔案,熟悉的藍色和紅色就會立刻出現。然而高亮純粹只是外觀上的 — 它只是告訴編輯器如何為 token 上色,而不是如何剖析它們。格式化（加上縮排、換行，以及一致的物件配置）是另一種不同的操作,需要編輯器實際理解 JSON 文法,而 Notepad++ 本身並不會這樣做。
它所需要的文法其實已經標準化：JSON 是由 RFC 8259 和 ECMA-404 所定義,真正的格式化工具會以嚴格的文法剖析輸入,再序列化輸出,並回報任何違反規則的位元組位移。沒有這一層,Notepad++ 只能透過外掛提供一鍵「美化」功能,而一個你沒安裝的外掛,在功能上等同於完全沒有外掛。這個落差正是每一個 Notepad++ JSON 外掛存在的原因,也是為什麼當你只需要一次格式化一個檔案時,一個自給自足的瀏覽器工具反而可以是更乾淨的替代方案。
Notepad++ JSON 外掛比較
三個外掛涵蓋了大部分「在 Notepad++ 中格式化 JSON」這類搜尋需求。沒有任何一個是隨編輯器預裝的;它們都存在於 Plugin Manager 之中,或是必須手動丟進 plugins 資料夾。
| 方法 | 格式化（美化排版） | 壓縮 | 驗證 | 需要的設定 |
|---|---|---|---|---|
| Notepad++ 單獨使用 | 否 | 否 | 否 | 無 |
| JSTool 外掛 | 是（JSMin 風格） | 是 | 訊息有限,無行列號 | 透過 Plugin Manager 安裝,重新啟動 |
| JSONViewer 外掛 | 是（樹狀檢視） | 否 | 僅樹狀剖析 | 手動放入 .dll,重新啟動 |
| JSON Formatter（瀏覽器） | 是（2 / 4 / tab） | 是 | 回報行列位置 | 無 |
由 Ekopalypse 開發的 JSTool 是最受歡迎的選擇,因為它位於 Plugins 選單中,並提供單一「JSON Viewer」面板,可格式化目前文件並再壓縮回來。它的弱點在於錯誤訊息:當 JSON 損壞時,它只會以白話告訴你第一次剖析失敗的位置,卻不附上行號或欄號,因此你仍然得自己用肉眼數括號。Mohammadsadegh Shafie 開發的 JSONViewer 則走向另一個方向 — 它把檔案呈現為可摺疊的樹狀結構,這在瀏覽一個 5,000 行的回應時很方便,但在編輯時就不太實用,因為畫面上的文字已經不再是檔案的實際內容。這兩個外掛都預設你的 JSON 接近可剖析的狀態,只有在明顯無效時才會抱怨。如果你想要一個能對每一種錯誤做出反應、並指出規則被破壞的精確欄位的工具,JSON Formatter 工具正是為此需求而打造。
如何使用 JSON Formatter 格式化 JSON
整個工作流程只需三次點擊,並且能在你剪貼簿上任何 JSON 上運作,從 curl 回應到貼上的設定片段都適用。不需登入、不需上傳、不需安裝外掛。
- 把你的 JSON 貼上或輸入到頁面左側的輸入框中。
- 選擇縮排樣式 — 2 個空格、4 個空格或 tab — 以符合你專案的風格指南,然後點擊 Format 來美化文件;若你想要最小的有效承載量壓縮成單行,則點擊 Minify。
- 如果 JSON 有效,格式化或壓縮後的結果會出現在輸出框中;點擊 Copy 即可取得。
- 如果 JSON 無效,工具會在第一次剖析錯誤處停下,並顯示剖析失敗時的行號與欄號,加上剖析器本身的訊息 — 通常足以一眼看出尾端逗號或單引號字串。
所有過程都在瀏覽器原生的 JSON 剖析器內進行,因此輸出符合標準且可安全往返 — 你可以把格式化後的結果複製回 Notepad++,存檔,你的應用程式仍會讀到完全相同的資料,僅僅是空白字元被改變。如果你在除錯一個「看起來沒問題」、但伺服器仍拒絕的 API 回應,大多數的謎團都能在驗證步驟被解開。
驗證工具會抓到的常見 JSON 錯誤
JSON 是比 JavaScript 物件實字更嚴格的子集合,大多數的拒絕都來自 JavaScript 容許、但你很容易養成的四種習慣。了解它們,能把令人挫折的除錯過程變成快速的修正。
- 尾端逗號 — { "a": 1, "b": 2, } 在每個現代瀏覽器中都能剖析,但在 JSON 中是不合法的。工具會標記最後一個屬性結尾處的逗號。
- 單引號 — { 'a': 1 } 是合法的 JavaScript,但不是 JSON。每個鍵與字串都必須使用雙引號。
- 未加引號的鍵 — { a: 1 } 看起來無害;JSON 要求 { "a": 1 }。
- 註解與尾端分號 — JSON 沒有註解語法。文件中任何位置出現 // 或 /* */ 都會中斷剖析。
剖析器也強制執行六種值規則:物件、陣列、字串、數字、布林值（true 或 false）,或 null。undefined、NaN、Infinity、日期和函式都會被拒絕,因為它們無法在另一端的通用 JSON 讀取器中往返。一旦你內化這份清單,格式化工具所回報的行與欄錯誤,就會像一張直接指向 bug 的地圖。
何時該格式化,何時該壓縮
格式化與壓縮會產生完全相同的資料 — 只有空白字元不同。在它們之間做選擇,取決於下一個要讀取 JSON 的是誰。當需要「人」來檢視時,選擇 格式化:除錯一個 2,000 字元的單行 API 回應、在 pull request 前檢視 package.json,或是清理從其他工具匯出的設定檔。2 個空格縮排是 JavaScript 社群事實上的預設;4 個空格縮排在 Python 或 YAML 相關風格下對齊得更整齊;tab 縮排則讓每位開發者可以在自己的編輯器中選擇視覺寬度,而不必動到檔案。
當需要「機器」來傳輸時,選擇 壓縮。正式環境的 API 回應、會被 base64 編碼進 URL 的承載資料、儲存在資料庫欄位中的資料列,以及任何透過計費行動網路傳輸的 JSON,都能受益於移除所有空格與換行。因為剖析器會先將結構標準化,壓縮後的輸出與手工去除空白的版本在位元組上等價,並能在同一個剖析器中往返而不會出意外。一個實用的原則是:除錯時將承載資料格式化一次以便閱讀,出貨前再壓縮以利傳輸。
有一個值得知道的怪癖,這不是格式化工具的 bug,而是 JavaScript 數字型別的特性:大於 9,007,199,254,740,991（Number.MAX_SAFE_INTEGER）的整數在往返時會失去精度,因為它們是以 IEEE-754 雙精度浮點數儲存。像 12345678901234567890 這樣的值會變回 12345678901234567000。如果你的 JSON 帶有 64 位元識別碼,例如 Twitter/X 的雪花時間戳,請從頭到尾都將它們保留為字串 — 在來源端與接收端程式碼中都如此,格式化工具就能精確地保留它們。
由於剖析是在用戶端進行,你貼進 JSON Formatter 的 JSON 從未離開過這個頁面,這與可能會回傳資訊以取得更新的編輯器外掛,以及會把你的承載資料 POST 到後端的網頁驗證工具,是真正的差別。如果你經常處理存取權杖、私有 API 回應或客戶資料,這個邊界比外掛所提供的任何功能都更為重要。