YAMLフォーマッター：オンラインでYAMLのフォーマット、検証、整形

YAML 1.2（2009年）は最も悪名高いYAMLの落とし穴を解決しました：YAML 1.1では、クォートなしの「yes」、「no」、「on」、「off」、「true」、「false」はブール値として解釈されます。「NO」（ノルウェー）や「YES」のような国コードはブール値のfalseとtrueになります——このバグはあまりに一般的で「ノルウェー問題」と呼ばれています。YAML 1.2は「true」と「false」（大文字小文字区別なし）のみをブール値として認識します。当フォーマッターは曖昧な値を検出し、クォートすることを推奨します。

YAMLインデントの黄金律：ネストレベルごとに2スペースを使用し、絶対にタブを使用しないこと。YAML 1.2はインデント用のタブ文字を明示的に禁止しています（タブにはインデント値がありません——パーサーの列カウンターでは0として表示されます）。スペースをタブに変換したソース（一部のチャットアプリケーション、Webフォーム、PDF）からYAMLをコピーした場合、バリデーターはすべてのタブをその正確な位置でフラグ付けします。

YAMLアンカー（&）とエイリアス（*）を使用すると、値を一度定義し、同じドキュメント内で複数回参照できます。例えば：`defaults: &defaults timeout: 30 retries: 3` はアンカーを定義し、`service_a: <<: *defaults` はそれらのデフォルトをservice_aにマージします。これはDocker Composeでサービス間で共通の設定を共有するため、およびKubernetesで大きなマニフェストの繰り返しを減らすために広く使用されています。

YAMLの複数行文字列には2つのスタイルがあります：リテラルブロックスカラー（|）は改行を保持します——シェルスクリプト、SQLクエリ、または改行が重要なコンテンツに使用します；折りたたみブロックスカラー（>）は改行をスペースに折りたたみます（HTMLのように）——長い段落、説明、またはリフローすべきテキストに使用します。デフォルトの末尾改行動作を|-（末尾改行を削除）または|+（追加のものを含めて末尾改行を保持）で上書きします。

YAMLのコメント（# コメント）サポートは、設定ファイルにおけるJSONに対する唯一最大の利点です。コメントを使用すると、値が選ばれた理由を文書化し、Jiraチケットにリンクし、TODOをマークし、自明でない設定を説明できます——すべてパーサーを壊すことなく。JSONやJSON5の回避策（"__comment": "explanation"のようなもの）はハックです。YAMLではコメントは第一級市民です。

YAMLマージキー（<<）は、あるマッピングのキーを別のマッピングにマージする特別なマッピングキーです。YAML 1.1仕様の一部であり、YAML 1.2コアには含まれていませんが広くサポートされています。Docker Composeはサービステンプレートを定義するためにアンカーと共にマージキーを多用しています。ただし、マージキーにはネストされたマッピングに関する既知のエッジケースがあります——ディープマージとシャローマージの期待について明示的になってください。

デプロイ前にCI/CDでYAMLファイルを検証してください。ローカルテストでは通るがCIでは失敗する不正な形式のYAMLは開発者の時間を無駄にします。YAMLリントステップをパイプラインに追加してください：`yamllint .` または `python -c "import yaml; yaml.safe_load(open('config.yaml'))"`。当オンラインバリデーターはGitHub Actionsと統合されました——YAML設定の検証ステータスを表示するバッジをリポジトリに追加してください。

「YAMLからJSONへの変換エラー」という不可解なメッセージで起動に失敗するKubernetesポッドをデバッグする場合、問題はほぼ常にマニフェスト内のYAMLフォーマットエラーです。当フォーマッターはインデントエラー、重複キー（YAMLでは最後の値がサイレントに優先されます——不可解に無視される設定の一般的な原因）、間違ったネストレベルに配置されたフィールドを検出します。マニフェストをフォーマットしてから、kubectlで再適用してください。