RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format
- ステータス: Proposed Standard
- 発行日: March 2014
- ストリーム: IETF
- 廃止: RFC4627, RFC7158
- 廃止: RFC8259
- エラッタ: エラッタなし
概要 (Abstract)
JavaScript Object Notation (JSON) は, 軽量でテキストベース, 言語に依存しないデータ交換フォーマットです。ECMAScriptプログラミング言語標準に由来します。JSONは, 構造化データの移植可能な表現のための小さなフォーマット規則のセットを定義します。
この文書は, 他のJSON仕様との不整合を排除し, 仕様エラーを修正し, 経験に基づいた相互運用性ガイダンスを提供します。
JSONの中核概念
データ型
JSONは以下のデータ型をサポートします:
プリミティブ型 (Primitive Types):
string- 文字列number- 数値boolean- ブール値 (true/false)null- null値
構造化型 (Structured Types):
object- オブジェクト (順序付けられていないキー値ペアの集合)array- 配列 (順序付けられた値のシーケンス)
構文の例
オブジェクト (Object):
{
"name": "張三",
"age": 30,
"city": "北京"
}
配列 (Array):
[1, 2, 3, 4, 5]
ネストした構造:
{
"users": [
{"name": "Alice", "age": 25},
{"name": "Bob", "age": 30}
],
"total": 2
}
RFC 4627からの主な変更点
- JSONテキスト定義の緩和: JSONテキストをオブジェクトや配列だけでなく, 任意のJSON値として許可
- 正誤表の修正: RFC 4627で報告されたエラーを修正
- 相互運用性ガイダンス: 実装の相互運用性に関するより多くのアドバイスを提供
- エンコーディングの明確化: UTF-8エンコーディングの使用を強調
関連リソース (Related Resources)
- 公式原文: RFC 7159 (TXT)
- 公式ページ: RFC 7159 DataTracker
- 廃止: RFC 4627 (旧JSON仕様)
- 廃止される: RFC 8259によって廃止されました
- メディアタイプ:
application/json - ファイル拡張子:
.json
クイックリファレンス
MIMEタイプ
Content-Type: application/json; charset=UTF-8
よく使用されるツール
オンライン検証:
プログラミング言語のサポート:
JavaScript:
const obj = JSON.parse('{"name":"Alice"}');
const str = JSON.stringify({name: "Bob"});
Python:
import json
obj = json.loads('{"name":"Alice"}')
str = json.dumps({"name": "Bob"})
Java:
// JacksonまたはGsonライブラリを使用
ObjectMapper mapper = new ObjectMapper();
MyObject obj = mapper.readValue(jsonString, MyObject.class);
重要な注意: RFC 7159はRFC 8259によって置き換えられましたが, JSONの進化の歴史を理解するための重要な文書です。最新のアプリケーションは, 現在の標準としてRFC 8259を参照すべきです。
1. Introduction (はじめに)
JavaScript Object Notation (JSON) は, 構造化データのシリアル化のためのテキストフォーマットです。これは, ECMAScriptプログラミング言語標準第3版 [ECMA-262] で定義されているJavaScriptのオブジェクトリテラルに由来します。
JSONは, 4つのプリミティブ型 (文字列, 数値, ブール値, null) と2つの構造化型 (オブジェクト, 配列) を表現できます。
文字列は, 0個以上のUnicode文字 [UNICODE] のシーケンスです。この参照は特定のバージョンではなく, Unicodeの最新バージョンを指していることに注意してください。Unicode仕様の将来の変更がJSONの構文に影響を与えることは予想されていません。
オブジェクトは, 0個以上の名前/値ペアの順序付けられていないコレクションであり, 名前は文字列で, 値は文字列, 数値, ブール値, null, オブジェクト, または配列にすることができます。
配列は, 0個以上の値の順序付けられたシーケンスです。
「オブジェクト」と「配列」という用語は, JavaScriptの慣例に由来します。
JSONの設計目標は, 最小限, 移植可能, テキストベース, そしてJavaScriptのサブセットであることでした。
1.1. Conventions Used in This Document (この文書で使用される規約)
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, [RFC2119] で説明されているように解釈されるべきです。
この文書の文法規則は, [RFC5234] で説明されているように解釈されるべきです。
1.2. Specifications of JSON (JSONの仕様)
この文書は, JSONを記述し, メディアタイプ "application/json" を登録した [RFC4627] を更新します。
ECMAScript用語でのJSONの説明は, ECMAScript仕様 [ECMA-262] のバージョン5.1, セクション15.12に記載されています。JSONは [ECMA-404] でも説明されています。
すべてのJSON文法仕様は, 言語の構文要素について一致しています。
1.3. Introduction to This Revision (この改訂版への序論)
RFC 4627が公開されてからの数年間で, JSONは非常に広く使用されるようになりました。この経験により, 仕様では許可されているものの, 相互運用性の問題を引き起こす特定のパターンが明らかになりました。
さらに, 少数の正誤表が報告されました (RFCエラッタID 607 [Err607] および3607 [Err3607] を参照)。
この文書の目標は, これらの正誤表を適用し, 他のJSON仕様との不整合を排除し, 相互運用性の問題につながる可能性のある実践を強調することです。
2. JSON Grammar (JSON文法)
JSONテキストはトークンのシーケンスです。トークンセットには, 6つの構造文字, 文字列, 数値, および3つのリテラル名が含まれます。
JSONテキストはシリアル化された値です。一部の以前のJSON仕様では, JSONテキストをオブジェクトまたは配列に制限していたことに注意してください。JSONテキストが必要な場所でオブジェクトまたは配列のみを生成する実装は相互運用可能です。すべての実装がこれらを準拠したJSONテキストとして受け入れるためです。
JSON-text = ws value ws
以下は6つの構造文字です:
begin-array = ws %x5B ws ; [ 左角括弧
begin-object = ws %x7B ws ; { 左中括弧
end-array = ws %x5D ws ; ] 右角括弧
end-object = ws %x7D ws ; } 右中括弧
name-separator = ws %x3A ws ; : コロン
value-separator = ws %x2C ws ; , カンマ
6つの構造文字のいずれかの前後に無意味な空白が許可されます。
ws = *(
%x20 / ; スペース (Space)
%x09 / ; 水平タブ (Horizontal tab)
%x0A / ; 改行 (Line feed or New line)
%x0D ) ; 復帰 (Carriage return)
7. Strings (文字列)
文字列の表現は, C言語ファミリーのプログラミング言語で使用される規約に似ています。文字列は引用符で始まり終わります。すべてのUnicode文字は引用符内に配置できますが, エスケープする必要がある文字は除外されます: 引用符, バックスラッシュ, および制御文字 (U+0000からU+001F)。
任意の文字をエスケープできます。文字が基本多言語面 (BMP) (U+0000からU+FFFF) にある場合, 6文字のシーケンスとして表現できます: バックスラッシュ, 続いて小文字のu, 続いて文字のコードポイントをエンコードする4つの16進数字。16進文字AからFは大文字または小文字にできます。したがって, たとえば, 単一のバックスラッシュ文字のみを含む文字列は "\u005C" として表現できます。
あるいは, 一般的に使用される一部の文字には2文字シーケンスのエスケープ表現があります。したがって, たとえば, 単一のバックスラッシュ文字のみを含む文字列は, よりコンパクトに "\\" として表現できます。
基本多言語面にない拡張文字をエスケープするには, その文字は12文字のシーケンスとして表現され, UTF-16サロゲートペアをエンコードします。したがって, たとえば, ト音記号文字 (U+1D11E) のみを含む文字列は "\uD834\uDD1E" として表現できます。
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; " 引用符 U+0022
%x5C / ; \ バックスラッシュ U+005C
%x2F / ; / スラッシュ U+002F
%x62 / ; b バックスペース U+0008
%x66 / ; f 改ページ U+000C
%x6E / ; n 改行 U+000A
%x72 / ; r 復帰 U+000D
%x74 / ; t タブ U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
8. String and Character Issues (文字列と文字の問題)
8.1. Character Encoding (文字エンコーディング)
JSONテキストは, UTF-8, UTF-16, またはUTF-32でエンコードされなければなりません (SHALL)。デフォルトのエンコーディングはUTF-8であり, UTF-8でエンコードされたJSONテキストは相互運用可能です。最も多くの実装によって正常に読み取られるためです。他のエンコーディング (UTF-16やUTF-32など) のテキストを正常に読み取れない実装が多数あります。
実装は, JSONテキストの先頭にバイトオーダーマーク (BOM) を追加してはなりません (MUST NOT)。相互運用性のため, JSONテキストを解析する実装は, バイトオーダーマークの存在をエラーとして扱うのではなく無視してもかまいません (MAY)。
8.2. Unicode Characters (Unicode文字)
JSONテキストで表現されるすべての文字列が完全にUnicode文字 [UNICODE] で構成されている場合 (どのようにエスケープされているかに関係なく), そのJSONテキストは相互運用可能です。それを解析するすべてのソフトウェア実装が, オブジェクトと配列内の名前と文字列値の内容について一致するためです。
ただし, この仕様のABNFでは, メンバー名と文字列値にUnicode文字をエンコードできないビットシーケンスを含めることができます。たとえば, "\uDEAD" (単一の対になっていないUTF-16サロゲート)。この状況のインスタンスが観察されています。たとえば, ライブラリがUTF-16文字列を切り捨てるときに, 切り捨てがサロゲートペアを分割するかどうかをチェックしない場合などです。このような値を含むJSONテキストを受信するソフトウェアの動作は予測不可能です。たとえば, 実装は文字列値の長さに対して異なる値を返したり, 致命的なランタイム例外を起こしたりする可能性があります。
8.3. String Comparison (文字列比較)
ソフトウェア実装は, オブジェクトメンバー名の等価性をテストする必要があることがよくあります。テキスト表現をUnicodeコードユニットのシーケンスに変換し, コードユニットごとに数値比較を実行する実装は相互運用可能です。すべてのケースで2つの文字列の等価または非等価について実装が一致するためです。たとえば, エスケープされた文字列を無条件に比較する実装は, "a\\b" と "a\u005Cb" が等しくないと誤って発見する可能性があります。
9. Parsers (パーサー)
JSONパーサーは, JSONテキストを別の表現に変換します。JSONパーサーは, JSON文法に準拠するすべてのテキストを受け入れなければなりません (MUST)。JSONパーサーは, 非JSON形式または拡張を受け入れてもかまいません (MAY)。
実装は, 受け入れるテキストのサイズに制限を設定することができます。実装は, ネストの最大深度に制限を設定することができます。実装は, 数値の範囲と精度に制限を設定することができます。実装は, 文字列の長さと文字の内容に制限を設定することができます。
10. Generators (ジェネレーター)
JSONジェネレーターは, JSONテキストを生成します。生成されたテキストは, JSON文法に厳密に準拠しなければなりません (MUST)。
12. Security Considerations (セキュリティに関する考慮事項)
一般的に, スクリプト言語にはセキュリティ上の問題があります。JSONはJavaScriptのサブセットですが, 代入と呼び出しを除外しています。
JSONの構文はJavaScriptから借用されているため, その言語の "eval()" 関数を使用してJSONテキストを解析することが可能です。これは通常, 許容できないセキュリティリスクを構成します。テキストにデータ宣言だけでなく実行可能コードが含まれる可能性があるためです。JSONテキストがその言語の構文に準拠している他のプログラミング言語でeval()のような関数を使用する場合にも, 同じ考慮事項が適用されます。
14. Contributors (貢献者)
RFC 4627はDouglas Crockfordによって書かれました。この文書は, その文書に比較的少ない変更を加えることによって構築されました。したがって, ここに含まれるテキストの大部分は彼のものです。
Appendix A. Changes from RFC 4627 (RFC 4627からの変更)
このセクションでは, この文書とRFC 4627のテキストとの間の変更をリストします。
-
文書のタイトルと要約を変更
-
[UNICODE] への参照をバージョン非特定に変更
-
"JSON仕様" セクションを追加
-
"この改訂版への序論" セクションを追加
-
"JSONテキスト" の定義を変更して任意のJSON値にすることができるようにし, オブジェクトまたは配列でなければならないという制約を削除
-
重複したオブジェクトメンバー名, メンバーの順序, および相互運用性に関する言語を追加
-
配列内の値が同じJSON型である必要がないことを明確化
-
RFC 4627の正誤表#607を適用して "object" 定義のダイアグラムの配置を修正
-
"数値" セクションで "as sequences of digits" を "in the grammar below" に変更し, 10進数の基数を明確化
-
数値の相互運用性をIEEE754関数として言語を追加し, IEEE754参照を追加
-
相互運用性とUnicode文字, および文字列比較に関する言語を追加。このため, 古い "エンコーディング" セクションを "文字列と文字の問題" セクションに変換し, 3つのサブセクション: "文字エンコーディング", "Unicode文字", "文字列比較" を含める
-
"パーサー" セクションのガイダンスを変更して, 実装が数値の範囲 "と精度" に制限を設定できることを示す
-
"IANAへの考慮事項" セクションを更新および整理
-
真の "セキュリティに関する考慮事項" セクションを作成し, 前の "IANAへの考慮事項" セクションからテキストを抽出
-
RFC 4627の正誤表#3607を適用して, "A JSON text can be safely passed" で始まるセキュリティ考慮事項とその考慮事項に関連するJavaScriptコードを削除
-
"セキュリティに関する考慮事項" セクションに, JavaScriptまたはJSONテキストがその言語の構文に準拠している他の言語で "eval()" 関数を使用するリスクを強調するメモを追加
-
"IANAへの考慮事項" に, application/jsonメディアタイプに "charset" パラメータがないことを明確化するメモを追加
-
最初の例で "100" を100に変更し, ブールフィールドを追加
-
単純な値 (オブジェクトでも配列でもない) を持つJSONテキストの例を追加
-
Douglas Crockfordに感謝するための "貢献者" セクションを追加
-
RFC 4627への参照を追加
-
ECMAScript参照を規範的から参考情報に移動し, ECMAScript 5.1を参照するように更新し, ECMA 404への参照を追加