JSON→YAML変換
リアルタイムプレビュー付きでJSONをYAML形式に変換します。
使い方
- 左側のエリアにJSONデータを貼り付けまたは入力します。
- 希望のインデント(2または4スペース)を選択します。
- YAML出力は右側にリアルタイムで表示されます。コピーをクリックしてコピーするか、ダウンロードをクリックしてファイルとして保存します。
よくある質問
データは安全ですか?
はい、変換は完全にブラウザ内で行われます。データはサーバーに送信されません。
どのインデントオプションが利用可能ですか?
2または4スペースのインデントを選択できます。デフォルトは2スペースです。
出力を直接コピーできますか?
はい、出力エリアの下の「コピー」ボタンをクリックして、YAMLをクリップボードにコピーします。
仕組み
- JSONを貼り付け: 任意の有効なJSON, フラットなキー値ペアから深くネストされたオブジェクトと配列まで, を入力します。
- 瞬時の変換: ツールは適切なインデントでJSONをYAMLに変換し、文字列キーから引用符を削除し、null、ブール、数値型を翻訳します。
- 出力を構成: インデント幅(2または4スペース)を定義し、コレクションのブロックまたはフロースタイルから選択します。
- YAMLをコピー: 結果は、設定ファイル、CI/CDパイプライン、Kubernetesマニフェストに貼り付ける準備ができています。
なぜJSONをYAMLに変換するのか?
YAMLは、Kubernetes、Docker Compose、GitHub Actions、Ansible、Helmチャートなどのインフラツールで好まれる設定形式です, JSONより読みやすく、コメントをサポートし、各文字列の周りに引用符を必要としません。APIレスポンス、package.jsonセクション、データ構造をJSONからYAMLに変換することは、DevOpsとバックエンド開発で頻繁なタスクです。YAMLのインデントベースの構造は人間にとって読みやすく、JSONはAPIとプログラム生成に好まれます, このコンバーターは両方の橋渡しをします。
型のマッピング
- 文字列 → 可能であれば引用符なし、特殊文字を含む場合は引用符付き
- 数値 → そのままYAML数値スカラー
- ブール → YAMLで
true/false - null → YAMLで
nullまたは~ - 配列 →
-プレフィックス付きのYAMLブロックシーケンス - オブジェクト → key: valueペア付きのYAMLマッピング
JSONからYAMLへの変換とは?
JSONからYAMLへの変換は、キーと値のペアのツリーを、基になるデータを保持しながら、ある直列化形式から別の形式に翻訳します。両方の形式は同じデータ形状 (文字列、数値、ブール値、null、配列、オブジェクト) を記述しますが、JSONは中括弧と角括弧を使用し、YAMLはインデントとダッシュを使用します。同じ構成「name: app, version: 1, ports: 80, 443」はどちらでも表現でき、コンバーターは意味を失うことなく両者の間を移動します。
JSONは、Douglas Crockfordが2001年頃に発明し、2006年にRFC 4627として、2013年にECMA-404として標準化されたもので、ウェブAPIの共通言語です。Clark Evans、Ingy doet Net、Oren Ben-KikiによるYAML 1.0 (2001)、1.1 (2005)、1.2 (2009) は、コメント、複数行文字列、アンカー、エイリアスをサポートし、人間の可読性に最適化されたJSONのスーパーセットとして設計されました。現代のDevOpsツーリング (Kubernetes、Docker Compose、GitHub Actions、Ansible、Helm) は、configsが人間によって書かれ、レビューされるため、YAMLをデフォルトにしました。
このコンバーターは両方の形式を横に並べて配置します。左にJSONを貼り付け、JSONからYAMLをクリックすると、右ペインが選択したインデント深さ (2または4スペース) で有効なYAMLで更新されます。逆ボタンは同じプロセスを逆方向に実行します。変換は、jsDelivrからロードされたjs-yamlライブラリ (Vitaly Puzrin、2011) を使用し、Kubernetesマニフェスト、Helmチャート、OpenAPI仕様をラウンドトリップするのに十分正確にYAML 1.2仕様を実装しています。
コンバーター内部には何があるか
インターフェースは2ペイングリッドレイアウトを使用します: 左にJSON、右にYAML。幅768ピクセル未満の画面では、レイアウトは縦に積み重なります。ペインの上には、レベルごとに2または4スペースを選択できるインデント選択器があります。アクティブな選択はハイライトされ、インデントは両方向の変換に適用されます。
各ペインには独自のアクションボタンがあります。JSONペインはJSONからYAML (変換) とClearを提供します。YAMLペインはYAMLからJSON (逆)、コピー (クリップボード)、Download .yaml (.yaml拡張子とUTF-8エンコーディングのファイルとして保存) を提供します。コンバーターの下のエラーバナーは、行番号と短いメッセージで解析エラーを表示するので、ツールを離れることなく無効な入力を修正できます。
内部では、JSONからYAMLへの変換はJSON.parseとjs-yamlのdump関数を使用します。YAMLからJSONの方向はjs-yamlのload関数と2スペースインデントのJSON.stringifyを使用します。両方向は入力の純粋な関数であり、変換間で状態は引き継がれず、ページをリフレッシュするとすべてがリセットされます。
歴史と背景
Douglas CrockfordがJSONを規定 (2001)
Douglas Crockfordは2001年4月、State Software在籍中、JavaScriptのオブジェクトリテラル構文が言語独立のデータ形式として機能できることに気付いた後、JSON構文を文書化しました。仕様は意図的に最小限でした: 6つのタイプ、2つのコレクション、コメントなし、スキーマなし。RFC 4627は2006年に、ECMA-404は2013年に続きました。ミニマリズムこそが、JSONをウェブで遍在させたものです。
YAML 1.0公開 (2001)
Clark Evans、Ingy doet Net、Oren Ben-Kikiは2001年5月、JSONと同じ年にYAML 1.0をリリースしました。この頭字語はもともとYet Another Markup Languageでしたが、YAMLがドキュメントマークアップではなく構成データを対象としていることを明確にするため、YAML Ain't Markup Languageに改められました。1.0仕様は野心的で、アンカー、エイリアス、マルチドキュメントストリーム、カスタムタグ、コメントをサポートしていました。
YAML 1.1とノルウェー問題 (2005)
YAML 1.1 (2005年1月) は仕様を厳しくしましたが、yes、no、on、off、y、n、true、false、およびそれらの大文字バリアントの文字列がすべてブール値になる有名なブール強制動作を維持しました。これがノルウェー問題です: 引用符のないISO国コードNOがブール値falseになります。バグは初期のKubernetesユーザーを噛みつき、YAML 1.2 (2009) が代替ブール綴りを削除するまで続きました。
YAML 1.2がJSONをサブセットとして宣言 (2009)
YAML 1.2 (2009年10月) は明示的にJSONをYAMLの厳密なサブセットにしたので、有効なJSON文書はすべて有効なYAML文書でもあります。これは大きな設計の勝利でした: YAML 1.2を処理するツールはJSONを無料でパースでき、コンバーターとバリデーターの実装を簡略化しました。今日のほとんどのツーリングで使用されているバージョンは1.2または1.1互換プロファイルです。
KubernetesがYAMLマニフェストを出荷 (2015)
Kubernetes 1.0は、2015年7月にGoogleによってリリースされ、YAMLマニフェストを使用してクラスタリソース (Pod、Deployment、Service) を定義しました。この選択は、テキストエディタとバージョン管理に慣れているopsチームの可読性によって駆動されました。Helm (2016) はその上にテンプレーティングを追加し、GitHub Actions (2018) はワークフローにYAMLを採用し、Ansibleプレイブック (2012-2018) はYAMLを支配的なDevOps構成言語として定着させました。
js-yamlが事実上のJavaScriptライブラリになる (2011年以降)
Vitaly Puzrinは2011年にPyYAMLの純粋JavaScriptポートとしてjs-yamlを公開しました。その後のバージョン (2014年の2.0、2015年の3.0、2021年の4.0) はYAML 1.2仕様を追跡し、危険な機能をオプトアウトするためのスキーマを追加し、週50万件以上のnpmダウンロードに達しました。ライブラリはブラウザサイドのYAML作業のためにwebpack、parcel、esbuildによってバンドルされており、このコンバーターが内部で使用しているものです。
実用的なワークフロー
Kubernetesマニフェストの作成
kubectl run --dry-run=client -o json経由でPodまたはDeploymentを生成すると、JSONを取得します。ここに貼り付け、JSONからYAMLをクリックすると、gitにコミットする準備ができたマニフェストができます。変換は、ネストされた仕様、環境変数、リソース制限をKubernetesが読み取るとおり正確に保持します。
Docker Composeサービス定義
チームメイトが新しいサービス用のJSONスニペットを送ってきます。貼り付けて変換し、YAMLをdocker-compose.ymlにドロップします。2スペースインデントはComposeのデフォルトなので、インデントオプションを2のままにします。
GitHub Actionsワークフロー
JSONベースのテンプレートジェネレーターからワークフローをスキャフォールドしたり、JSON APIレスポンスからステップをコピーしたりするとき、ここに貼り付けて変換します。出力は.github/workflows/*.ymlに直接ドロップします。GitHub Actionsは一部のフィールドでJSONも受け入れますが、YAMLが正規の形式です。
Ansibleプレイブック
Ansibleインベントリは、CMDBまたはアセットデータベースからエクスポートされたJSONとして始まることがよくあります。貼り付けて、YAMLに変換すると、Ansibleの期待スタイルに合うhostsファイルまたはプレイブックヘッダーができます。Ansibleコミュニティスタイルガイドに合わせるために2スペースインデントを使用してください。
Helmチャート値
ベンダーが自分のHelmチャート用のJSONサンプル構成を出荷します。YAMLに変換してvalues.yamlにドロップします。変換はネストされたキー (image.repository、image.tag、resources.limits.memory) をHelmが期待するとおり正確に尊重します。
OpenAPI 3仕様
Swagger EditorはOpenAPI仕様をJSONとYAMLの両方としてエクスポートします。ツールがJSONを発するがチームがバージョン管理でYAMLを使用する場合 (またはその逆)、このコンバーターはNode、Python、yqを起動せずに形式を切り替える最速の方法です。
よくある落とし穴
ノルウェー問題 (yes、no、on、offがブール値として)
YAML 1.1では、yes、no、on、off、y、n、true、false (およびそれらの大文字バリアント) の文字列はすべてブール値です。だから引用符のないISO国コードNOはブール値falseになります。js-yaml 4.xは、trueとfalseのみをブール値として扱うYAML 1.2をデフォルトとしますが、古いYAMLパーサーはまだ躓くかもしれません。ツーリングバージョンを混在させる場合、曖昧な文字列を明示的に引用してください。
タブは有効なYAMLインデントではない
YAMLはインデントにタブではなくスペースを使用します。エディタがデフォルトでタブを挿入する場合、変換されたYAMLはKubernetes、Helm、または厳密なYAMLローダーでのパースに失敗します。エディタを.yamlと.ymlファイルに2または4スペースを使用するように構成するか、コミット前にリンター (yamllint) を実行してください。
アンカーとエイリアスはJSON変換を生き残らない
YAMLは値を再利用するためのアンカー (&name) とエイリアス (*name) をサポートします。YAMLをJSONに変換すると、JSONには同等の機能がないため、アンカーはインラインで展開されます。逆のJSONからYAMLへの変換は、自動的にアンカーを再導入しません。アンカーが必要な場合は、変換後に手で書いてください。
複数行文字列には明示的なインジケーターが必要
埋め込まれた改行を持つJSON文字列 (Hello\nWorld) は、リテラルブロックスカラー (|) または折り畳みブロックスカラー (>) を使用してYAMLに変換されます。js-yamlは正しい形式を選びますが、結果を手動編集する場合は、|が改行を保持し、>がそれらをスペースに折り畳むことを覚えておいてください。
大きな数値は精度を失う
JavaScriptの数値は64ビットIEEE 754浮動小数点数なので、2の53乗 (約9兆) を超える整数はJSON.parseでパースされると精度を失います。YAMLへの変換は、オリジナルではなく、損失のある値を保持します。データがBigIntスタイルの識別子を持っている場合は、変換前にJSONで文字列としてエンコードしてください。
コメントはYAMLからJSONへの変換で失われる
YAMLは#コメントをサポートしますが、JSONはサポートしません。コメント付きYAMLをJSONに戻して変換すると、JSONには構文がないためコメントが削除されます。処理のためにYAMLをJSON経由でラウンドトリップする場合、すべての#行を失うことを期待してください。yqまたはruamel.yamlのようなツールはコメントを保持できますが、仕様準拠のjs-yamlはそれらを削除します。
プライバシーとデータ取り扱い
すべての変換は、ページにバンドルされたjs-yamlライブラリを介してブラウザで実行されます。JSONまたはYAMLをサーバーに送信せず、入力をログに記録せず、変換の内容にアナリティクスを実行しません。コピーボタンはユーザージェスチャーを必要とするClipboard APIを使用し、Download .yamlボタンはメモリ内のblob URLを使用するので、ファイルがネットワーク経由でラウンドトリップすることは決してありません。
ページがロードされると (js-yaml CDNファイルを含む)、ツールはオフラインで動作します。ネットワークから切断し、機密な構成 (APIキー、データベースURL、内部サービス名) を変換できます、何もデバイスを離れることなく。js-yamlファイルはSubresource Integrityハッシュ付きでjsDelivrから提供されるので、バンドルが静かに交換されることはありません。
このコンバーターを使わないとき
メガバイトのデータをストリーミング
コンバーターは入力全体をメモリにロードし、パースし、結果を一度に発します。マルチメガバイトのJSONまたはYAMLファイルの場合、シェルパイプラインでyqまたはjq、お気に入りの言語でストリーミングパーサーを使用してください。ブラウザは5〜10メガバイトを超える場合に適切なツールではありません。
JSONのバイナリデータ
JSONに検査または変更する必要があるBase64エンコードされたバイナリブロブがある場合、YAMLへの変換はそれらを展開しません。YAMLはjs-yamlが処理するタグ付きバイナリ (!!binary) をサポートしますが、バイトはBase64のままです。実際のバイトレベル作業には専用のバイナリエディタを使用してください。
スキーマ検証
このコンバーターは入力が有効なJSONまたはYAMLであることを確認しますが、スキーマ (JSON Schema、OpenAPI、Kubernetes CRD、Helm values) に対して検証しません。Kubernetesマニフェストが1.28クラスタに対して構造的に正しいかどうかを知る必要がある場合は、kubectl --dry-run=serverまたはkubeval、kubeconformのようなツールを実行してください。
スキーマ対応リファクタリング
数百のYAMLファイルでフィールドを名前変更する必要がある場合、またはAPIバージョンをアップグレードする必要がある場合 (apps/v1beta1からapps/v1へ)、明示的なパスクエリでsed、ast-grep、またはyqを使用してください。コンバーターはフォーマット間の変換のみを行い、意味的内容を編集しません。
その他の質問
JSONはYAMLより安全ですか?
セキュリティのために、はい。PyYAMLのyaml.load (5.1以前) および類似の許容的なパーサーは、タグ付きPythonオブジェクトを介して信頼できないYAML入力から任意のコードを実行できました。JSONにはそのような機能はなく、すべてのJSONパーサーは設計上安全です。現代のYAMLパーサー (PyYAML 5.1+、4.0以降のjs-yaml) はデフォルトでsafe-loadなので、ギャップは狭くなりましたが、JSONは信頼できない入力のための依然として安全なデフォルトです。
なぜYAMLは括弧の代わりにインデントを選んだのですか?
YAMLの作者は構成がアウトラインのように読まれることを望んでいたので、Pythonの重要な空白と同じ規則を使用しました。括弧と角括弧は有効なYAML (フロースタイル) ですが、インデント付きのブロックスタイルがデフォルトです、なぜならプレーンテキストで編集する人間にとってより自然にスキャンするからです。トレードオフは、空白が意味を持つようになることで、これは末尾の空白を自動的にトリムするエディタを捕まえます。
YAMLは常にJSONの厳密なスーパーセットですか?
YAML 1.2 (2009) 以降、はい。有効なJSON文書はすべて有効なYAML 1.2文書でもあります。YAML 1.1には関係がより緩いいくつかのエッジケース (六十進数、ノルウェー問題) がありました。現代のjs-yamlはデフォルトで1.2を使用するので、このツールではスーパーセットプロパティが成立します。
なぜKubernetes YAMLはこんなに冗長なのですか?
Kubernetesマニフェストは固定のトップレベル形状 (apiVersion、kind、metadata、spec) を持ち、specにはAPIの内部Go構造体を反映したネストされたオブジェクトが含まれます。冗長性はオブジェクト指向APIをフラットテキスト形式にマッピングする副作用です。Kustomize、Helm、Pulumiのようなツールは冗長性を減らしますが、基礎となるYAMLはkubectlが実際にクラスタに送信するものです。
データ損失なしにJSONをYAML経由でラウンドトリップできますか?
ほとんどのJSONに対して、はい。文字列、数値、ブール値、null、配列、オブジェクトはすべて生き残ります。エッジケースには、非常に大きな整数 (精度損失)、Unicodeサロゲートペア (パーサーに依存)、キー順序 (YAMLは並べ替える可能性がある) が含まれます。JSONキーが元の順序を保持する必要がある場合は、挿入順序を尊重するツール (PythonのOrderedDict、JavaScriptのjson-stable-stringify) を使用してください。
TOMLとHCLはどうですか?
TOML (Tom's Obvious Minimal Language、2013年Tom Preston-Wernerによる) は、Cargo (Rust)、pyproject.toml (Python) などで使用されます。HCL (HashiCorp Configuration Language、2014) はTerraformで使用されます。両方とも構成ユースケースを対象としていますが、異なる構文を使用します。このコンバーターはJSONとYAMLのみを処理します。TOMLまたはHCLには、専用コンバーターまたは適切なプラグイン付きのyqを使用してください。