基礎知識 · テキスト・データ・セキュリティ
JSON・YAML・XML の違いは？どの形式を使うべきか
結論
JSON、YAML、XML は構造化データを表すテキスト形式です。JSON はコンパクトで厳格、値の型は6種類で、Web API の主流です。YAML はインデントで構造を表し、コメントを書けるため、設定ファイルでよく使われます。XML はタグと属性を使い、名前空間と正式なスキーマに対応しており、文書、企業システム、フィードでいまも広く使われています。3つとも同じ入れ子のデータを表現できます。
JSONフォーマッタを開く同じデータを3つの形式で書く
名前、有効フラグ、2つの役割を持つユーザーは、各形式で次のようになります。
| 形式 | 例 |
|---|---|
| JSON | {"name": "Ana", "active": true, "roles": ["admin", "editor"]} |
| YAML | name: Ana / active: true / roles: [admin, editor]（1行に1キー） |
| XML | <user active="true"><name>Ana</name><role>admin</role><role>editor</role></user> |
JSON と YAML は、ほとんどのプログラミング言語のオブジェクト、リスト、スカラー値にそのまま対応します。XML は要素のツリーを表し、オブジェクトへの対応づけは慣習にすぎません。この例でも有効フラグは属性にも子要素にもでき、XML 自体には値がテキストの true ではなく真偽値だと示す仕組みがありません。
並べて比較
| JSON | YAML | XML | |
|---|---|---|---|
| 仕様 | RFC 8259、ECMA-404 | YAML 1.2.2（2021年） | W3C XML 1.0 第5版 |
| 構造 | 波かっこと角かっこ | インデント | 開始タグと終了タグ |
| コメント | 書けない | # comment | <!-- comment --> |
| 組み込みの型 | オブジェクト、配列、文字列、数値、真偽値、null | マップ、シーケンス、型が解決されるスカラー | スキーマで型を指定しない限りテキストのみ |
| スキーマ言語 | JSON Schema | 通常は JSON Schema | XSD、DTD、RELAX NG |
| その他の機能 | なし | アンカーとエイリアス、1ファイルに複数ドキュメント | 属性、名前空間、混合コンテンツ |
| 主な用途 | Web API、ブラウザーのデータ、ログ | 設定：Kubernetes、CI パイプライン、Docker Compose | Office ファイル、SVG、RSS、SOAP、Android のレイアウト |
JSON：厳格で予測しやすい
JSON の文法は1ページに収まるほど小さく、そのためどの言語のパーサーでも解釈が一致します。その厳格さが、よくあるエラーの原因にもなります。
- キーと文字列にはダブルクォートが必要で、シングルクォートは無効です。
- オブジェクトや配列の最後の要素のあとにカンマ（末尾カンマ）は付けられません。
- コメントが書けないので、JSON で書いた設定ファイルには説明を入れられません。JSONC や JSON5 などの派生形式はコメントを追加できますが、標準の JSON ではありません。
- RFC 8259 は、システム間でやり取りする JSON には UTF-8 を使うよう求めています。
文法上、数値の大きさに上限はありませんが、RFC 8259 はほとんどのソフトウェアが IEEE 754 の倍精度浮動小数点数を使うと注記しています。JavaScript では 9007199254740992（2^53）を超える整数は精度が失われるので、大きな ID は文字列として送るほうが安全です。
YAML：読みやすいが、落とし穴もある
YAML は人が読み書きしやすいように設計されており、YAML 1.2 は JSON のほぼ上位互換なので、ほとんどの JSON ファイルは YAML としても有効です。ただし柔軟さには代償があります。
- インデントが構造そのものです。スペースが1つずれるだけで入れ子が変わり、インデントにタブは使えません。
- クォートしない値は型が推測されます。いまも多くのパーサーが使う YAML 1.1 のルールでは
no、off、yesが真偽値になるため、国コードのNOがfalseに変わります。YAML 1.2 のコアスキーマで真偽値として扱うのはtrueとfalseだけですが、使っているパーサーがどのバージョンを実装しているか確認しましょう。 1.10のような値は数値の1.1に、012は8進数になることがあります。バージョン番号や郵便番号など、数値に見えるだけの文字列はクォートしましょう。
XML：冗長だが、文書のために作られている
単純なデータでは XML は JSON より重くなりますが、他の形式にできないことができます。混合コンテンツ（<p>Hello <b>world</b></p> のようにインラインのマークアップを含むテキスト）、出どころの異なる語彙を1つのファイルに共存させる名前空間、XSD による成熟した検証などです。DOCX、XLSX、SVG、RSS などの形式の中身は XML です。
XML から JSON への変換は、本質的に情報が失われます。属性、要素の順序、繰り返し要素、混合コンテンツには JSON で一意に対応するものがないため、変換ツールは属性に @ を付ける、繰り返し要素を必ず配列にするといった慣習を選んでいます。
よくある質問
YAML は JSON の上位互換ですか？
YAML 1.2 は JSON のほぼ厳密な上位互換になるよう改訂されたので、ほとんどすべての JSON ドキュメントは YAML として解析できます。一部の特殊なケースでは違いがあり、YAML 1.1 のパーサーは互換性がより低くなります。
JSON でコメントが書けないのはなぜですか？
作者が、相互運用性を壊すような解析指示をコメントに入れられないよう、あえて除外したためです。設定ファイルにコメントが必要なツールは、代わりに JSONC、JSON5、YAML を使います。
JSON と XML ではどちらが速く解析できますか？
同じデータなら、たいてい JSON のほうが速く、サイズも小さくなります。文法が単純で、終了タグ、属性、名前空間がないためです。差が問題になるのは主に大量のデータを扱う場合です。
YAML を JSON に変換しても何も失われませんか？
データは残りますが、コメント、アンカー、キーの書式は失われます。JSON にはそれらを入れる場所がないからです。JSON から YAML への変換では何も失われません。