YAML ↔ JSONについて
Kubernetes マニフェスト、GitHub Actions、Spring 系設定は YAML が多く、REST のモックや jq は JSON 向きです。{ または [ で始まる入力は JSON→YAML、それ以外は YAML を parse して 2 スペース JSON を出します。
合法 JSON は YAML としても読めますが、YAML にはコメント・アンカー・柔軟な引用など独自拡張があります。本ツールは map・リスト・スカラーなど両形式で共有するデータモデルを対象にします。
できること
方向の自動判定
YAML テキストは 2 スペース整形 JSON に、JSON オブジェクト/配列は読みやすい YAML に変換します。キー順はパーサ結果に従います。
きれいに通る内容
- map、リスト、文字列、数値、真偽値、null など典型的な設定・フィクスチャ。
- JSON 構文は YAML の部分集合なので、多くの設定断片は往復しやすいです。
- アンカー (&)、エイリアス (*)、マージキー、カスタムタグは保持されません。
- YAML のコメントは JSON へ行く際に落ちます（JSON にコメント構文がないため）。
K8s・DevOps での注意
- 多行文字列（|、>）は改行入り JSON 文字列になります。下流ツールで引用を確認してください。
- 非常に大きい整数は厳密 JSON パーサと見え方がずれることがあります。API Schema と照合を。
- --- で区切る複数ドキュメントは、1 回の貼り付けで 1 ドキュメントずつ処理してください。
失敗しやすい原因
- インデント不一致や Tab 混在（YAML は空白に敏感）。
- 先頭キーの前に BOM や余分な文字 — trim して再試行。
- JSON に末尾カンマやコメントがある — JSON→YAML の前に修正。
よくある使い方
K8s と CI 設定
Deployment や ConfigMap の断片を JSON にして jq、OPA、OpenAPI 例で使う。ベンダーが JSON サンプルしか渡さないときは YAML 草稿に戻す。
Mock と docker-compose
curl の JSON を YAML にし、docker-compose や Helm values の書き方と見比べてからコミット。
ドキュメントレビュー
README や Schema レビューで、同じフィクスチャを YAML/JSON 両方で並べ、フィールド漏れを減らす。
テストデータの共通化
Jest、pytest、Go testdata 間で JSON/YAML を行き来し、手でインデントを直す手間を減らす。
よくある質問
- YAML を JSON にする手順は？
- YAML を貼り「変換」（または自動判定）します。出力がインデント JSON です。貼り付けが { または [ で始まる場合は JSON とみなし YAML を出力します。
- YAML と JSON の関係は？
- 合法 JSON は YAML としても parse できますが、YAML 独自のコメントやアンカーなどは JSON 側に残りません。カスタムタグ付き YAML は完全な往復が難しい場合があります。
- YAML 変換が失敗する典型原因は？
- インデントのずれ、Tab、先頭のゴミ文字が多いです。短い断片に分け、パーサが示す行付近を直してください。
- 真偽値と null はどうなる？
- YAML の true/false/null は JSON の true/false/null になります。"yes" のように引用符付きは文字列のまま。未引用の yes/no はエンジンによって真偽値になることがあるので、文字列が欲しければ引用してください。
- 複数 YAML ドキュメントを一度に変換できますか？
- いいえ。--- で区切り、1 ドキュメントずつ貼り付けてください。必要ならエディタ側で結果をマージします。
- YAML のコメントは JSON に残りますか？
- 残りません。コメントが重要なら YAML ソースを版管理に残してください。
- 変換後に数字の見え方が変わるのはなぜ？
- YAML が長い数字列を整数として読む一方、Schema 上は文字列 ID のことがあります。文字列 ID が必要なら YAML 側でクォートしてから変換してください。