JSON ～ YAML: 機械出力を再び読み取り可能にします

そもそもなぜ JSON を YAML に変換するのか

2 つの形式は同一のデータを保持しますが、異なるリーダー向けに最適化されています。 JSON は中括弧、カンマ、引用符に文字を使用します。 YAML は、目がインデントとして追跡できる構造にそれらを費やします。プログラムによって生成および消費されるデータの場合は、JSON が優先されます。個人が編集するデータ (Helm 値、CI 定義、Ansible インベントリ、Docker Compose ファイル) の場合は YAML が優先されます。生成されたデータに人間の所有者が必要な場合には常にこの方向性が登場するのはこのためです。

コメントは生き残れない唯一のものです

変換により可読性は復元できますが、意図は復元できません。ソース JSON には引き継ぐコメントがありませんでした。生成された YAML がユーザーによって保守される場合は、そのファイルの出所と再生成の内容を説明する短いヘッダー コメントを追加して、次回のデプロイ時に上書きされるファイルを編集する人がいないようにします。

引用：変換されたYAMLが静かに壊れる場所

YAML は、いくつかの裸の単語を文字列ではなく値として扱います。引用符を積極的に削除するコンバーターは、表示されている文字を 1 つも変更せずに型を変更できます。

                country: NO        # parses as boolean false in YAML 1.1
version: 1.10      # parses as the number 1.1
time: 22:30        # parses as a sexagesimal integer
name: "on"         # quoted on purpose — must stay a string
              

良好な出力では、すべてを引用するのではなく、誤読される可能性のある文字列 (`yes`/`no`/`on`/`off`、数値に見える識別子、先頭にゼロが付いている値、時刻、日付) を引用します。これにより、回避しようとしていた句読点の壁が生じます。

インデントと複数行の文字列

2 つのスペースが安全なデフォルトです。これは、Kubernetes ドキュメント、Helm テンプレート、およびほとんどの編集者が想定しているものであり、ツール間でコピーアンドペーストしても存続します。 4 スペース スタイルでの深いネストは、約 6 レベルを超えるとスキャンが困難になります。長い文字列はもう 1 つの書式設定の決定です。改行が埋め込まれた JSON 値は、エスケープされたワンライナーとして、または自然に読み取れる YAML ブロック スカラーとして出力されます。フィールドがシェル スクリプトまたは構成スニペットの場合は、ブロック形式を要求します。

キーをソートすると差分が意味のあるものになります

JSON オブジェクト キーの順序は重要ではないため、コンバータは自由に順序を変更できます。キーをアルファベット順にソートすると、再生成されたファイルの差分がきれいに作成されます。これを行わないと、変更された展開順序はファイル全体の書き換えとして表示されます。 git で生成された YAML を追跡している場合、ソートは 1 行の差分と 200 行の差分の違いとなります。

往復を 1 か所にまとめて保存

2 つの方向は逆であるため、コンテキストを切り替えたり、構成を 3 つの異なるサービスに貼り付けたりすることなく、変換、編集、および元に戻すことができるように、両方を同じツールに含める価値があります。このサイトのブラウザベースのコンバータは、YAML to JSON ツールとペアになっており、オフラインで動作し、ペイロードをアップロードしません。これは、問題の JSON が本番環境の API 応答である場合に重要です。