YAML を JSON に変換

Q: YAML ファイル はどこかにアップロードされますか。

いいえ。この変換は完全にブラウザーの中で行われるので、ファイルが端末から出ることはありません。ご自分で確かめられます。開発者ツールのネットワークタブを開いて、何か変換してみてください。ページそのものと、このサービスの費用をまかなっている分析・広告のリクエストは見えますが、あなたのファイルを運んでいるリクエストはひとつもありません。

Q: YAML から JSON への変換は無料ですか。

はい。アカウントも透かしもなく、消費される 1 日の割り当てもありません。お使いの機械の上で動くので、何度でも戻ってきていただけます。ブラウザーが扱えるのは 100 MB までのファイルで、一度に 100 本です。

Q: YAML を JSON に変換すると品質は落ちますか。

いいえ。JSON は同じ内容を何も捨てずに保持できるので、結果は品質の点で元のファイルと同じです。

Q: YAML から JSON への変換は可逆ですか。

失われるものはありません。YAML も JSON も中身を劣化なしに保持します。この変換が変えるのは包み方であって品質ではないので、劣化が積み重なる心配をせずに何度でも繰り返せます。

Q: YAML から JSON にすると、コメントは残りますか。

コメントは引き継がれません。YAML ではファイルに説明を書き添えられますが、JSON にはコメントの構文そのものがないので、説明の行はすべて落ちます。そして困るのは、まさにコメントが書かれるようなファイル——誰かが引き継ぐ設定ファイルです。

ここで YAML を JSON に変換できます。無料、アカウント不要です。ファイルを上の枠に落とせば、数秒で結果がダウンロードできる状態になります。変換はお使いのブラウザーの中で行われるので、ファイルはアップロードされません。Windows でも macOS でも Linux でも、iPhone でも Android でも同じように動き、通信を切っても動き続けます。

処理される場所 ブラウザーの中です。ファイルがアップロードされることはありません。
可逆何も捨てられません。JSONはYAMLが持っていたものをそのまま保持します。
ファイルサイズの上限 1ファイルあたり100MBまで。無料、アカウント不要です。

一度に100ファイルまで。フォーマットが混ざっていても構いません。

YAML から JSON

テキストとしてではなく、データとして読む

YAML 1.2 は JSON の上位互換として設計されているため、JSON の文書はそのまま有効な YAML でもあります。この変換は、同じデータから省略記法をすべて取り除いて書き出しているにすぎません。だからこそデバッグに役立ちます。JSON に出てくるのは、入力した文字ではなく、パーサーが実際に導き出した値だからです

YAML でつまずく原因の多くは、値の解釈にまつわる意外な結果です。バージョン番号が数値になっていた、ある単語が真偽値として扱われていた、参照が想定より多くの内容を引き込んでいた。こうしたことは YAML の見た目からは分からず、JSON にすると一目で分かります。

複数文書のYAMLは変換できない

YAML は --- という行で区切って、1つのストリームに複数の文書を持てます。Kubernetes のマニフェストではこれが日常的に使われ、1つのファイルの中に Deployment と Service と ConfigMap が並んでいることも珍しくありません。JSON にはこれに相当する仕組みがなく、1つの JSON ファイルは1つの値しか持てません。

そのため、パーサーはどれか1つを勝手に選ぶのではなく、その場で変換を拒否し、2つ目の文書が始まる行を示します。--- で区切って1文書ずつ変換するか、変換前に配列としてまとめておく必要があります。

アンカーは展開され、マージキーはマージされない

アンカーとエイリアスは、参照先の内容をそのままコピーした形に展開されます。JSON には他の場所を参照する仕組みがないため、これが唯一の忠実な表現です。1か所に定義した内容を複数のジョブから参照している設定ファイルは、変換すると同じ内容が繰り返し現れる、元より大きな JSON になります。

つまずきやすいのはマージキーです。<< に続けてエイリアスを書く記法は、YAML 1.1 時代の慣習であり、このパーサーが実装する YAML 1.2 のコアスキーマには含まれません。そのため "<<" という名前の普通のキーとして、参照先のオブジェクトを値に持つ形でそのまま出てきます。マージされているはずだったキーは、想定より1階層深い場所にあります。

独自タグは警告なく消える

CloudFormation の短縮記法など、!Ref のような独自タグに意味を持たせる方言がいくつも存在します。このパーサーはそうしたタグを知らないため、それぞれを裸の値に解決してから先に進みます。!Ref myBucket は単なる文字列の "myBucket" になり、タグが付いていたという情報は残りません。

これはこのページで最も注意が必要な変換です。出てきた JSON は文法的に正しく、もっともらしく見えますが、意味が変わっています。独自タグを使う方言の YAML を扱っているなら、あらかじめそれを知っておくことが唯一の防御策です。

どの単語が真偽値になるか

YAML 1.1 では yes、no、on、off、y、n がすべて真偽値として扱われ、国コードの no が false になってしまうという有名な問題を生みました。このパーサーが実装する YAML 1.2 のコアスキーマは true と false だけを真偽値として認識するため、こうした単語は文字列のまま残ります。

ただし、これはこのパーサーの既定の挙動にすぎません。ファイルの先頭に %YAML 1.1 という指示行があれば1.1として読まれ、on は真偽値になります。また、実際の運用で使われるパーサーが1.1系の実装であることもあるため、このページの結果は1.2のパーサーがどう見るかの参考として扱ってください。

数値として解釈される値

1.0と書かれた値は数値の1として解決され、小数点が消えます。0755と書かれた値は755になります。元の値の周りに引用符を付ければ文字列のまま保たれ、JSONの出力にも引用符が現れます。この違いを見れば、引用符が必要な値を素早く洗い出せます。

大きな整数は精度が静かに失われることがあります。YAML の整数には桁数の制限がありませんが、JSON の数値は倍精度浮動小数点数なので、桁数の多いIDは末尾の桁が変わってしまうことがあります。大きな数値を扱う場合は、変換前に文字列として引用符で囲んでおいてください。

JSONに持ち場のない型はどうなるか

!!timestamp というタグを持つ値は日付として解釈され、UTC に正規化された ISO 8601 の文字列になります。マイナス5時間のオフセットを持つ時刻は、その分だけシフトされてZ付きの表記になり、元のオフセットの情報は残りません。

!!binary の値はバイト列に変換されたのち、位置をキーとするオブジェクトとして書き出されます。データ自体は保持されますが、その形をそのまま活用できるツールはほとんどありません。タグのない日付らしき文字列は、YAML 1.2のコアスキーマのもとでは単なる文字列として扱われ、そのまま残ります。

変換自体が失敗する場合

同じマッピングの中にキーの重複があると、行番号とともに拒否されます。他のツールより厳格に見えるかもしれませんが、重複キーというのは、片方の設定が追加された瞬間から無視され続けていたことを意味するので、これはむしろ正しい振る舞いです。

インデントにタブ文字が使われている場合も拒否されます。YAML の仕様でタブは禁止されているためです。どちらのエラーも、読み込むパーサーによって挙動が変わりかねないファイルであることを教えてくれています。

出てきたJSONの使い道

出力はスペース2つでインデントされ、末尾に改行が付くので、jq や JSON Schema のバリデーター、HTTP クライアントにそのまま渡せます。検証はこの変換を行う最も強い理由です。YAML の構文チェックは文法しか見ませんが、生成した JSON をスキーマに通せば、タイプミスしたキーのような意味的な誤りまで見つかります。

ただし YAML の代わりにはなりません。コメントは失われ、アンカーは重複したデータに展開され、独自タグは静かに消えています。YAML を正本として保ち、JSON はその一時的な見え方として扱ってください。