[RFC ホーム] [TEXT|PDF|HTML] [トラッカー] [IPR] [正誤表] [情報ページ]
インターネット
標準
正誤表あり
インターネット技術タスクフォース (IETF) T. Bray, Ed.
Request for Comments: 8259 Textuality
廃止対象: 7159 2017年12月
カテゴリ: 標準化過程
ISSN: 2070-1721
JavaScript Object Notation (JSON) データ交換形式
概要
JavaScript Object Notation (JSON) は、軽量でテキストベースの、
言語に依存しないデータ交換形式である。これは
ECMAScript プログラミング言語標準から派生したものである。JSON は、構造化
データを可搬的に表現するための少数の書式規則を定義する。
この文書は、他の JSON 仕様との不整合を解消し、
仕様上の誤りを修正し、経験に基づく
相互運用性の指針を提供する。
このメモの位置付け
これはインターネット標準化過程の文書である。
この文書は、インターネット技術タスクフォース
(IETF) の成果物である。これは IETF コミュニティの合意を表している。公開
レビューを受け、インターネット技術運営グループ (IESG) によって
公開が承認されている。インターネット標準に関する詳細情報は
RFC 7841 の第 2節に記載されている。
この文書の現在の状態、正誤表、および
フィードバックの提供方法に関する情報は、
https://www.rfc-editor.org/info/rfc8259 で入手できる。
Bray 標準化過程 [1 ページ]
RFC 8259 JSON 2017年12月
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Bray 標準化過程 [2 ページ]
RFC 8259 JSON 2017年12月
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. この文書で使用する規約 . . . . . . . . . . . . . . . . 4
1.2. JSON の仕様 . . . . . . . . . . . . . . . . . . . . . 4
1.3. この改訂について . . . . . . . . . . . . . . . . . . . 5
2. JSON 文法 . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. オブジェクト . . . . . . . . . . . . . . . . . . . . . . . . 6
5. 配列 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. 数値 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. 文字列 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. 文字列と文字に関する問題 . . . . . . . . . . . . . . . . . 9
8.1. 文字エンコーディング . . . . . . . . . . . . . . . . 9
8.2. Unicode 文字 . . . . . . . . . . . . . . . . . . . . 10
8.3. 文字列の比較 . . . . . . . . . . . . . . . . . . . . . 10
9. パーサー . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. ジェネレーター . . . . . . . . . . . . . . . . . . . . . 10
11. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . . 11
12. セキュリティに関する考慮事項 . . . . . . . . . . . . . . . 12
13. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. 規範的参考文献 . . . . . . . . . . . . . . . . . . . 14
14.2. 参考情報 . . . . . . . . . . . . . . . . . . . . . . 14
付録 A. RFC 7159 からの変更点 . . . . . . . . . . . . . . . 16
貢献者 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . 16
1. はじめに
JavaScript Object Notation (JSON) は、構造化データを
シリアライズするためのテキスト形式である。これは、ECMAScript プログラミング
言語標準 第3版 [ECMA-262] で定義されている JavaScript のオブジェクト
リテラルから派生したものである。
JSON は、4つのプリミティブ型（文字列、数値、ブール値、
null）と2つの構造化型（オブジェクトと配列）を表現できる。
文字列は、0個以上の Unicode 文字 [UNICODE] の並びである。
この引用は特定のリリースではなく、Unicode の最新バージョンを
参照していることに注意されたい。Unicode 仕様の将来の
変更が JSON の構文に影響することは想定されていない。
オブジェクトは、0個以上の名前と値の
ペアからなる順序のないコレクションであり、名前は文字列、値は文字列、数値、
ブール値、null、オブジェクト、または配列である。
配列は、0個以上の値からなる順序付きの並びである。
Bray 標準化過程 [3 ページ]
RFC 8259 JSON 2017年12月
「object」および「array」という用語は、
JavaScript の慣例に由来する。
JSON の設計目標は、最小限で、可搬性があり、テキスト形式であり、
JavaScript のサブセットであることだった。
1.1. この文書で使用する規約
この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、
"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、および
"OPTIONAL" は、ここに示すようにすべて
大文字で記述されている場合に限り、BCP
14 [RFC2119] [RFC8174] に記述されているとおりに解釈される。
この文書の文法規則は、
[RFC5234] に記述されているとおりに解釈される。
1.2. JSON の仕様
この文書は [RFC7159] を置き換える。[RFC7159] は [RFC4627] を
廃止した。RFC4627 は当初 JSON を記述し、メディアタイプ
"application/json" を登録したものである。
JSON は [ECMA-404] にも記述されている。
前文の ECMA-404 への参照は規範的なものであるが、
実装者がこの文書を理解するために参照する必要があるという
通常の意味ではなく、すべての
仕様における「JSON text」という用語の定義に
不整合がないことを強調するためである。ただし、ECMA-404 では、
相互運用性を最大限に高めるために本仕様が避けることを推奨する
いくつかの慣行が許可されていることに注意されたい。
異なる記述方法が用いられているものの、2つの文書間で文法を
同一にすることを意図している。両者の間に相違が
見つかった場合、ECMA と IETF は協力して
両方の文書を更新する。
いずれかの文書に誤りが見つかった場合、もう一方にも
同様の誤りがないか調査し、存在する場合には、
可能であれば修正するべきである。
将来いずれかの文書が変更された場合、ECMA と IETF は
その変更を通じて2つの文書の整合性が保たれるよう
協力する。
Bray 標準化過程 [4 ページ]
RFC 8259 JSON 2017年12月
1.3. この改訂について
RFC 4627 の公開以降の年月で、JSON は非常に
広く使用されるようになった。この経験により、仕様では
許可されているものの、相互運用性の問題を引き起こす特定のパターンが明らかになった。
また、RFC 4627 に関して少数の正誤情報が報告されている
（RFC Errata ID 607 [Err607] および 3607 [Err3607] を参照）。また、
RFC 7159 に関しても（RFC Errata ID 3915 [Err3915]、4264 [Err4264]、4336
[Err4336]、および 4388 [Err4388] を参照）報告されている。
この文書の目的は、正誤情報を反映し、他の JSON 仕様との
不整合を解消し、相互運用性の問題につながる可能性のある
慣行を強調することである。
2. 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 ; , コンマ
Bray 標準化過程 [5 ページ]
RFC 8259 JSON 2017年12月
重要でない空白は、6つの構造文字のいずれの前後にも
許可される。
ws = *(
%x20 / ; スペース
%x09 / ; 水平タブ
%x0A / ; ラインフィードまたは改行
%x0D ) ; キャリッジリターン
3. 値
JSON 値は、オブジェクト、配列、数値、文字列、または
次の3つのリテラル名のいずれかでなければならない。
false
null
true
リテラル名は小文字でなければならない。他のリテラル名は
許可されない。
value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
true = %x74.72.75.65 ; true
4. オブジェクト
オブジェクト構造は、0個以上の名前と値のペア
（またはメンバー）を囲む一対の波括弧で表される。名前は
文字列である。各名前の後には1つのコロンが置かれ、名前と
値を分離する。1つのコンマが値とそれに続く
名前を分離する。オブジェクト内の名前は一意であるべきである。
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
すべての名前が一意であるオブジェクトは、そのオブジェクトを受け取る
すべてのソフトウェア実装が名前と値の対応について一致するという意味で
相互運用可能である。オブジェクト内の名前が
一意でない場合、そのようなオブジェクトを受け取るソフトウェアの動作は
予測できない。多くの実装は最後の名前と値のペアのみを
報告する。他の実装はエラーを報告するか、オブジェクトの解析に失敗する。
Bray 標準化過程 [6 ページ]
RFC 8259 JSON 2017年12月
また、一部の実装は重複を含むすべての名前と値のペアを
報告する。
JSON 解析ライブラリは、オブジェクトメンバーの順序を
呼び出し元ソフトウェアから参照可能にするかどうかについて異なることが確認されている。
メンバーの順序に依存しない動作をする実装は、
これらの相違の影響を受けないという意味で
相互運用可能である。
5. 配列
配列構造は、0個以上の値
（または要素）を囲む角括弧で表される。要素はコンマで区切られる。
array = begin-array [ value *( value-separator value ) ] end-array
配列内の値が同じ
型である必要はない。
6. 数値
数値の表現は、多くの
プログラミング言語で使用されているものと似ている。数値は
10進数字を用いた基数10で表される。整数部分を含み、
任意のマイナス記号を前置でき、その後に
小数部および／または指数部を続けることができる。先頭のゼロは
許可されない。
小数部は、小数点の後に1個以上の数字が続く。
指数部は大文字または小文字の E で始まり、
その後にプラスまたはマイナス記号を続けることができる。E と任意の
符号の後には1個以上の数字が続く。
以下の文法で表現できない数値
（Infinity や NaN など）は許可されない。
number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E ; .
digit1-9 = %x31-39 ; 1-9
e = %x65 / %x45 ; e E
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
Bray 標準化過程 [7 ページ]
RFC 8259 JSON 2017年12月
int = zero / ( digit1-9 *DIGIT )
minus = %x2D ; -
plus = %x2B ; +
zero = %x30 ; 0
本仕様は、実装が受け入れる数値の範囲
および精度に制限を設けることを許可する。IEEE 754 binary64
（倍精度）数値 [IEEE754] を実装するソフトウェアは一般に
利用可能で広く使用されているため、これが提供する以上の
精度または範囲を期待しない実装は、実装が期待される精度内で
JSON 数値を近似するという意味で、良好な相互運用性を
実現できる。1E400
や 3.141592653589793238462643383279 のような JSON 数値は、
それを生成したソフトウェアが、受信側ソフトウェアに対して
一般に利用可能なものより大きな数値の規模および精度を
扱う能力を期待していることを示唆するため、潜在的な相互運用性の問題を示す可能性がある。
このようなソフトウェアが使用される場合、整数であり、
[-(2**53)+1, (2**53)-1] の範囲にある数値は、実装間で
その数値が完全に一致するという意味で
相互運用可能であることに注意されたい。
7. 文字列
文字列の表現は、C 系
プログラミング言語で使用される慣例と似ている。文字列は
引用符で始まり、引用符で終わる。エスケープしなければならない
文字、すなわち引用符、逆斜線、および制御文字（U+0000
から U+001F）を除き、すべての Unicode 文字を
引用符の内側に配置できる。
任意の文字をエスケープできる。文字が基本
多言語面（U+0000 から U+FFFF）にある場合、その文字は
6文字の並びとして表現できる。すなわち、逆斜線、その後に
小文字の u、その後にその文字のコードポイントを
符号化する4桁の16進数字が続く。16進数字の A から
F は大文字でも小文字でもよい。したがって、たとえば、
逆斜線1文字だけを含む文字列は
"\u005C" と表現できる。
あるいは、よく使われる一部の文字には2文字の
エスケープ表現がある。したがって、たとえば、
逆斜線1文字だけを含む文字列は、
より簡潔に "\\" と表現できる。
Bray 標準化過程 [8 ページ]
RFC 8259 JSON 2017年12月
基本多言語面にない拡張文字を
エスケープするには、その文字を12文字の並びとして表現し、
UTF-16 サロゲートペアを符号化する。したがって、たとえば、
G 音部記号（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. 文字列と文字に関する問題
8.1. 文字エンコーディング
閉じたエコシステムの一部ではないシステム間で交換される
JSON テキストは、UTF-8 [RFC3629] を使用して符号化されなければならない。
以前の JSON 仕様では、JSON テキストを送信する際に
UTF-8 の使用を要求していなかった。しかし、JSON
ベースのソフトウェア実装の圧倒的大多数は UTF-8 エンコーディングを
使用することを選択しており、それが相互運用性を実現する
唯一のエンコーディングとなっている。
実装は、ネットワーク経由で送信される JSON テキストの
先頭にバイトオーダーマーク（U+FEFF）を追加してはならない。相互運用性のため、
JSON テキストを解析する実装は、バイトオーダーマークの存在を
エラーとして扱う代わりに無視してもよい。
Bray 標準化過程 [9 ページ]
RFC 8259 JSON 2017年12月
8.2. Unicode 文字
JSON テキストで表現されるすべての文字列が、完全に
Unicode 文字 [UNICODE] から構成されている場合（どのようにエスケープされていても）、その JSON
テキストは、それを解析するすべてのソフトウェア実装が
オブジェクトおよび配列内の名前と文字列値の内容について
一致するという意味で相互運用可能である。
しかし、本仕様の ABNF は、メンバー名および
文字列値に Unicode 文字を符号化できないビット列を含むことを
許可している。たとえば、"\uDEAD"（単独で対応する相手のない UTF-16
サロゲート）である。このような事例は、たとえばライブラリが
UTF-16 文字列を切り詰める際に、その切り詰めが
サロゲートペアを分割していないか確認しなかった場合に確認されている。そのような値を含む
JSON テキストを受け取るソフトウェアの動作は予測できない。たとえば、
実装によって文字列値の長さに異なる値を返したり、
致命的な実行時例外が発生したりする可能性がある。
8.3. 文字列の比較
ソフトウェア実装は通常、オブジェクトメンバーの名前が
等しいかどうかを検査する必要がある。テキスト表現を
Unicode コード単位の並びに変換し、その後、
コード単位ごとに数値的に比較する実装は、
2つの文字列が等しいか等しくないかについてすべての場合に
実装間で一致するという意味で相互運用可能である。たとえば、
エスケープされた文字を変換せずに文字列を比較する
実装は、"a\\b" と "a\u005Cb" が等しくないと
誤って判断する可能性がある。
9. パーサー
JSON パーサーは JSON テキストを別の表現に変換する。
JSON パーサーは JSON 文法に適合するすべてのテキストを受け入れなければならない。
JSON パーサーは、JSON ではない形式や拡張を受け入れてもよい。
実装は、受け入れるテキストのサイズに制限を
設けてもよい。実装は、ネストの最大深度に
制限を設けてもよい。実装は、数値の範囲および精度に
制限を設けてもよい。実装は、文字列の長さおよび
文字内容に制限を設けてもよい。
10. ジェネレーター
JSON ジェネレーターは JSON テキストを生成する。生成されたテキストは
JSON 文法に厳密に適合しなければならない。
Bray 標準化過程 [10 ページ]
RFC 8259 JSON 2017年12月
11. IANA に関する考慮事項
JSON テキストのメディアタイプは application/json である。
タイプ名: application
サブタイプ名: json
必須パラメーター: なし
任意パラメーター: なし
エンコーディングに関する考慮事項: binary
セキュリティに関する考慮事項: RFC 8259 第 12節を参照
相互運用性に関する考慮事項: RFC 8259 に記述されている
公開仕様: RFC 8259
このメディアタイプを使用するアプリケーション:
JSON は、次のすべてのプログラミング言語で記述されたアプリケーション間の
データ交換に使用されている: ActionScript、C、C#、
Clojure、ColdFusion、Common Lisp、E、Erlang、Go、Java、JavaScript、
Lua、Objective CAML、Perl、PHP、Python、Rebol、Ruby、Scala、および
Scheme。
追加情報:
マジックナンバー: なし
ファイル拡張子: .json
Macintosh ファイルタイプコード: TEXT
詳細情報の問い合わせ先となる担当者およびメールアドレス:
IESG
<iesg@ietf.org>
想定される用途: COMMON
使用上の制限: なし
著者:
Douglas Crockford
<douglas@crockford.com>
変更管理者:
IESG
<iesg@ietf.org>
Bray 標準化過程 [11 ページ]
RFC 8259 JSON 2017年12月
注: この登録では "charset" パラメーターは定義されていない。
これを追加しても、適合する受信者には実質的な影響はない。
12. セキュリティに関する考慮事項
一般に、スクリプト言語にはセキュリティ上の問題がある。JSON は
JavaScript のサブセットだが、代入と呼び出しは除外している。
JSON の構文は JavaScript から借用されているため、
その言語の "eval()" 関数を使用して大部分の JSON テキストを解析することができる
（ただしすべてではない。U+2028 LINE SEPARATOR や U+2029
PARAGRAPH SEPARATOR などの特定の文字は JSON では正当だが
JavaScript では正当ではない）。テキストにはデータ宣言とともに
実行可能コードが含まれる可能性があるため、これは一般に
許容できないセキュリティリスクとなる。同じ
考慮事項は、JSON テキストがその言語の構文に適合する
他のプログラミング言語で eval() に類似した関数を使用する場合にも
当てはまる。
13. 例
これは JSON オブジェクトである:
{
"Image": {
"Width": 800,
"Height": 600,
"Title": "View from 15th Floor",
"Thumbnail": {
"Url": "http://www.example.com/image/481989943",
"Height": 125,
"Width": 100
},
"Animated" : false,
"IDs": [116, 943, 234, 38793]
}
}
その Image メンバーはオブジェクトであり、その Thumbnail メンバーもオブジェクト、
IDs メンバーは数値の配列である。
Bray 標準化過程 [12 ページ]
RFC 8259 JSON 2017年12月
これは2つのオブジェクトを含む JSON 配列である:
[
{
"precision": "zip",
"Latitude": 37.7668,
"Longitude": -122.3959,
"Address": "",
"City": "SAN FRANCISCO",
"State": "CA",
"Zip": "94107",
"Country": "US"
},
{
"precision": "zip",
"Latitude": 37.371991,
"Longitude": -122.026020,
"Address": "",
"City": "SUNNYVALE",
"State": "CA",
"Zip": "94085",
"Country": "US"
}
]
次に、値だけを含む3つの小さな JSON テキストを示す:
"Hello world!"
42
true
Bray 標準化過程 [13 ページ]
RFC 8259 JSON 2017年12月
14. 参考文献
14.1. 規範的参考文献
[ECMA-404] Ecma International, "JSON データ交換形式",
Standard ECMA-404,
<http://www.ecma-international.org/publications/
standards/Ecma-404.htm>.
[IEEE754] IEEE, "浮動小数点演算の IEEE 標準",
IEEE 754.
[RFC2119] Bradner, S., "要件レベルを示すために RFC で使用する
キーワード", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997年3月,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "ISO
10646 の変換形式 UTF-8", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003年11月,
<https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "構文
仕様のための拡張 BNF: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, 2008年1月,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "RFC
2119 キーワードにおける大文字と小文字の曖昧さ", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2017年5月, <https://www.rfc-editor.org/info/rfc8174>.
[UNICODE] The Unicode Consortium, "Unicode 標準",
<http://www.unicode.org/versions/latest/>.
14.2. 参考情報
[ECMA-262] Ecma International, "ECMAScript 言語仕様",
Standard ECMA-262, 第3版, 1999年12月,
<http://www.ecma-international.org/publications/files/
ECMA-ST-ARCH/
ECMA-262,%203rd%20edition,%20December%201999.pdf>.
[Err3607] RFC 正誤情報, 正誤情報 ID 3607, RFC 4627,
<https://www.rfc-editor.org/errata/eid3607>.
[Err3915] RFC 正誤情報, 正誤情報 ID 3915, RFC 7159,
<https://www.rfc-editor.org/errata/eid3915>.
Bray 標準化過程 [14 ページ]
RFC 8259 JSON 2017年12月
[Err4264] RFC 正誤情報, 正誤情報 ID 4264, RFC 7159,
<https://www.rfc-editor.org/errata/eid4264>.
[Err4336] RFC 正誤情報, 正誤情報 ID 4336, RFC 7159,
<https://www.rfc-editor.org/errata/eid4336>.
[Err4388] RFC 正誤情報, 正誤情報 ID 4388, RFC 7159,
<https://www.rfc-editor.org/errata/eid4388>.
[Err607] RFC 正誤情報, 正誤情報 ID 607, RFC 4627,
<https://www.rfc-editor.org/errata/eid607>.
[RFC4627] Crockford, D., "JavaScript Object Notation (JSON) の
application/json メディアタイプ", RFC 4627,
DOI 10.17487/RFC4627, 2006年7月,
<https://www.rfc-editor.org/info/rfc4627>.
[RFC7159] Bray, T., Ed., "JavaScript Object Notation (JSON) データ
交換形式", RFC 7159, DOI 10.17487/RFC7159, 2014年3月,
<https://www.rfc-editor.org/info/rfc7159>.
Bray 標準化過程 [15 ページ]
RFC 8259 JSON 2017年12月
付録 A. RFC 7159 からの変更点
この節では、この文書と
RFC 7159 の本文との変更点を一覧にする。
o 第1.2節は、ECMA-262 から JSON
仕様が削除されたことを反映し、ECMA-404 を規範的
参考文献とし、「規範的」の特定の意味を説明するために更新された。
o 第1.3節は、RFC 4627 ではなく
RFC 7159 に対して提出された正誤情報を反映するために更新された。
o 第8.1節は、ネットワーク経由で
送信する際に UTF-8 の使用を要求するよう変更された。
o 第12節は、ECMAScript の "eval()" 関数を使用することから
生じるセキュリティリスクの記述をより正確にするために
更新された。
o 第14.1節は、ECMA-404 を規範的
参考文献として含めるよう更新された。
o 第14.2節は、ECMA-404 を削除し、ECMA-262 の
バージョンを更新し、正誤情報の一覧を更新するために変更された。
貢献者
RFC 4627 は Douglas Crockford によって執筆された。この文書は、
その文書に比較的少数の変更を加えることで
作成された。したがって、ここにある本文の大部分は彼によるものである。
著者の連絡先
Tim Bray（編集者）
Textuality
メール: tbray@textuality.com
Bray 標準化過程 [16 ページ]