[31] [DFN[[RUBY[[[JSON]]][ジェイソン]]]] ([DFN[JavaScript Object Notation]] / [DFN[JavaScript オブジェクト記法]])
は、 [[JavaScript]] における[[オブジェクト・リテラル]]の[[部分集合]]によって[[オブジェクト]]や[[配列]]を表記するデータ交換書式です。
[[JavaScript]] を始め数多くの[[言語]]で[[ライブラリー]]が整備されており、
汎用的な[[データ構造]]の交換形式として広く用いられています。
[FIG[
[FIGCAPTION[
[30] [CITE@en[JSON]] ([TIME[2011-07-09 12:55:13 +09:00]] 版)
]FIGCAPTION]
>JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
]FIG]
* 仕様書
[REFS[
- [132] [CITE[Standard ECMA-404]]
( ([TIME[2013-10-09 12:19:30 +09:00]] 版))
]REFS]
* データ型
[37] [[JSON]] では以下の[[データ型]]を表現できます [SRC[>>3 1.]]。
- [38] [RUBYB[[[プリミティブ型]]]@en[primitive types]]
-- [39] [RUBYB[[[文字列]]]@en[string]]
-- [40] [RUBYB[[[数値]]]@en[number]]
-- [41] [[boolean]]
-- [42] [[null]]
- [43] [RUBYB[[[構造化型]]]@en[structured types]]
-- [44] [RUBYB[[[オブジェクト]]]@en[object]]
-- [45] [RUBYB[[[配列]]]@en[array]]
* 構文
** 文字符号化
[69] [[JSONテキスト]]は [[Unicode]] で[[符号化]]しなければ[['''なりません''']] [SRC[>>3 3.]]。
[70] [[Unicode]] のどの[[符号化方式]]、というような限定はされていません。
どれを使っても良いということでしょうか。 [[UTF-8]]、[[UTF-16]]、[[UTF-32]]
を使って構わないという記述はありますが [SRC[>>3 6.]]、
それ以外を使ってはいけないとは明確に規定されていません。
[71] [[既定]]の[[符号化]]は [[UTF-8]] です [SRC[>>3 3.]]。しかしこの「既定」
が何を表すのかは明記されていません。特に意図がなければ [[UTF-8]]
を使うべきであるということでしょうか。あるいは[[文字符号化方式]]が特定できないときに
[[UTF-8]] として解釈するべきということでしょうか。
[75] 実装はこれらの[[符号化方式]]のいずれ、あるいはすべてに対応しなければならないのか、
しなくてもよいのか、といったことは規定されていません。
*** Sniffing
[72] [[RFC]] の規定する [[JSONテキスト]]は、最初の2文字が必ず [[ASCII文字]]となります。
そのため、最初の4つの[[オクテット]]のパターンにより、
,[CODE[00 00 00 [VAR[xx]]]],[[UTF-32BE]]
,[CODE[00 [VAR[xx]] 00 [VAR[xx]]]],[[UTF-16BE]]
,[CODE[[VAR[xx]] 00 00 00]],[[UTF-32LE]]
,[CODE[[VAR[xx]] 00 [VAR[xx]] 00]],[[UTF-16LE]]
,[CODE[[VAR[xx]] [VAR[xx]] [VAR[xx]] [VAR[xx]]]],[[UTF-8]]
... と区別できるとされています。 [SRC[>>3 3.]] [VAR[xx]] は [CODE[00]]
以外の[[オクテット]]を表すのでしょう。 [[JSONテキスト]]に直接 [CODE(char)[[[U+0000]]]]
が出現することは無いとされているので、 [CODE[00]] かどうかで確実に判定できます。
[73] [[ES5]] によって拡張された [[JSON]] として解釈される[[文字列]]は、
2文字目が必ずしも [[ASCII文字]]であるとは限りません ([[文字列リテラル]]の場合。) が、
それでもやはり同様にこれら5つの[[文字符号化方式]]を区別できます。
[76] この [[sniffing]] は、実装が必ず使わなければならないなどという規定は特にありません。
しかし [CODE(MIME)@en[[[application/json]]]] には [CODE(MIME)@en[[[charset]]]]
[[引数]]がありませんし、実際にこれらの[[文字符号化]]が使われているのであれば、
これ、あるいはこれに類する [[sniffing]] を実装する以外に選択肢はありません。
*** BOM
[74] [[RFC]] は [[BOM]] について言及していません。 [[BOM]] がある場合は >>72 のパターンに当てはまらず、
[[UTF-16]] や [[UTF-32]] であっても [[UTF-8]] と判定されてしまいます。ただし [[RFC]]
のこの部分は単なる事実の記述であって、そう解釈[[しなければならない]]などと規定されているわけではなく、
また明確に [[BOM]] を使用しては[[ならない]]と規定されているわけでもありませんから、
どう理解するべきか難しいところです。
[159] [[RFC 4627]] の改訂にあたっても [[BOM]] が認められているかどうかは議論になっています。
[160] [[ECMA-404]] も明確に認めてはいませんが、 [[ECMA-404]]
は[[符号化]]については触れずに[[文字]]の列について定義しているに過ぎないので、
どちらともしていないと言えます。
[161] [[XHR]] は [[JSON]] の解釈の際に [[BOM]] があれば無視するよう規定しています。
これを [[XHR]] が [[JSON]] の変種を規定しているとみなす人もいます。
** 字句解析
[46] [[JSONテキスト]]は、次の[[字句]]により構成されます [SRC[>>3 2.]]。
[FIG[
- [RUBYB[構造的文字]@en[structual character]]
-- [CODE(char)[[['''[''']]]], [CODE(char)[[[''']''']]]], [CODE(char)[[[{]]]],
[CODE(char)[[[}]]]], [CODE(char)[[[:]]]], [CODE(char)[[[,]]]]
-- 前後に[[空白]]があっても構いません。
-- [[空白]]は、0[[文字]][[以上]]の [CODE(char)[[[U+0009]]]], [CODE(char)[[[U+000A]]]],
[CODE(char)[[[U+000D]]]], [CODE(char)[[[U+0020]]]] です。
- JSON [RUBYB[値]@en[value]]
-- [[文字列]]
-- [[数値]]
-- [[リテラル名]]
--- [CODE(char)[[[true]]]], [CODE(char)[[[false]]]], [CODE(char)[[[null]]]]
--- [[小文字]]でなければ[['''なりません''']]。
]FIG]
[100] [[RFC]] の [[JSON]] は、 [[ABNF]] により [[Unicode]] [[文字]]について定義されています [SRC[>>3]]。
[[ES5]] の [[JSON]] は、 [[BNF]] により [[SourceCharacter]]、すなわち [[UTF-16]]
の[[16ビット符号単位]]について定義されています [SRC[>>36 15.12]]。実質的には同じです。
** 構文
[47] [[RFC]] により規定される [DFN[JSON [RUBYB[テキスト]@en[text]]]]は、
[[オブジェクト]]または[[配列]]を1つ[[直列化]]したものです
[SRC[>>3 2.]]。
[101] [[ES5]] により規定される [CODE[[[JSONText]]]] は、それに加えて他の[[文字列]]や[[数値]]や
[[true]] や [[false]] や [[null]] のような値も認めています [SRC[>>36 15.12]]。
*** オブジェクト
[48] [[オブジェクト]]は、 [CODE(char)[[['''{''']]]] の後に0個[[以上]]の[RUBYB[[[メンバー]]]@en[member]]を
[CODE(char)[[[,]]]] で区切って並べ、最後に [CODE(char)[[['''}''']]]] が来る文字列として表されます。
メンバーは、名前と値の組であり、[[文字列]]の後に [CODE(char)[[[:]]]] が来て、
その後に値が来ます。 [SRC[>>3 2.2.]]
[49] [[オブジェクト]]内で名前は固有である[['''べきです''']] [SRC[>>3 2.2.]]。
[52] 最後の[[メンバー]]の後に [CODE(char)[[[,]]]] を入れることは認められていません。
*** 配列
[50] [[配列]]は、 [CODE(char)[[['''[''']]]] の後に0個[[以上]]の値を [CODE(char)[[[,]]]]
で区切って並べ、最後に [CODE(char)[[[''']''']]]] が来る文字列として表されます。 [SRC[>>3 2.3.]]
[51] 最後の値の次に [CODE(char)[[[,]]]] を入れることは認められていません。
*** 数値
[53] [[数値]]は、必要なら[[負符号]]の後、[[整数部]]が来て、
必要なら[[小数部]]が来て、最後に必要なら[[指数部]]が来る形を取ります。
[SRC[>>3 2.4.]]
- number = ["-"] int ["." 1*DIGIT] [ exp ]
- int = "0" / ( (DIGIT - "0") *DIGIT )
- exp = "e" ["-" / "+"] 1*DIGIT
[54] 先頭に[[正符号]]を使うことは認められていません。 ([[指数部]]では使えます。)
[55] [[十進数]]により表記します。
[56] [[整数部]]で[[先導0]]は認められていません。
[57] [[無限大]]や[[NaN]]は表現できません。 [SRC[>>3 2.4.]]
*** 文字列
[58] [[文字列]]は、0個以上の[[文字]]を[[引用符]]で括ることによって表されます。
[SRC[>>3 2.5.]]
[59] [[文字]]は [[escape]] により表現することができます。特に[[引用符]]、
[CODE(char)[[[\]]]], [CODE(char)[[[U+0000]]]] - [CODE(char)[[[U+001F]]]]
については必ず [[escape]] しなければなりません。
[SRC[>>3 2.5.]]
[65]
,[CODE(JS)[\"]],[CODE(char)[[["]]]]
,[CODE(JS)[\\]],[CODE(char)[[[\]]]]
,[CODE(JS)[\/]],[CODE(char)[[[/]]]]
,[CODE(JS)[\b]],[CODE(char)[[[U+0008]]]]
,[CODE(JS)[\f]],[CODE(char)[[[U+000C]]]]
,[CODE(JS)[\n]],[CODE(char)[[[U+000A]]]]
,[CODE(JS)[\r]],[CODE(char)[[[U+000D]]]]
,[CODE(JS)[\t]],[CODE(char)[[[U+0009]]]]
,[CODE(JS)[\u[VAR[HHHH]]]],[CODE(char)[U+[VAR[HHHH]]]]
;; [66] [[大文字]]と[[小文字]]は区別されます。しかし[[十六進数]]は[[大文字]]でも[[小文字]]でも構いません。
[SRC[>>3 2.5.]]
[60] [CODE(char)[[[U+10000]]]] [[以上]]の[[文字]]は [[UTF-16]]
[[サロゲート・ペア]]の2つの[[16ビット符号単位]]の列によって [[escape]]
で表せます。 [SRC[>>3 2.5.]]
[64] [[RFC]] の [[ABNF]] 上は [[Unicode]] の[[サロゲート・ペア]]や[[非文字]]の[[符号位置]]を使うことは明確に禁止されていません。
[61] 明記されていませんが、半分は[[サロゲート・ペア]]の[[符号位置]]そのまま、
もう半分は [[escape]] というような列で [CODE(char)[[[U+10000]]]] より大きな[[文字]]を表現することは認められていないとも解釈できます。
;; [115] [[ES5]] の [[JSON]] の構文と構文解析の定義上は、 [[ECMAScript]] の [[UnicodeEscape]]
と同じとなっており、従って[[サロゲート・ペア]]の[[符号位置]]も単なる[[16ビット符号単位]]の文字列表現として普通に解釈されるべきものであるようです。
;; [116] [[Perl]] モジュール [CODE(perl)[[[JSON::XS]]]] はそのような[[サロゲート・ペア]]の[[符号位置]]に遭遇するとエラーを出して構文解析を中止します。
*** boolean
[67] [CODE(JS)[[[true]]]] や [CODE(JS)[[[false]]]] は、それぞれ [[boolean]]
の[[真]]と[[偽]]を表します。これらは[[小文字]]でなければなりません。
*** null
[68] [CODE(JS)[[[null]]]] は、 [[null]] を表します。これは[[小文字]]でなければなりません。
* 構文解析器
[77] [DFN[JSON [RUBYB[構文解析器]@en[parser]]]]は、 [[JSONテキスト]]を他の表現に変形するものです
[SRC[>>3 4.]]。
[78] [[JSON構文解析器]]は、 [[JSON]] の文法に適合するすべての[[テキスト]]を[[受理]]しなければ[['''なりません''']]
[SRC[>>3 4.]]。
[79] [[JSON構文解析器]]は、 [[JSON]] ではない形式や拡張を[[受理]]しても[['''構いません''']]
[SRC[>>3 4.]]。
[80] [[受理]]する[[テキスト]]の[[サイズ]]を制限して構いません [SRC[>>3 4.]]。
[81] [[入れ子]]の深さを制限して構いません [SRC[>>3 4.]]。
[82] [[数値]]の範囲を制限して構いません [SRC[>>3 4.]]。
[83] [[文字列]]の[[長さ]]や[[文字]]の[[内容]]を制限して構いません [SRC[>>3 4.]]。
;; [84] これらの制限に抵触する場合にどのように処理しなければならないかは規定されていません。
また、 >>83 の文字の内容の制限というのが具体的に何を指しているかは不明確です。
特定の種類の文字から構成される文字列以外を処理できなくても構わないといったことでしょうか。
[102] [[ES5]] の [CODE(JS)[[[JSON.parse]]]] は、 >>79 の拡張は認めておらず、
[[ES5]] の規定に厳密に従って構文解析しなければなりません [SRC[>>36 15.12]]。
なお、 [[ES5]] の規定は [[RFC]] の規定より若干拡張されています (>>101)。
* 生成器
[85] [DFN[JSON [RUBYB[生成器]@en[generator]]]]は、 [[JSONテキスト]]を生産するものです
[SRC[>>3 5.]]。
[86] [[JSON生成器]]が生産する[[テキスト]]は、[[JSON]] の[[文法]]に厳密に[[適合]]しなければ[['''なりません''']]
[SRC[>>3 5.]]。
[103] [[ES5]] の [CODE(JS)@[[[JSON.stringify]]]] は、 [[RFC]] ではなく [[ES5]]
の規定に従って [[JSON]] を生成しなければなりません [SRC[>>36 15.12]]。これは [[RFC]]
の規定より拡張された [[ES5]] の [[JSON]] を生成するので、 [[RFC]] の規定に基づく
[[JSON生成器]] (>>85) には適合しません。
* 不正な JSON
- [22] [[JSONP]] が [[JSON]] として扱われることがあります。
- [23] [[オブジェクト]]の[[特性名]]を表す[[文字列リテラル]]が [CODE(char)[[["]]]] で括られないことがあります。
- [24] [[JSON]] の前に「[CODE(JS)[[[var]] name = ]]」のような[[文字列]]がつくことがあります。
- [25] [[YAML]] の [[serializer]] によって実際には [[JSON]] ではない [[YAML]] が [[JSON]] であるとして出力されることがあります (>>176)。
- [87] [[JavaScript]] の[[注釈]]が含まれることがあります。
-- /* ... */
-- // ...
- [88] [[配列]]や[[オブジェクト]]の最後の[[メンバー]]の後に [CODE(char)[[[,]]]] が余分に挿入されることがあります。
- [110] 果ては[[関数リテラル]]が含まれることすらあります。
- [112] # ... のような注釈が使われることがあります。
- [117] 0x0000 のような数値の16進数表記が用いられることがあります。
- [158] [[XSSI]] 防止のために本来の [[JSON]] データの前に「[CODE[)]}]]」のようなごみを挿入することがあります。
[[Source Map]] はこれを明示的に認めています。
- [165] [[Perl]] モジュールである [CODE(perl)@en[[[JSON::XS]]]] は、[[符号化]]時に数値としての [[inf]] や [[nan]] が与えられると[[引用符]]のない
[CODE[inf]] や [CODE[nan]] を出力します。 ([[復号]]はできず構文エラーになります。) [TIME[2014-01-09T11:35:59.600Z]]
* JavaScript との互換性
[105] [[JavaScript]] の[[文字列リテラル]]では [CODE(char)[[[U+2028]]]] や [CODE(char)[[[U+2029]]]]
を直接記述することは認められていませんが、 [[JSON]] では認められています
[SRC[>>36 15.12.2]]。
[REFS[
- [28] [CITE[JSON: The JavaScript subset that isn't — Timeless]]
([TIME[2011-05-16 04:05:34 +09:00]] 版)
- [27] [CITE[JSON::XS - search.cpan.org]] ([TIME[2011-04-15 12:50:01 +09:00]] 版)
]REFS]
[FIG[
[FIGCAPTION[
[119] >>27 より
]FIGCAPTION]
>One of the problems is that U+2028 and U+2029 are valid characters inside JSON strings, but are not allowed in ECMAscript string literals
>Another problem is that some javascript implementations reserve some property names for their own purposes (which probably makes them non-ECMAscript-compliant). For example, Iceweasel reserves the __proto__ property name for it's own purposes.
]FIG]
[118] また、 [CODE(JS)@en[[[__proto__]]]] のように [[JavaScript]] 自体の持つ機能の名前と衝突した場合に、
[[JSON]] を直接 [[JavaScript]] と解釈すると問題が起こり得ることも指摘されています (>>119)。
[120] このような [[JavaScript]] との非互換性は、 [CODE(JS)@en[[[JSON]]]] [[オブジェクト]]のような正規の実装に依らず、
[CODE(JS)@en[[[eval]]]] などで [[JavaScript]] 文字列として解釈する際に発症します。しかも通常は
[CODE(char)@en[[[U+2028]]]] などは使わない[[文字]]なので気づきにくく、時にサービス拒否攻撃のように悪用されることもあります。
[121] また、 [[JSON]] を[[関数]]で括った“だけ”であるはずの [[JSONP]] も、
[WEAK[([[JavaScript]] と解釈されるのが目的のものですから、 [[JavaScript]] コードであることになり、)]]
実は [[JSON]] とは非互換であることになります。
* YAML との互換性
[176] [[Perl]] コミュニティーの一部など、 [[JSON]] 以前に [[YAML]] が広く用いられていた人達の中には、
[[JSON]] は [[YAML]] の[[部分集合]]であるとして、 [[YAML]] の実装を元にした [[JSON]]
の実装が行われていました。
[26] しかし [[JSON]] は [[YAML]] の[[部分集合]]であるとの主張は'''嘘'''とされています。
[REFS[
- [177] [CITE[JSON::XS - search.cpan.org]] ([TIME[2011-04-15 12:50:01 +09:00]] 版)
]REFS]
[178] このため [[JSON]] であると称しながら実際には [[JSON]] ではない [[YAML]]
のデータが存在しています。
* MIME 型
[89] [[JSON]] の [[MIME型]]は [DFN[[CODE(MIME)@en[[[application/json]]]]]] です [SRC[>>3 6.]]。
[90] この他 [DFN[[CODE(MIME)@en[[[*/*+json]]]]]] により [[JSON]] を使った特定の[[応用]]を表すことがあります。
;;
[124] [CODE(MIME)@en[[[text/json]]]] が使われることもあります。
** CTE
[91] [[CTE]] としては、 [[UTF-8]] を使う時は [CODE(MIME)@en[[[8bit]]]]、
[[UTF-16]] や [[UTF-32]] を使う時は [CODE(MIME)@en[[[binary]]]] が適切です。 [SRC[>>3 6.]]
** 引数
[92] [CODE(MIME)@en[[[application/json]]]] には[[引数]]が定義されていません。
[93] たまに [CODE(MIME)@en[[[charset]]]] [[引数]]が付けられていることがあります。
[125] [CODE(MIME)@en[[[charset]]]] が指定されていないと [[UTF-8]] であっても正しく[[復号]]できない実装があります。
[TIME[2013-03-06T07:46:28.900Z]]
[129] 他方、[[引数]]なしの「[CODE(MIME)@en[[[application/json]]]]」でないと [[JSON]]
が指定されたとみなさない実装もあります。
[FIG[
[FIGCAPTION[
[147] [CODE(MIME)@en[[[application/json]]]] の[[引数]]
]FIGCAPTION]
- [CODE(MIME)@en[[[charset]]]]
- [CODE(MIME)@en[[[ieee754compatible]]]]
- [CODE(MIME)@en[[[odata.metadata]]]]
- [CODE(MIME)@en[[[odata.streaming]]]]
]FIG]
** [CODE(MIME)@en[+json]] で終わる MIME 型
[FIG[
- [98] [CODE(MIME)@en[[[application/jsonml+json]]]]
- [122] [CODE(MIME)@en[[[application/ld+json]]]]
- [99] [CODE(MIME)@en[[[application/microdata+json]]]]
]FIG]
* 拡張子
[94] [[JSON]] の[[拡張子]]には [CODE(file)@en[[[.json]]]] [SRC[>>3 6.]] がしばしば使われます。
* Macintosh ファイル型
[95] 古い [[Mac OS]] で[[ファイル]]の種類を表す[[符号]]としては [CODE[[[TEXT]]]]
が使われます [SRC[>>3 6.]]。
* 素片識別子
[96] [[RFC]] では[[素片識別子]]には言及されていません。
[97] [[JSON]] では[[素片識別子]]は使われていません。
[162] [[JSON Pointer]] というものがあり、[[JSON]] の[[素片識別子]]として使われることが想定されています。
* 歴史
[REFS[
- [3] [CITE@en[RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON)]]
- [34] [CITE[Annotated ES5]]
-- [35] [CSECTION@en[5.1.5 The JSON Grammar]]
-- [36] '''[CSECTION@en[15.12 The JSON Object]] '''
]REFS]
[104] [[ES5]] は、 [[RFC]] を引用しつつも独自に構文や解釈を規定しています。
[[Webブラウザー]]は [[ES5]] を実装しており、現在ではこちらが [[JSON]] の定義として参照されるべきものでしょう。
[163] その後 [[ECMA-404]] が出版されました。 [[ES6]] は [[ECMA-404]] を参照するように改められています。
ただし [CODE(JS)@en[[[JSON]]]] オブジェクトや構文解析、直列化の方法は [[ES]] 側に残されています。
** ietf-json と ECMA-404
[194] 2013年の初め頃、 [[IETF]] において [[RFC 4627]] を改訂して[[標準化過程]] [[RFC]]
とすることを目指す動きが起こり、 [DFN[[[IETF]] JSON [RUBYB[作業部会]@en[working group]]]]
([DFN[[[ietf-json]]]]) が組織されました。細かな修正もありますが、[[Informational]] から[[標準化過程]]に移すことで、
([[IETF]] の標準化手続き上) より他の[[標準化過程]] [[RFC]] から参照しやすくすることが主たる目的だったようです。
[195] 当初は [[JSON]] の考案者で [[RFC 4627]] の著者でもある [[Douglas Crockford]]
も協力する姿勢を見せていましたが、改訂の方向性に納得がいかなかったのか、2013年の中頃には関わらないようになります。
その理由は明言していませんし、 [[ietf-json]] [[メーリングリスト]]の記事をみても議論がはっきり決裂しているわけではないのですが、
Douglas が意図的に曖昧にし (各言語・環境の) 実装に委ねている箇所を特定の解釈に固定したり、
[[部分集合]]や拡張によって非互換な[[プロファイル]]を作ろうとしたりする動きに賛成しかねているようです。
[196] 2013年の夏、 Douglas と [[ECMA]] [[TC 39]] ([[ECMAScript]] の標準化コミュニティー) は [[ES5.1]]
における [[JSON]] の定義を元にした独立した [[JSON]] の仕様書を作成し、数週間で [DFN[[[ECMA-404]]]]
として出版されました。 [[ES6]] からは [[JSON]] の定義は削除され、 [[ECMA-404]] を参照する形に改められました。
ただし [CODE(JS)@en[[[JSON]]]] オブジェクトの定義や [[ECMAScript]] との相互変換の定義は [[ES6]]
側に残されています。
[197] この ([[IETF]] では考えられないくらいに) 素早い新仕様の出版に、 [[Tim Bray]] ら [[ietf-json]]
側の関係者は [[JSON]] の標準化を行っているのは [[ietf-json]] であって [[TC 39]] では無い、
[[TC 39]] とは協力関係にあったはずなのに連絡もなかったなどと非難しますが、
[[TC 39]] 側はほとんど相手にしていません。互いの仕様の不備を主張し合うなど、両者の溝は埋まりません。
そこへ一見無関係な [[W3C]] の [[TAG]] も乱入してきて、
[[RFC]] の改訂版は [[ECMA-404]] の定義を参照するべきとするコメントを [[IETF]]
側に送付するなど、ちょっとした騒ぎになりました。
[198] 結局 [[RFC]] の改訂版は [[ECMA-404]] を参照していますが、違いを説明するために引用しているに過ぎず、
独自に [[JSON]] を定義しています。ただし [[JSON]] 全体は[[オブジェクト]]や[[配列]]だけでなく、
任意の値となるよう拡張されました ([[ECMA-404]] と同等になりました。 >>47、>>101 を参照。)
その他にも旧 [[RFC]] や [[ECMA-404]] にない規定が追加されています。更に [[JSON]]
の拡張や[[部分集合]]を定義することが引き続き [[ietf-json]] で検討されています。
こうして [[IETF]] によって [[JSON]] は [[fork]] されました。
[REFS[
- [179] [CITE[''''''[''''''Json'''''']'''''' Coordinating publication of 4627bis with ECMA]]
( ([TIME[2013-05-17 10:20:05 +09:00]] 版))
- [180] [CITE@en[charter-ietf-json-01]]
( ([TIME[2013-10-21 05:27:10 +09:00]] 版))
- [181] [CITE@en[JavaScript Object Notation (json) - Charter]]
( ([TIME[2013-10-21 05:28:37 +09:00]] 版))
- [182] [CITE[json Discussion Archive - Thread Index]]
( ([TIME[2013-10-23 18:32:14 +09:00]] 版))
- [183] [CITE[''''''[''''''Json'''''']'''''' Possible next work for the WG]]
( ([TIME[2013-10-16 19:21:19 +09:00]] 版))
- [184] [CITE[''''''[''''''Json'''''']'''''' Authorship]]
( ([TIME[2013-09-27 18:20:05 +09:00]] 版))
- [185] [CITE[''''''[''''''Json'''''']'''''' JSON & ECMA]]
( ([TIME[2013-03-19 21:22:04 +09:00]] 版))
- [186] [CITE[''''''[''''''Json'''''']'''''' Two Documents]]
( ([TIME[2013-06-18 14:21:41 +09:00]] 版))
- [187] [CITE[Re: ''''''[''''''Json'''''']'''''' Two Documents]]
( ([TIME[2013-06-19 14:52:20 +09:00]] 版))
- [188] [CITE[''''''[''''''Json'''''']'''''' 2-step proposal 4627bis + I-JSON]]
( ([TIME[2013-07-08 16:50:03 +09:00]] 版))
- [189] [CITE[''''''[''''''Json'''''']'''''' Consensus call: document title]]
( ([TIME[2013-06-24 16:20:15 +09:00]] 版))
- [190] [CITE[''''''[''''''Json'''''']'''''' What are we trying to do?]]
( ([TIME[2013-07-03 20:21:08 +09:00]] 版))
- [191] [CITE[Appropriate list for JSON standardization disussion]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [126] ( ([TIME[2013-03-11 16:24:22 +09:00]] 版))
- [127] [CITE[''''''[''''''apps-discuss'''''']'''''' JSON mailing list and BoF]]
( ([TIME[2013-02-19 20:50:03 +09:00]] 版))
- [131] [CITE@en[Next Steps on JSON + Proposed TAG Resolution]]
( ([[Appelquist Daniel (UK)]] 著, [TIME[2013-10-18 04:39:12 +09:00]] 版))
- [133] [CITE@en[draft-ietf-json-rfc4627bis-04 - The JSON Data Interchange Format]]
( ([TIME[2013-10-14 08:15:24 +09:00]] 版))
- [134] [CITE@en[draft-ietf-json-rfc4627bis-06 - The JSON Data Interchange Format]]
( ([TIME[2013-10-16 22:34:48 +09:00]] 版))
- [135] [CITE@en[Re: XHR vs JSON, was: Next Steps on JSON + Proposed TAG Resolution]]
( ([[Bjoern Hoehrmann]] 著, [TIME[2013-10-18 21:47:00 +09:00]] 版))
- [136] [CITE[Re: ''''''[''''''Json'''''']'''''' I-JSON vs. JSON-S]]
( ([TIME[2013-07-08 16:50:05 +09:00]] 版))
- [138] [CITE[Re: ''''''[''''''Json'''''']'''''' Comments on proposed charter for JSON]]
( ([TIME[2013-03-01 20:54:39 +09:00]] 版))
- [139] [CITE@en[Re: Next Steps on JSON + Proposed TAG Resolution]]
( ([[Tim Bray]] 著, [TIME[2013-10-19 00:01:07 +09:00]] 版))
- [140] [CITE@en[Technical Architecture Group Teleconference -- 02 Oct 2013]]
( ([TIME[2013-10-03 12:30:11 +09:00]] 版))
- [141] [CITE[tc39-notes/es6/2013-03/mar-12.md at master · rwaldron/tc39-notes]]
( ([TIME[2013-10-21 05:06:57 +09:00]] 版))
- [142] [CITE[tc39-notes/es6/2013-07/july-24.md at master · rwaldron/tc39-notes]]
( ([TIME[2013-10-21 05:13:50 +09:00]] 版))
- [143] [CITE@en[Re: ''''''[''''''Json'''''']'''''' FYI ECMA, W3C, IETF coordination on JSON]]
( ([[Allen Wirfs-Brock]] 著, [TIME[2013-10-09 04:37:43 +09:00]] 版))
- [144] [CITE@en[Re: ''''''[''''''Json'''''']'''''' FYI ECMA, W3C, IETF coordination on JSON]]
( ([[John Cowan]] 著, [TIME[2013-10-09 01:42:19 +09:00]] 版))
- [145] [CITE[Re: ''''''[''''''Json'''''']'''''' Streaming JSON parsers]]
( ([TIME[2013-07-03 06:50:40 +09:00]] 版))
- [146] [CITE[Re: ''''''[''''''Json'''''']'''''' Streaming JSON parsers]]
( ([TIME[2013-07-03 06:50:40 +09:00]] 版))
- [148] [CITE[JSON Duplicate Keys]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [149] [CITE[JSON specification WAS: Re: JSON Duplicate Keys]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [150] [CITE[May 21, 22, 23 TC39 Meeting Notes]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [151] [CITE@en[JSON feedback we could submit]]
( ([[Anne van Kesteren]] 著, [TIME[2013-11-11 12:08:26 +09:00]] 版))
- [152] [CITE@en[JSON: remove gap between Ecma-404 and IETF draft]]
( ([[Anne van Kesteren]] 著, [TIME[2013-11-12 16:01:30 +09:00]] 版))
- [153] [CITE@en[Concerns from the W3C Technical Architecture Group regarding JSON]]
( ([[Philippe Le Hegaret]] 著, [TIME[2013-11-27 07:31:33 +09:00]] 版))
- [155] [CITE@en[Re: ''''''[''''''Json'''''']'''''' Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)]]
( ([[Tim Bray]] 著, [TIME[2013-11-28 09:13:40 +09:00]] 版))
- [156] [CITE[''''''[''''''Json'''''']'''''' Response to Statement from Ecma International TC39]]
( ([TIME[2013-12-06 16:51:36 +09:00]] 版))
- [157] [CITE@en[TAG Teleconference -- 05 Dec 2013]]
( ([TIME[2013-12-09 15:52:58 +09:00]] 版))
]REFS]
[202] [[Tim Bray]] と [[ietf-json]] による [[RFC]] の改訂版は、2014年3月に [DFN[[[RFC 7158]]]]
として出版されました。ところがこのとき [[RFC Editor]] が誤って日付を「201'''3'''年3月」
としてしまったため、すぐに修正して [DFN[[[RFC 7159]]]] として再出版されました。
[203] これだけでも前代未聞の珍事ですが、どうやら [[RFC Editor]] も相当慌てていたらしく、
当初の [[RFC 7159]] は Errata のリンクや [[IANA Considerations]] の章の記述が「[[RFC 715'''8''']]」
のままになっていました。それらを修正したものがすぐに '''[[RFC 7159]] のまま'''再出版されました。
;; [205] この旧版 [[RFC 7159]] は2014年3月20日の時点で [[Google]] のキャッシュに [[HTML]]
版と [[PDF]] 版が残っています。 [[RFC Editor]] のサイトでも >>204 には [[PDF]]
版がまだ残っています。イレギュラーな操作で改版してここだけ差し替えを忘れているのでしょうか。
[206] さすがに3つ目の [[RFC]] を発行することは憚られたのでしょうが、一度出版した [[RFC]]
を置き換えないというポリシーを守るために日付だけ書き換えた [[RFC]] を再発行し、
日付が間違った [[RFC]] を (廃止状態とはいえ) 放置したり、
その直後にポリシーを歪めてより多くの箇所を変更した [[RFC]] を同じ番号で改版したりと、
[[RFC]] の発行手続きの運用上の大きな問題を曝け出す形になりましたが、なぜか [[IETF]]
界隈ではそれほど重大な問題として取り上げられていないようです。
;; [207] このような再出版に関する [[RFC Editor]] と著者の間のやり取りも個別に行われていたと見られ、
[[ietf-json]] などの[[メーリングリスト]]には記録は特に残っていません。
[209] >>201 は [[RFC 7158]] と新版 [[RFC 7159]] の差分です。
[210] このような流れを皮肉ってか、 [[RFC 7159]] への [[Errata]] として、
“全文を削除して「[[RFC 7158]] 参照」に置き換える”という修正案まで提案されています (>>208)。
[212] >>211 は [[RFC 4627]] と新版 [[RFC 7159]] の差分です。
[REFS[
- [199] [CITE@en[RFC 7158 - The JavaScript Object Notation (JSON) Data Interchange Format]] ([TIME[2014-03-04 16:52:46 +09:00]] 版)
- [200] [CITE@en[RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format]] ([TIME[2014-03-07 18:11:43 +09:00]] 版)
- [201] [CITE[wdiff rfc7158.txt rfc7159.txt]] ([TIME[2014-03-23 09:55:50 +09:00]] 版)
- [204] ([TIME[2014-03-03 10:54:26 +09:00]] 版)
-- [171] [[魚拓]] ( ([TIME[2014-03-20 16:10:57 +09:00]] 版))
- [211] [CITE[wdiff rfc4627.txt rfc7159.txt]] ([TIME[2014-03-23 10:19:06 +09:00]] 版)
- [208] [CITE[RFC Errata Report]] ([TIME[2014-03-23 10:16:41 +09:00]] 版)
- [168] [CITE@en[ongoing by Tim Bray · JSON Redux AKA RFC7159]]
( ([TIME[2014-03-18 02:26:29 +09:00]] 版))
- [170] [CITE[RFC 7159 — the JSON Data Interchange Format]]
( ([TIME[2014-03-04 17:33:33 +09:00]] 版))
]REFS]
* 実装
[192] 現在ではありとあらゆる言語で [[JSON]] が実装されています。
[193] ただし [[JSON]] の仕様が (本項で長々と説明している通り) 半ば意図的に細部を曖昧にしていることもあり、
細部の実装はそれぞれに異なっており、境界ケースや独自拡張機能を使っていると他の実装で意図通り扱えないことがよくあります。
* [CODE(JS)@en[JSON]] オブジェクト (JavaScript)
- [CODE(JS)@en[[[JSON.parse]]]]
- [CODE(JS)@en[[[JSON.stringify]]]]
** 歴史
[9] [CITE[Re: Native JSON parsing API]] ([[Henri Sivonen]] 著, [TIME[2008-06-16 06:12:12 +09:00]] 版)
>
The JSON parsers I've used in non-browser contexts have been Draconian
and incompatible with existing content such as output from
del.icio.us, which can contain escaped single quotes, which isn't
allowed in proper JSON.
[10]
[CITE[JSON Serialization (was Re: ES4 draft: Name)]] ([TIME[2008-04-01 12:34:49 +09:00]] 版)
[11] [CITE[Re: Native JSON parsing API]] ([[Maciej Stachowiak ]] 著, [TIME[2008-06-14 08:43:00 +09:00]] 版)
>Native JSON parsing is being considered for the next versions of
ECMAScript (the 3.1 and 4 versions). It seems like a better fit there
than in HTML5. If it ends up not being added to ECMAScript, I would
propose it as a standalone spec for the W3C Web Apps WG.
[12] [CITE@en[es3.1:json_support '''['''ES4 Wiki''']''']] ([TIME[2008-12-20 11:20:05 +09:00]] 版)
[14] [CITE@ja-jp[2008/9/10 - Internet Explorer 8 のネイティブ JSON]] ([TIME[2009-02-02 22:11:29 +09:00]] 版)
[15] [CITE@en-us[Firefox 3.1 for developers - MDC]] ([TIME[2009-02-08 18:25:06 +09:00]] 版)
>ネイティブ JSON の DOM バインディング( bug 408838 ) 。
** 実装
[13] [CITE@en-us[JSON - MDC]] ([TIME[2009-02-02 22:06:53 +09:00]] 版)
[16] [CITE[JSON、8進数 - 素人がプログラミングを勉強するブログ]] ([TIME[2009-06-28 10:12:45 +09:00]] 版)
>まず、0123のように、0以外で先頭が0の数値はJSONとして不正である。
>例えばJSON.parse("0123")を評価すると、IE8とWebKit(r45311)ではSyntaxErrorが投げられる。
>
Firefox(20090617のナイトリー)では、123になる。
>
http://www.json.org/json2.js:json2.jsとGoogle Chrome(3.0.191)では、83になる。
[18] [CITE@en-us[JSON - MDC]]
([TIME[2009-10-18 14:43:23 +09:00]] 版)
* 関連
** XML との関係
[172] [[JSON]] は [[XML]] とは構文的にもデータモデル的にも全く互換性も歴史的関係もありませんが、
しばしば対比して語られます。 [[XML]] は90年代末から00年代中頃にかけて、
[[文書]]と[[データ]]の両方の記述形式の大本命としてもてはやされていました。ところが [[JSON]]
の登場により、[[データ]]の情報交換形式として多くの場面で [[XML]] より [[JSON]]
の方がより勘弁で扱い易いと認識されるようになりました。 [[JSON]] は元々 [[JavaScript]]
の[[リテラル]]から派生したものですから、多くの近代的な[[プログラミング言語]]における[[オブジェクト]]とも自明な対応関係が存在しており、
多くの[[プログラマー]]達には [[XML]] よりも [[JSON]] の方が理解しやすいという性質もありました。
[173] [[Webアプリケーション]]のサーバーが提供する [[Web API]] のデータ形式としては、かつては
([CODE(DOMi)@en[[[XMLHttpRequest]]]] という[[インターフェイス]]名に象徴されるように)
[[XML]] を用いるのが最善策であると考えられていた時期もありましたが、現在では専ら [[JSON]]
が用いられています。10年代の最初期には ([[Atom]] や [[RSS]] を含め) [[XML]] ベースの形式と
[[JSON]] の両方を提供する [[Web API]] も少なくありませんでしたが、10年代中頃には後方互換性のために必要な場合を除き、
[[XML]] ベースの [[Web API]] は見られなくなっています。
[174] アプリケーションの設定ファイルの類の記述形式としても、 [[XML]]
(や [[YAML]] その他の独自形式) から [[JSON]] へのシフトが同時期に起こっています。
例えば [[Widgets 1.0]] は [[XML]] 形式の設定ファイルを使っていますが、 [[Chrome拡張]]の設定ファイルは
[[JSON]] です。
[175] 世間一般での [[XML]] の衰退と [[JSON]] の普及を後追いするように、標準化コミュニティーでもかつての [[XML]]
ベースの技術にかわり、 [[JSON]] ベースで同様の技術を定義しようとする動きがあります。例えば
[[JSON Pointer]] ([[XPointer]])、[[JSON Schema]] ([[XML Schema]])、[[JSON Web Signature]] ([[XML Signature]])、
[[JSON-LD]] ([[RDF/XML]])、[[JSON Home Document]] ([[WSDL]]、[[AtomPub]]) などが提案されています。
* メモ
[1]
[CITE[Introducing JSON]]
> [CODE[JSON]] (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
;; [29] リンク切れ [TIME[2011-08-24T11:10:03.000Z]]
[2]
''Semantic Interpretation for Speech Recognition (SISR) Version 1.0''
([[名無しさん]] [WEAK[2006-01-19 03:31:05 +00:00]])
[4]
>>3 明記されていないけど [[BOM]] は使えないということでおk?
([[名無しさん]])
[5]
不適合文書の扱いも明記されていないけど、構文解析器は不適合も処理して'''構わない'''ことになっているから、
適当に理解するなりはじくなりでおk?
([[名無しさん]])
[6]
[[サロゲート・ペア]]の片割れだけが escape されている場合は >>5?
([[名無しさん]])
[7]
[CITE@ja-JP[Matzにっき(2007-04-16)]] ([[Yukihiro -matz- Matsumoto]] 著, [CODE[2007-04-23 23:58:26 +09:00]] 版)
([[名無しさん]] [WEAK[2007-05-05 03:25:51 +00:00]])
[8]
[CITE@en[JSONLint - The JSON Validator.]] ([TIME[2008-06-22 12:32:25 +09:00]] 版)
[17] [CITE[IRC logs: freenode / #whatwg / 20090906]]
([TIME[2009-10-17 22:08:59 +09:00]] 版)
;; [33] [[JSON]] の[[構文解析]]における互換性について。 [[RFC]] は非標準の拡張を理解することを認めている。
[[ES5]] はより厳密に定義している。古い案では[[注釈]]を認めていたが、
非標準の[[指令]]の埋込みに使われるようになったため、結局認めないことになった。
[19] [CITE[as3corelib の JSON.decode() をいい加減な JSON に対応させる - てっく煮ブログ]]
([TIME[2010-01-01 12:15:16 +09:00]] 版)
[20] [CITE[IRC logs: freenode / #whatwg / 20100104]]
([TIME[2010-01-06 08:11:05 +09:00]] 版)
;; [32] [[JSON]] の[[文字符号化]]について。
[62] [[JSON]] の [[RFC]] はデータ型と構文上の要素と字句の関係を半ば暗黙のものとして扱っていて、
何がどう解釈されるかといったことを明確に規定していません。
;; [63] こういうのが、 [[Hixie]] が [[BNF]] を使わない理由の1つだよなー。
[106] [CITE[PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記]]
([TIME[2011-09-15 11:02:11 +09:00]] 版)
[107] [CITE@en-US[An update is available for the native JSON feature in Internet Explorer 8]]
([TIME[2011-10-05 11:52:02 +09:00]] 版)
[108] [CITE@en[Native JSON in IE8 - IEBlog - Site Home - MSDN Blogs]]
([TIME[2011-10-05 11:52:24 +09:00]] 版)
[109] [CITE[IRC logs: freenode / #whatwg / 20111005]]
( ([TIME[2011-10-06 22:50:15 +09:00]] 版))
[111] [CITE@en[draft-pbryan-http-json-resource-01 - A Convention for HTTP Access to JSON Resources]]
( ([TIME[2012-02-05 13:38:13 +09:00]] 版))
[113] [CITE@ja[JSONIC - simple json encoder/decoder for java]]
( ([TIME[2012-02-12 13:26:51 +09:00]] 版))
[114] [CITE[dominictarr/JSON.sh · GitHub]]
( ([TIME[2012-03-12 23:04:45 +09:00]] 版))
[123] [CITE[JSON::XSで作られる浮動小数点数でハマった話 - 北海道苫小牧市出身のPGが書くブログ]]
( ([TIME[2012-10-24 11:49:48 +09:00]] 版))
[128] [CITE[''''''[''''''whatwg'''''']'''''' asynchronous JSON.parse and sending large structured data between threads without compromising responsiveness]]
( ([TIME[2013-08-06 23:47:37 +09:00]] 版))
[130] [CITE@en[RFC 6839 - Additional Media Type Structured Syntax Suffixes]]
( ([TIME[2013-06-28 00:23:48 +09:00]] 版))
[137] [CITE@EN[XSL Transformations (XSLT) Version 3.0]]
( ([TIME[2012-07-10 14:04:59 +09:00]] 版))
[154] [CITE[twitterのXSSとJSON in ECMAScriptと外部JSONを安全に取り扱うためのアプローチ - 金利0無利息キャッシング – キャッシングできます - subtech]]
( ([TIME[2013-12-03 04:59:58 +09:00]] 版))
[164] [CITE@en[PostgreSQL: Documentation: 9.3: JSON Functions and Operators]]
( ([TIME[2013-12-17 07:19:21 +09:00]] 版))
[166] [CITE[Twitter の JSON に罪はない - ぐま あーかいぶ]]
( ([TIME[2014-01-06 18:51:36 +09:00]] 版))
[167] [CITE[IRC logs: freenode / #whatwg / 20140319]]
( ([TIME[2014-03-20 20:29:26 +09:00]] 版))