YAML 格式化工具

將 YAML 整理為統一的縮排寬度,或轉換為 JSON。可檢測製表符混入和縮排不一致等問題。

什麼是 YAML 格式化工具

YAML 格式化工具可以將縮排寬度不統一的 YAML 重新整理為 2 個或 4 個空格的統一縮排,並在整理的同時檢查語法是否正確。組態檔在反覆複製貼上和手動編輯之後很容易出現縮排錯亂,而很多時候直到 CI/CD 流程或組態管理工具報錯才會發現問題。本工具完全在瀏覽器內執行,因此可以在不將敏感組態內容傳送到外部伺服器的情況下完成檢查。

本工具基於遵循YAML 1.2規範的開源解析器(yaml)運作,支援錨點(&)與別名(*)、塊狀標量(|和>)以及用---分隔的多文件。布林值和null依照YAML 1.2的core schema判定,因此不帶引號的no、on會被視為字串。同一層級出現重複鍵時會報錯並顯示行號;轉換為JSON時,多文件會變成依文件排列各自值的陣列。

YAML 格式化工具的使用方法

  1. 貼上 YAML 將需要整理的 YAML 貼到左側的輸入框。如果手邊沒有可用的內容,點擊「示例」按鈕即可插入一段用於測試的 YAML。
  2. 選擇模式 選擇「格式化・驗證」來檢查語法並統一縮排,或選擇「轉換為 JSON」將 YAML 內容渲染成 JSON。
  3. 選擇縮排寬度 僅在「格式化・驗證」模式下可選,從 2 個空格或 4 個空格中選擇輸出縮排,與專案現有規範保持一致即可。
  4. 查看輸出結果 如果 YAML 有效,右側會顯示整理後的結果(或轉換後的 JSON);如果無效,則會顯示錯誤訊息和行號,方便直接定位到出問題的那一行。
  5. 複製結果 點擊「複製」按鈕,將輸出結果複製到剪貼簿,隨後可直接貼回組態檔中。

用好本工具的小技巧

  • 本工具使用遵循YAML 1.2規範的開源解析器(yaml)進行解析,錨點、別名、塊狀標量以及用---分隔的多文件都可以直接處理。格式化時會原樣保留註解和引號。
  • 即使貼上縮排不統一(例如 3 個或 5 個空格)的 YAML,只要能成功解析,就可以重新輸出為統一的 2 或 4 個空格縮排。
  • 在“轉換為 JSON”模式下,可以直接預覽將 YAML 內容轉換成 JSON 的結果,方便與 CI 配置或 API 響應進行比較。
  • 出現錯誤時會顯示行號,請檢查該行的縮排或冒號後面是否忘記加空格。
  • YAML 規範禁止使用製表符縮排。建議在編輯器設定中開啟“將製表符轉換為空格”,以避免這類問題。

適用場景

提交前檢查 CI 組態檔

在提交 GitHub Actions 或 GitLab CI 的 .yml 檔案之前,用本工具檢查一遍是否存在縮排錯亂或誤混入的製表符,可以避免流程因語法錯誤而中斷。

整理 Kubernetes 清單檔案

由多人共同編輯的 Deployment、Service 清單檔案很容易出現縮排寬度不統一的情況,可以先統一為團隊約定的規範(例如 2 個空格)後再提交審閱。

驗證 Docker Compose 檔案

docker-compose.yml 中的縮排錯誤往往要到容器啟動失敗時才會被發現,提前用本工具檢查語法和縮排的一致性會更加安心。

對照 YAML 與 JSON

當同一份組態或 API 資料需要同時以 YAML 和 JSON 兩種格式使用時,可以用「轉換為 JSON」模式查看轉換結果,再配合基於 JSON 的其他工具或結構描述驗證一起使用。

術語表

YAML
「YAML Ain't Markup Language」的遞迴縮寫,是一種透過縮排表達層級結構的資料序列化格式,被廣泛用作組態檔。
縮排
位於行首的空白字元,在 YAML 中用於表示父子層級關係。根據規範,縮排不能使用製表符。
對映(Mapping)
以「鍵: 值」形式表示資料的結構,相當於其他語言中的關聯陣列或物件。
列表(Sequence)
按順序排列多個值的結構,每個項目以「- 」(連字符加空格)開頭表示。
流式風格(Flow Style)
將對映或列表以 {a: 1}、[a, b, c] 這樣的形式寫在同一行的內聯寫法,不依賴縮排即可簡潔表達。
錨點與別名
用&name定義內容,再用*name重複使用的機制,可避免重複書寫相同的值。本工具在格式化時原樣保留,在轉換為JSON時展開為被參照的值。
塊狀標量(Block Scalar)
使用|(保留換行)或>(將換行摺疊為空格)書寫多行字串的方式。本工具在格式化和轉換為JSON時都支援。
挪威問題
不加引號的 no、yes 等值會被解釋為布林值而非字串,是 YAML 中廣為人知的一個陷阱。

常見問題

對於需要人工編輯和審閱的配置檔案(如 CI 配置、Kubernetes 清單等),YAML 支援註釋、可讀性更高,更為合適;而對於程式之間互動的場景(如 API 響應),歧義更少、解析速度更快的 JSON 更為合適。

YAML 規範禁止使用製表符進行縮排。大多數解析器會將其視為語法錯誤並中止處理。建議將編輯器設定為自動把製表符轉換為空格,以確保安全。

支援。格式化時會原樣保留錨點和別名,轉換為JSON時會在別名的位置展開被參照的值。Docker Compose等檔案中使用的合併鍵(<<: *name)也會展開。多文件和塊狀標量(|、>)同樣支援。

這是一個著名的陷阱:如果不加引號直接寫 no、yes、on、off,許多 YAML 實現會將其解釋為布林值,而不是普通字串(例如挪威的國家程式碼)。如果希望將其作為字串處理,需要用引號括起來,例如 "no"。
工具君

閒話 ― YAML 為何成為配置檔案的主流選擇

YAML(YAML Ain't Markup Language)是一種誕生於 2001 年的資料序列化格式。由於不需要閉合標籤、外觀比 XML 更簡潔,自 2010 年代以來被廣泛用作基礎設施配置檔案的格式,例如 Docker Compose、GitHub Actions 和 Kubernetes 清單檔案都採用了 YAML。

另一方面,YAML「用縮排表示結構」的設計雖然便於人類閱讀,但在複製貼上時縮排很容易錯亂。規範禁止使用定位字元(Tab)縮排,主流解析器會將其視為語法錯誤。更麻煩的是空格數量出現偏差的情況:檔案可能不會報錯,卻把某個元素讀成了另一個層級,從而埋下意想不到的設定錯誤。

此外還有一個著名的陷阱,被稱為“挪威問題”。如果不加引號直接寫國家程式碼 no,許多 YAML 實現會將其解釋為布林值 false。YAML 1.1 與 1.2 版本對哪些字串會被視為布林值的規定也有所不同,這也是不同實現之間相容性問題的常見成因。