5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

JSON と YAML(or TOML) の使い分け

Last updated at Posted at 2020-12-16

JSON か YAML どっちを使うべきだろう、となったときの個人的な判断基準。現実には様々な制約があったりするので必ずしもこの基準に従うのが良いとは限らないが、目安にはなると思う。

JSON

  • 機械: read & write
  • 人間: read-only

人間が読むこともあるが、編集はしなくて済むような用途が向く。Web API の応答などはおおむねこの性質を持ち、事実広く採用されている。デバッグ時や緊急対応時には、テキストエディタで人間が編集する道も残されているのがテキストフォーマットである JSON の利点である。

YAML

  • 機械: read-only
  • 人間: read & write

主に人間が作成や編集を行い、機械は読むだけといった用途に向く。翻訳定義のような静的データや、アプリケーションの設定ファイルなどは JSON よりも YAML が良い。機械から書き出す場合は、最初に雛形を生成するだけに留めるのが無難である。

TOML

  • 機械: read-only
  • 人間: read & write

TOML は利用経験が浅いためあまりはっきりしたことは言えないが、ほぼ YAML と同等の用途と思って良さそうである。 YAML よりもいくらかシンプルで、人間が編集するという観点ではこちらの方が若干やりやすい。後発なだけに言語やライブラリのサポートはまだこれからといった印象だが、環境が整っているなら YAML の代わりにこちらを採用しても良さそうだ。ただ YAML 特有の機能を利用したいのであれば自然と YAML になるだろう。

機械も人間も read & write な用途には何が良いか

JSON を採用の上、人間が編集するためのインターフェースを用意し、実際にファイルを編集するのは機械とすることで、人間側の write 需要をできるだけ減らすのが最も無難だと思う。人間用のコメントが欲しければ、コメントも JSON 構造の中に含めてしまうという策がある。

YAML も検討の余地はあるが、機械が編集する際に人間のための表現(コメントなど)が失われたりしないように気を付ける必要がある。

TOML に関しては経験が浅くなんとも言い難いが、こちらも YAML 同様、機械での編集時に人間のための表現が壊れる可能性が高そうに見えるのが懸念点だ。

5
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?