JSON ↔ YAML 変換
JSONをYAMLに、YAMLをJSONに、ブラウザ内でそのまま変換できます。どちらの形式を貼り付けても、インデントの整ったきれいな出力が得られ、設定ファイルやCIパイプライン、Kubernetesマニフェストに最適です。
インデント
上にデータを入力すると、変換結果がここに表示されます。
JSON ↔ YAML 変換 の使い方
- 1
変換の方向を選ぶ
トグルで「JSONをYAMLに」か「YAMLをJSONに」を選びます。入れ替えボタンを押すと結果が入力欄に移り、逆方向に再変換できます。
- 2
データを貼り付ける
JSONまたはYAMLを入力欄に貼り付けます。入力すると同時に変換が自動で実行され、構造・ネスト・データ型はそのまま保持されます。
- 3
インデントを選ぶ
プロジェクトのスタイルに合わせて、2スペースか4スペースのインデントを選びます。どちらの形式でも、出力はきれいで正しいインデントを保ちます。
- 4
結果をコピーする
変換結果を確認してクリップボードにコピーすれば、設定ファイルやパイプライン、コードにそのまま貼り付けられます。
JSONからYAMLへ: 落とし穴のない、よりすっきりした設定
YAMLはJSONのスーパーセットである
すべての有効なJSON文書は、有効なYAMLでもあります。これは偶然ではなく、YAML仕様の保証です。YAMLはその上に、より人間に優しい層を加えます。波括弧や角括弧の代わりに、構造はインデントで表現され、コンマの代わりに、項目はそれぞれ自分の行に並び、そしてJSONとは違い、YAMLはコメントをサポートします。その結果、データの羅列ではなくアウトラインのように読め、これがYAMLが設定ファイルを席巻している理由です。
データモデルがこれほど近く対応しているので、つまり両方ともマップ、シーケンス、文字列、数値、真偽値、null を持つので、両者の間の変換は機械的で、値そのものについては無損失です。変換は同じ木を別の表面の構文で表現し直します。JSONの往復を生き延びられない唯一のものはコメントです。JSONにはそれを置く場所がないからです。
インデントが構文である
YAMLでは、空白は見た目だけのものではなく、構造そのものです。入れ子は、子のキーを親よりも深くインデントすることで示され、同じ深さの項目は同じインデントを共有しなければなりません。キーの下に入れ子になったマップは、その下のインデントされた行の集まりになり、リストはそれぞれダッシュで始まる行になります。インデントを間違えると、見た目だけでなく意味が変わってしまい、これはJSONが空白を扱う仕方とは正反対です。
一貫したインデント幅を選んでください。設定ファイルでは2スペースが一般的な既定で、一部のハウススタイルでは4スペースです。そしてそれをどこにでも適用してください。変換器はきれいで均一なインデントを出力するので、手で行を揃えるのではなく、正しい土台から始められます。
タブは禁じられている
これは、ほとんど誰もが最初に引っかかるルールです。YAML仕様は、インデントにタブ文字を使うことを明示的に禁じています。スペースを使わなければなりません。Tab キーを押したときにタブを挿入するように設定されたエディターは、ひそかにパースに失敗するファイルを生み出し、しばしばエラーメッセージが間違った場所を指します。パーサーは1〜2行後になって初めて構造が壊れていることに気づくからです。
YAMLファイルが読み込みを拒み、インデントが正しく見えるなら、まずタブを確認してください。YAMLファイルでは空白を表示するか、タブをスペースに変換するようにエディターを設定しましょう。JSONから変換すれば、生成された出力は最初からスペースでインデントされているので、これを完全に回避できます。
ノルウェー問題とそのほかの驚きの真偽値
古いYAMLパーサーは、驚くほど幅広い裸の単語を真偽値として解釈します。true と false だけでなく、さまざまな大文字小文字の yes、no、on、off もです。古典的な災難は、国コードのリストで、Norway のための項目が裸の文字 n と o として書かれていると、真偽値の false と読まれ、データからひそかに消えてしまうことです。on や off と書かれたトグルのフラグも、同じように型が変わることがあります。
防御は引用です。真偽値、数値、日付、null と取り違えられうる文字列は、パーサーがテキストとして保つように引用符で囲むべきです。安全なスキーマを軸に作られた現代のパーサーはより厳格で、これにはるかに陥りにくいですが、曖昧なスカラーを引用する習慣は、特に短いコード、バージョンのような文字列、そしてユーザーが入力したあらゆるものについて、持っておく価値があります。
さらなるスカラーの落とし穴: 数値、先頭のゼロ、null
ほかにもいくつかの裸の値が人を驚かせます。先頭にゼロのある郵便番号や部品番号は、数値として読まれてゼロを失ったり、一部のパーサーで8進数と解釈されたりすることがあります。1.20 のようなバージョン文字列は、数値の 1.2 に強制され、末尾のゼロを落とすことがあります。単語の null、空の値、そして単独のチルダは、いずれも null を意味します。真偽値の罠と同じく、対処法も同じです。テキストの形が重要なものは何でも引用してください。
このツールは安全なスキーマでパースするので、標準のデータ型だけを読み込み、任意のオブジェクトを構築したりコードを実行したりすることは決してありません。そのため信頼できないYAMLを貼り付けても、何も実行できません。これは変換を予測可能に保ちます。返ってくるのはプレーンなマップ、シーケンス、スカラーであり、タグを通じて密輸された驚きのカスタム型は何もありません。
YAMLが実際に住んでいる場所
YAMLの読みやすさは、それをインフラとCIツールの共通語にしました。Docker Compose ファイル、Kubernetes マニフェスト、GitHub Actions と GitLab CI のパイプライン、Ansible のプレイブック、そして数えきれないアプリケーションの設定ファイルは、すべてYAMLです。それらのどれにおいても、YAMLが許すコメントときれいな差分は、人間が本番設定への変更をレビューしなければならないときの本物の利点です。
対照的にJSONは、API越しの機械同士の交換に、より適したままです。そこでは、その厳格さと空白への非感受性が曖昧さを減らします。よくあるパターンは、人間の快適さのためにYAMLで書いて編集し、ツールやエンドポイントが求めたときにJSONに変換することです。これこそが、この変換器が両方向に動く理由です。
ブロックスタイル、フロースタイル、そして出力を読む
YAMLは同じデータを2通りに表現できます。ブロックスタイルはマップとリストをインデントされた行に広げ、読みやすい設定に望むものです。フロースタイルはインラインの波括弧と角括弧を使い、ほとんどJSONそっくりに見えます。これは、より大きな文書に埋め込まれた短くコンパクトな値にときどき便利です。両方を知っておくと、他の人が書いたYAMLを混乱せずに読めます。
ここで変換するときは、JSONを貼り付け、インデント幅を選び、リポジトリに入れる前にブロックスタイルの出力を確認してください。すべてはブラウザの中でローカルに起こるので、設定ファイルの中の秘密、つまりトークン、接続文字列、内部のホスト名は、決してデバイスから出ません。これにより、無害化された例ではなく本物のデプロイのマニフェストを変換しても安全になります。
よくある質問
JSONとYAMLの違いは何ですか?
JSONをYAMLに変換するにはどうすればよいですか?
YAMLをJSONに逆変換することもできますか?
信頼できないYAMLをここで解析しても安全ですか?
入力したデータはサーバーに送信されますか?
関連ツール
こちらの便利なツールもどうぞ