YAMLフォーマッター＆バリデーター

YAMLを貼り付けてフォーマットおよび検証します。エラーを瞬時に確認し、インデントを修正して、JSONに変換します。

ローカルで処理 · 何もサーバーに送信されません
検証するためにYAMLを貼り付け

YAMLとは?

YAML(YAML Ain't Markup Language)は、設定ファイル(Docker、Kubernetes、GitHub Actions、Ansible)、データ交換などに使用される人間が読めるデータシリアライゼーション形式です。中括弧の代わりにインデントを使用し、JSONのスーパーセットです。

よくある質問

バリデーターはどのエラーを検出しますか?

インデントエラー、欠落したコロン、重複したキー、無効な文字、未閉じの文字列、誤ったネスト、その他のYAML構文の問題。エラーメッセージには行番号が含まれます。

YAMLをJSONに変換できますか?

はい!「→ JSON」ボタンをクリックして、YAMLを整形されたJSONに変換します。逆変換には、JSON→YAML変換を使用してください。

YAMLクイックツアー

YAML 1.0は2001年にClark Evans・Ingy döt Net・Oren Ben-Kikiによって発表された。YAML 1.1は2005年に続き、現在のバージョンはYAML 1.2.2だ。これはいくつかの歴史的な問題（特に「ノルウェー問題」、後述）を修正し、JSONの厳格なスーパーセットとなるよう設計された。公式仕様はyaml.org/spec/1.2.2にある。このフォーマッターはオープンソースのjs-yamlライブラリを使用し、デフォルトでYAML 1.2スキーマに基づいてパースするため、ここでフォーマットしたテキストにはレガシーの1.1の癖のほとんどは適用されない。ただし出力を送る多くのサーバーサイドYAMLツールには適用される。

YAMLが実際に使われる場所

YAMLはクラウドネイティブインフラの設定フォーマットとして勝者となった。最もよく使われる場所：

空白の罠（スペースのみ）

YAMLは構造を示すためにインデントを使い、タブはインデントに使用できないとスペックは明示している。スペースのみだ。これは手書きYAMLの最も一般的なバグの原因で、多くのエディターが設定によってタブとスペースを静かに混在させるためだ。厳格なパーサーから得られるエラーメッセージは「found character '\t' that cannot start any token」のような内容で、訳すと「どこかでタブを使った」となる。修正は普遍的だ：エディターで「空白を表示」を有効にして、すべてのタブをスペース2つまたは4つに変換する。

インデントサイズはスペックではなく慣習だ。スペース2つはKubernetesマニフェスト・GitHub Actions・現代のウェブで見るほとんどのYAMLの事実上の標準だ。スペース4つはAnsibleでより一般的だ。重要なルール：単一ファイル内で一貫させること。兄弟キー間でスペース2つと4つを混在させることがパーサーを引っかかる原因であり、どちらを選ぶかではない。

ノルウェー問題（と曖昧な文字列をクォートすべき理由）

YAML 1.1（PyYAML・snakeyaml・他の多くのサーバーサイドパーサーのデフォルト）はクォートなしのboolean表記の長いリストを実際のbooleanとして解釈する：true・True・TRUE・false・False・FALSE・yes・Yes・YES・no・No・NO・y・n・on・off。有名な罠：ノルウェーのISO国コードはNOだ。国をクォートなし文字列でリストするYAML設定は、ノルウェーを静かにboolean falseとしてパースし、countries[0] == 'NO'を読むダウンストリームのコードが不可解な失敗をする。

YAML 1.2（とjs-yamlのデフォルトスキーマ）はbooleanをtrue / falseだけに制限し、パーサーレベルでノルウェー問題を修正した。しかし多くの実際のツールは後方互換性のためにまだYAML 1.1スキーマをデフォルトとしている。防衛的な習慣：boolean・数値・日付・バージョンのように見える可能性がある文字列はすべてクォートする。country: "NO"・postal_code: "01234"・version: "1.10"・time: "10:30"。クォートは万能の曖昧さ解消手段だ。

その他の型強制の落とし穴

ブロックスタイル対フロースタイル

YAMLは同じデータに対して2つの記法をサポートする：

# Block style (the standard, indentation-based)
person:
  name: Alice
  tags:
    - admin
    - billing

# Flow style (JSON-like inline)
person: { name: Alice, tags: [admin, billing] }

ブロックスタイルは手書きYAMLの99%で見られ、フォーマットを読みやすくするものだ。フロースタイルは短い1行の値や、インデントを追跡したくないプログラム的なYAML生成のための便利なエスケープハッチだ。フォーマッターはどちらのスタイルの入力でも（より読みやすい形式として）ブロックスタイルで出力する。

アンカーとエイリアス（DRYのトリック）

YAMLの再利用機能：&nameアンカーで値を一度定義し、*nameエイリアスで他の場所から参照する。同じ値ブロックが何度も現れる長い設定ファイルに便利だ。

defaults: &defaults
  region: us-east-1
  log_level: info

production:
  <<: *defaults
  log_level: warn   # override

staging:
  <<: *defaults

いくつかの注意点：すべてのYAMLプロセッサーがアンカーとエイリアスをサポートしているわけではない（特に一部の古いKubernetesマニフェストツールや特定のHelmコンテキスト）。上記で示した<<:「マージキー」構文はYAML 1.1の拡張で、1.2では公式に廃止予定だ。js-yamlはサポートしているが、純粋な1.2パーサーはサポートしないかもしれない。

マルチドキュメントファイル

単一のYAMLファイルには---で区切られた複数のドキュメントを含めることができる。Kubernetesでは一般的で、Deployment・Service・ConfigMapを1つのファイルに収め、---で区切り、kubectl apply -fコマンド1つで適用する：

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
---
apiVersion: v1
kind: Service
metadata:
  name: app-svc

YAML 対 JSON 対 TOML

新しい設定の選択肢がある場合：フラットな設定にはTOML、深いネストが必要でエコシステムが標準化している場合はYAML（Kubernetes・Ansible）、機械が書く場合はJSON。YAMLは人間が深くネストした設定を読み、意味のあるコメントをインラインで書く必要があるときに適したフォーマットだ。

プライバシー

YAML設定には、KubernetesのシークレットのBase64ブロブ・application.yml内のデータベースパスワード・CIワークフローのAPIキー・デプロイ設定の内部ホスト名など、他者のサーバーを経由させるべきでないシークレットが頻繁に含まれる。このフォーマッターはオープンソースのjs-yamlライブラリを通じて完全にブラウザ内で動作する。貼り付けたコンテンツはローカルでパースおよび再出力され、フェッチ・アップロード・ログ記録は一切ない。タブを閉じればすべて消去される。

よくある間違い

  1. インデントにタブとスペースを混在させる。最も一般的なエラー。タブはスペックで禁止されているが、一部のエディターは静かに挿入する。エディターで空白を表示する。
  2. 兄弟要素間のインデントが一致しない。兄弟キーは同じカラムに揃える必要がある。スペース2つと4つのインデントの混在はパースを壊す。
  3. boolean・数値・日付・時刻のように見えるクォートなしの値。NO・012・1.10・10:30・yes：クォートする。
  4. コロンの後のスペースがない。key: valueは動作する。key:valueは無効だ（単一の文字列としてパースされる）。
  5. 末尾の空白。一部のパーサーは末尾スペースを有意なものとして扱い、他は扱わない。クロスツール安全な習慣は末尾空白を削除することだ。
  6. 適切なブロックスカラーなしの複数行文字列。長い文字列は|（リテラル、改行を保持）または>（折りたたみ、行を結合）が必要だ。クォートなしのプレーンな複数行テキストは期待通りに動作することはほとんどない。
  7. どこでもアンカー/エイリアスを前提とする。Helmと一部のKubernetesコンテキストは&/*を完全にサポートしていない。本番パイプラインで依存する前にテストする。
  8. エンコードの不一致。YAMLファイルはUTF-8である必要がある。BOM付きUTF-16で保存するWindowsエディターは、一部のパーサーが読めないファイルを生成する。

よくある質問

フォーマッターはコメントを保持しますか？

いいえ。js-yamlライブラリはYAMLをJavaScriptの値にパースしてその値から再出力する。つまりコメント（# like this）はドロップされる。コメントはソーステキストに存在するが、パースされた構造には存在しない。コメントの保持が重要な場合（手動で管理された設定ファイルでは通常そうだ）、そのCST APIを通じたeemeli/yamlのようなコメント保持の代替ツールを使うか、このフォーマッターをラウンドトリップさせるのではなく手動で小さな編集を行う。

サーバーのYAMLパーサーが私のNOをbooleanとして扱うのはなぜですか？

そのパーサーがYAML 1.1（PyYAML・snakeyaml・他の多くのデフォルト）を使用しており、NOをboolean falseとして解釈するからだ。このフォーマッターはデフォルトでYAML 1.2（js-yaml経由）を使用するため、ここではバグは発生しないが、ファイルをYAML 1.1環境に送った瞬間に罠が作動する。曖昧な文字列は常にクォートする：country: "NO"。

YAMLをJSONに変換できますか？

はい、「→ JSON」をクリックする。変換はJSONで表現できるすべてのもの（文字列・数値・boolean・null・配列・オブジェクト）に対してロスレスだ。生き残らないもの：コメント（JSONにはその構文がない）・アンカーとエイリアス（JSONには相当するものがない）・YAMLの日付/タイムスタンプ型（JSONでは文字列になる）。逆方向には専用のJSON to YAMLツールを使う。

サーバーに何か送信されますか？

いいえ。パース・フォーマット・JSON変換はすべてjs-yaml経由でブラウザ内で動作する。貼り付けたYAMLはどのサーバーにも送信されない。YAMLの設定には頻繁にシークレット（Kubernetesのシークレット値・データベースのパスワード・APIキー・内部エンドポイント）が含まれ、これらはサードパーティサービスにアップロードされるべきでないため、これは重要だ。

サイズ制限はありますか？

上限はない。フォーマッターはブラウザのメモリ内で動作する。典型的なKubernetesマニフェスト（数KB）とHelmチャート（数十KB）は即座にフォーマットされる。非常に大きなマルチドキュメントファイル（数MB）は遅いが一般的には動作する。10MBのHelmチャートがある場合は、代わりにCLIツールでローカルでフォーマットする。

YAMLはなぜこんなにエラーが出やすいのですか？

複合的な3つの理由：（1）有意な空白はタイポが静かなセマンティック変更を引き起こすことを意味する。（2）YAML 1.1の寛容な型強制は曖昧な文字列を意図しないboolean/数値に変換する。（3）同じものを書く方法が多すぎる（ブロック対フロー・シングル対ダブルクォート・複数行文字列の3つのフレーバー）。防衛的な習慣（常にクォート・インデントを常に一貫させる・デプロイ前に検証）でサーフェスエリアのほとんどを修正できる。

関連ツール

JSON → YAMLコンバーター

JSONとYAML形式間で変換します。

JSONフォーマッター

JSONデータをフォーマット、検証、美化します。

XMLフォーマッター

XMLをフォーマット、美化、ミニファイします。