[31] JSON (JavaScript Object Notation / JavaScript オブジェクト記法) は、 JavaScript におけるオブジェクト・リテラルの部分集合によってオブジェクトや配列を表記するデータ交換書式です。 JavaScript を始め数多くの言語でライブラリーが整備されており、 汎用的なデータ構造の交換形式として広く用いられています。
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.
[219] 現在 JSON は ECMA-404 によって定義されています。
[220] それとは別に RFC 7159 にもやや異なる定義があります。
ECMA-404 を参照しつつも、独自の異なる内容も含んでいます。
混乱を招きかねないので、あまり参照するべきではないでしょう。
ただし MIME型 application/json
は RFC 7159
で定義されています (ECMA-404 では定義されていません)。
[316] RFC 7159 は RFC 7158 を再出版したもので、 RFC 4627 の改訂版でもあります。 RFC 4627 はながらく JSON の定義として参照されていましたが、 現行仕様とは異なるため、歴史的文脈以外で参照するべきではありません。
[222] 以降の各項目では ECMA-404 での定義に加えて、各仕様での歴史的な定義についても触れます。 全体としての経緯は歴史の項を参照してください。
[37] JSON 値 には次の種類があります >>132, >>3 1.。
[48] オブジェクトは、 {
の後に0個以上のメンバーを
,
で区切って並べ、最後に }
が来る文字列として表されます。
>>132, >>3 2.2.
[52] 最後のメンバーの後に ,
を入れることは認められていません。
[273] メンバーは、名前と値の組であり、文字列の後に :
が来て、
その後に値が来ます。 >>132, >>3 2.2.
[225] オブジェクトとその名前や値の解釈は仕様上定義されていません。 JavaScript ではオブジェクトに、 Perl ではハッシュ参照に対応付けられるなど、言語と環境により異なります。 また JSON を利用するプロトコルや Web API などがそれぞれで認められる名前の種類と解釈を定めていたりします。
[444] 仕様書によれば、 オブジェクトはプログラミング言語で記録、 構造体、 辞書、 写像、 ハッシュ、 オブジェクトのように呼ばれている構造に相当するものと説明されています >>132。 多くのプログラミング言語はこうした構造がありますが、 複数あることもありますし、 1つもないこともあるかもしれません。
[445]
JavaScript
では
Object
が最も近いですが、他に
Map
も似た構造を持っています。
一般的には
Object
だけを
JSONオブジェクトに直接相当するものとします。
[446] JSONオブジェクトのことを map や hash と呼ぶ人もいるようですが、 混乱の元で不適切です。
[227] メンバーの順序に意味はあるかどうかは仕様上言及されていません。
[418] 極めて稀に、実装が独自に順序に意味を持たせている場合があるようです。 しかし多くの実装はそれを想定した JSON を出力できず、 相互運用性の問題があります。
[248] RFC 7159 の追加部分によると、メンバーの順序を保持する実装と保持しない実装があるようです。
[49] RFC ではオブジェクト内で名前は固有であるべき >>3 2.2., RFC 7159 とされていますが、 ECMA-404 ではそのような制限はありません。 ECMAScript 仕様書で定義される JSON から JavaScript への変換では、 同名のメンバーのうち最後のものが JavaScript オブジェクトに反映されます。
[223] 同名のメンバーに対する処理が定義されていないため、実装によりどの値を選択するかが異なり、 セキュリティー上問題となる危険性もあります。
[247] RFC 7159 の追加部分によると、重複の内最後を選択する実装の他、エラーとなる実装やすべてを返す実装もあるようです。
[224] しばしば注釈として他の正規のメンバーと衝突しない名前を採用する慣習が一部にあり、 同名のメンバーがあってもエラーにはならないことを仮定して複数の同名のメンバーによって複数の注釈を表すことがあるようです。
[287] OAuth 2.0 は重複した指定を禁止しているようです。
[50] 配列は、 [
の後に0個以上の値を ,
で区切って並べ、最後に ]
が来る文字列として表されます。 >>132, >>3 2.3.
[232] 値の個数に上限はありません。
[51] 最後の値の次に ,
を入れることは認められていません。
値なしに ,
が連続することも認められていません。
[231] 配列がどう解釈されるのか、順序に意味があるという以上には定義されていません。 一般的には各種プログラミング言語の配列に対応付けられています。
[233] 値について、すべて同じ種類の値でなければならないなどの制約はありませんが、 JSON を利用するプロトコルその他によっては値の種類や可能な値に制約があるかもしれません。
[53] 数値は、必要なら負符号の後、整数部が来て、 必要なら小数部が来て、最後に必要なら(十の)指数部が来る形を取ります。 >>132, >>3 2.4.
[54] 先頭に正符号を使うことは認められていません。指数部では使えます。
[234] 符号の意味は自明であるためか、明確には規定されていません。
「先頭には負符号 -
を置くことができる」 >>132 との規定より、 -
で始まるなら残りの部分で表される数値が絶対値であるような負数、
そうでなければ正数を表すと解釈するのが自然でしょう。
指数部では更に +
も置くことができ >>132、
残りの部分で表される数値が絶対値であるような正数と解釈するのが自然でしょう。
[308] 0
と -0
の違いの扱いは、明記されていません。
構文上は -0
などの形で負の 0 を記述することは可能です。
JSON 仕様としては規定せず応用に委ねているのでしょう。
実際にはほとんどすべての場合に -0
は単に0 であるとして扱われ、
-0 とはみなされません。両者の違いに意味を持たせた用法は相互運用性が高くありません。
[335] 逆に JavaScript の JSON.parse
は -0
を -0
と解釈しますが、 JSON.stringify
は JSON.parse ("-0")
の結果を与えると 0
と出力します。
[55] 十進数により表記します >>132, RFC 7159。
[56] 整数部で先導0は認められていません >>132。 指数部では使えます。
[305] 小数部を含めることができます >>132。小数点は .
です >>132。小数点のみ含めて小数部を何も含めないことは認められていません。
末尾が 0
であっても構いません。
[235] 表現できる数値の最小や最大、精度は規定されていません。 JSON を利用するプロトコルその他や実装するプログラミング言語によっては制限や限界があるかもしれません。
[306] 小数部の末尾に 0
が余分にある場合とない場合とで値の解釈に相違があるかどうかは明記されていません。
JSON 仕様としては規定せず応用に委ねているのでしょう。
実際にはほとんどすべての場合に小数部の桁数は意味を持たず、
末尾の 0
の有無や 0
のみの小数部の有無は、意味を持ちません。
意味を持たせた用法は相互運用性が高くありません。
[249] RFC 7159 は次のような追加の規定を設けています。 IEEE 754-2008 binary64 (倍精度) 数が広く実装されておりますので、その範囲・精度で JSON 数を実装すると相互運用性が高くなります。その範囲外の JSON 数を使うと相互運用性の問題が生じるかもしれません。
[284] 64ビット整数を扱える環境で出力した数値は、 JavaScript の数値に変換される際に浮動小数点数に変換され、元の値と近くても異なる値に変わってしまうことがあるので、注意が必要です。
[58] 文字列は、0個以上の文字を引用符で括ることによって表されます >>132, >>3 2.5.。
[236] ただしここでいう文字は、厳密には Unicode符号位置であり、以降でも同様です。 これについては >>216 を参照してください。
[237] 文字列はJSON値の一種として、またはオブジェクトの名前の部分として用いられます。
[59] 文字 (厳密には符号位置) は escape により表現することができます。特に "
,
\
, U+0000
- U+001F
については必ず escape しなければなりません。
>>132, >>3 2.5.
[65] escape とそれによって表される文字の対応関係は次の表の通りです。
[66] escape 内の大文字と小文字は一般に区別されます。 しかし十六進数は大文字でも小文字でも構いません。 >>132, >>3 2.5.
[60] U+10000
以上の文字は UTF-16
サロゲート・ペアの2つの16ビット符号単位の列によって escape
で表せます。 >>132, >>3 2.5.
[238] 16進数はなぜか Unicode ではなく ISO/IEC 10646:2012 により解釈する >>132 とされています。しかし実用上は Unicode の任意の版と理解して構わないでしょう。
[64] サロゲートや非文字の符号位置を使うことは禁止されていません。
[61] 明記されていませんが、半分はサロゲート・ペアの符号位置そのまま、
もう半分は escape というような列で U+10000
より大きな文字を表現することは認められていないと解釈できます。
[442]
RFC 7515
は、
U+10000
以上が含まれても正しく扱えるべきとしつつ、
使用する
JSON
の実装が正しく扱えない時、
これを含む入力を拒絶しなければならないとしています。
>>439
[239] 文字の数に上下限はありません。文字列は空文字列であっても構いません。
[240] JSON を利用するプロトコル等によっては、文字の数やどのような文字列が認められるかに制限があるかもしれません。
[67] true
や false
の意味は >>132 では定義されていませんが、それぞれ boolean
の真と偽を表すと理解されています。これらは小文字でなければなりません。
[68] null
の意味は >>132 では定義されていませんが、 null を表すと理解されています。
これは小文字でなければなりません。
[101] JSON テキストとは、JSON値1つです >>132。
なお ECMAScript の仕様上はこれは JSONText
と呼ばれています >>36 15.12。
[47] RFC 4627 は JSONテキストをオブジェクトまたは配列を1つ直列化したもの >>3 2. と定義しており、文字列や数値や true や false や null のような値は認めていませんでした。 これは RFC 7159 で改められていて、現在では RFC でも >>101 の定義に揃えられています。 IETF の立場からはこれは厳密には非互換変更になります。
[216] JSONテキストは、Unicode符号位置の列として定義されています >>132。
[229] Unicode文字ではなくUnicode符号位置の列ですから、サロゲートの符号位置も含まれます。
[230] ES5 の JSON は、 BNF により SourceCharacter、すなわち UTF-16 の16ビット符号単位について定義していました >>36 15.12。この定義では、 サロゲートが正しく2つ連続する場合にサロゲートの符号位置が2つ分と解釈されるのではなく、 文字が1つと解釈されるので、厳密には >>216 の定義と違うことになりますが、 実用上は同じと言っても構わないでしょう。
[100] RFC 4627 の JSON は文字の列として定義されていました。 RFC 7159 は Unicode文字の列であるとより明確に述べています。従ってサロゲートは認められていません。 ただし ABNF 構文および escape の定義でサロゲートは除外されていません。 それらの意味は、 escape されたサロゲート2つ分として使われる場合を除き、明確に定義されていません。 RFC 7159 は実装により扱いが異なり、エラーになることもあると述べています。
[218] JSON としてはこの Unicode符号位置の列をどのような文字符号化方式で表現するかまでは規定していません。 多くのプロトコルでは UTF-8 のバイト列として転送されます。 JavaScript では UTF-16スカラー値の列である文字列として表現されます。 場合によってはシフトJIS や ISO-8859-1 など旧来の文字符号化方式が使われます。
[69] RFC の JSON は更に文字符号化の制約があります。 RFC 4627 では、 Unicode で符号化しなければならない >>3 3. とされていました。 RFC 7159 では更に制約され、 UTF-8、UTF-16、UTF-32 で符号化しなければならないとされています。 RFC 4627 にも UTF-8、UTF-16、UTF-32 を使って構わないという記述はありましたが >>3 6.、 それ以外を使ってはいけないとは明確に規定されていませんでした。
[71] 既定の符号化は UTF-8 です >>3 3.。 RFC 4627 ではこの「既定」 が何を表すのかは明記されていませんでした。特に意図がなければ UTF-8 を使うべきであるということとも、文字符号化方式が特定できないときに UTF-8 として解釈するべきということとも解釈できましたし、それ以外の解釈もあり得ました。 RFC 7159 では UTF-16 と UTF-32 に対応していない実装があり、 UTF-8 が最も相互運用性が高いという記述が追加されています。
[75] 実装はこれらの符号化方式のいずれ、あるいはすべてに対応しなければならないのか、 しなくてもよいのか、といったことは RFC 4627 ではまったく規定されておらず、 RFC 7159 でも明記はされていませんが、 UTF-8 は実装しなければならず、 UTF-16 と UTF-32 はオプションであると解釈するのが妥当でしょう。
[72] RFC 4627 の規定していた JSONテキストは、最初の2文字が必ず ASCII文字となります。 そのため、最初の4つのオクテットのパターンにより、
00 00 00 xx | UTF-32BE |
00 xx 00 xx | UTF-16BE |
xx 00 00 00 | UTF-32LE |
xx 00 xx 00 | UTF-16LE |
xx xx xx xx | UTF-8 |
... と区別できるとされています。 >>3 3. xx は 00
以外のオクテットを表すのでしょう。 JSONテキストに直接 U+0000
が出現することは無いとされているので、 00
かどうかで確実に判定できます。
[73] 一般の JSON は2文字目が必ずしも ASCII文字であるとは限りません (1文字以上の文字列や1文字だけの数の場合。) が、 それでもやはり同様にこれら5つの文字符号化方式を区別できます。
[76] この sniffing は、実装が必ず使わなければならないなどという規定は特にありません。
しかし application/json
には charset
引数がありませんし、実際にこれらの文字符号化が使われているのであれば、
これ、あるいはこれに類する sniffing を実装する以外に選択肢はありません。
[253] RFC 7159 では sniffing の項は削除されています。
[254] なお ECMA-404 は文字符号化に関して規定していないので、 sniffing への言及もありません。
[255] このような sniffing が実際に行われているのかは不明です。例えば XHR は使っていません。
[384] HTTP::Message - search.cpan.org () http://search.cpan.org/~oalders/HTTP-Message-6.13/lib/HTTP/Message.pm はこれを実装しているようです。
[160] ECMA-404 は BOM を使っても良いかどうか明記していません。ただし ECMA-404 は文字符号化については触れずにUnicode符号位置の列について定義しているに過ぎないので、 別の層の直交する問題 (つまり JSON を利用するプロトコルその他に依存する) と解するべきだと思われます。
[74] RFC 4627 は BOM について言及していませんでした。 BOM がある場合は >>72 のパターンに当てはまらず、 UTF-16 や UTF-32 であっても UTF-8 と判定されてしまいます。ただし RFC のこの部分は単なる事実の記述であって、そう解釈しなければならないなどと規定されているわけではなく、 また明確に BOM を使用してはならないと規定されているわけでもありませんから、 どう理解するべきか難しいところです。RFC 4627 の改訂にあたっても BOM が認められているかどうかは議論になっていました。
[159] RFC 7159 は JSON を生成するときに BOM を含めてはならず、 JSON を解釈するときに BOM を無視しても構わないとしています。
[341] JSON の構文上は U+0000
NULL
は認められていません。どう処理するべきかは JSON 本体仕様は規定していないので、
実装依存ということになります。
[342] HTML や CSS のような Web の各種言語に U+0000
が含まれていると、(文脈に依存して) U+FFFD
に置き換えられたり、
除去されたりします。
[343] つまり、 JSON のバイト列を受信し、文字列に変換し、
更に JSON として解釈した場合と、バイト列を HTML
として解釈し、その一部分を取り出し、その文字列を JSON
として解釈した場合で、含まれている U+0000
の解釈が変わってしまうことがあります。
[256] ECMA-404 は構文を定めるのみで、構文解析の方法は定義していません。 JSON の利用側 (例えば ECMAScript) で定義するのが適当と考えているのでしょう。
[77] RFC の定義するJSON 構文解析器は、 JSONテキストを他の表現に変形するものです >>3 4., RFC 7159。
[78] JSON構文解析器は、 JSON の文法に適合するすべてのテキストを受理しなければなりません >>3 4., RFC 7159。
[79] JSON構文解析器は、 JSON ではない形式や拡張を受理しても構いません >>3 4., RFC 7159。
[80] 受理するテキストのサイズを制限して構いません >>3 4., RFC 7159。
[81] 入れ子の深さを制限して構いません >>3 4., RFC 7159。
[82] 数値の範囲を制限して構いません >>3 4., RFC 7159。
[83] 文字列の長さや文字の内容を制限して構いません >>3 4., RFC 7159。
[102] ES5 の JSON.parse
は、 >>79 の拡張は認めておらず、
ES5 の規定に厳密に従って構文解析しなければなりません >>36 15.12。
[257] ECMA-404 は JSON の構文を定義するのみで、その生成の方法は定義していません。 プログラミング言語等の概念と JSON との対応関係は JSON の定義するところではなくそれぞれで定めるべきと考えているため、 構文は定義できても、その構文に従う文字列をどのように生成するかは定義できないのでしょう。
[85] RFC の定義する JSON 生成器は、 JSONテキストを生産するものです >>3 5., RFC 7159。
[86] JSON生成器が生産するテキストは、JSON の文法に厳密に適合しなければなりません >>3 5., RFC 7159。
[103] ES5 の JSON.stringify
は、 RFC ではなく ES5
の規定に従って JSON を生成しなければなりません >>36 15.12。
[391] 文字列から JSON を得る方法は、 ECMAScript
で規定されています。 JavaScript のプログラムからは
JSON.parse
により呼び出せます。
[392] バイト列から JSON を得る方法は、 Infra Standard で ECMAScript を参照する形で規定されています。
[388] バイト群からJSONを構文解析するには、 バイト群を次のようにします。 >>387
[398] 次の場面で使われます。
[423] JSONをバイト群に直列化するには、 JavaScript 値値を次のようにします Infra Standard。
[258] RFC が拡張された JSON に対応することを認めていることもあり、また JSON が広い分野で用いられていることもあり、いろいろな JSON の変種が「JSON」 と呼ばれていることがあります。
"
で括られないことがあります。var name =
」のような文字列がつくことがあります。,
が余分に挿入されることがあります。)]}
」のようなごみを挿入することがあります。
Source Map はこれを明示的に認めています。JSON::XS
は、符号化時に数値としての inf や nan が与えられると引用符のない
inf
や nan
を出力します。 (復号はできず構文エラーになります。) JSON::XS
は tagged value
と称して Perlモジュールとの対応付け情報が含まれた値を記述する構文を導入しています。
(ただし標準では無効になっています。)[267] JSON と互換性のあるもの、ないもの、 JSON 自体で表現できないデータモデルを JSON として表現する方法を定義するもの、 JSON に触発されただけで実際には JSON と関係性が薄いもの、JSON のプロファイルも含め、次のような名前がついた JSON の派生仕様が存在しています。
[286] CBOR は JSON データモデルとの互換性を大きな特徴として挙げています。
[21] MessagePack は JSON の派生仕様ではなく互換性はありませんが、 「It's like JSON. but fast and small.」と謳っています。各言語のライブラリーが存在し、 それなりに広く利用されているようですが、 JSON ほどとは言えなそうですし、 対象分野も必ずしも近いとは言えなそうです。少なくても Web API 等の疎結合な API を通じた情報交換目的で MessagePack が JSON と競合しているようには見えません。
[440] RFC 7515 は、構文解析器が RFC 7159 の構文に反するものを拒絶しなければならないとしています。 >>439
[441] {"a":"b"}c
のように余分なデータが含まれるものも不正な入力としなければならないことが特に注意されています。
>>439
[294] 複数の JSON 値の連続を表すデータ形式も幾つか存在しています。 意味的には JSON 単体でも配列で表せるのでしょうが、 ストリーミング処理のためには末尾まで読まないと正しいデータかどうか判定できない JSON は不適切です。
[301] i3bar は、無限に長い (閉じない) 配列を使っています >>300。
What follows is an infinite array (so it should be parsed by a streaming JSON parser, but as described above you can go for a simpler solution), whose elements are one array per status line.
[105] JavaScript の文字列リテラルでは U+2028
や U+2029
を直接記述することは認められていませんが、 JSON では認められています
>>36 15.12.2。
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.
[118] また、 __proto__
のように JavaScript 自体の持つ機能の名前と衝突した場合に、
JSON を直接 JavaScript と解釈すると問題が起こり得ることも指摘されています (>>119)。
[120] このような JavaScript との非互換性は、 JSON
オブジェクトのような正規の実装に依らず、
eval
などで JavaScript 文字列として解釈する際に発症します。しかも通常は
U+2028
などは使わない文字なので気づきにくく、時にサービス拒否攻撃のように悪用されることもあります。
[121] また、 JSON を関数で括った“だけ”であるはずの JSONP も、 (JavaScript と解釈されるのが目的のものですから、 JavaScript コードであることになり、) 実は JSON とは非互換であることになります。
[176] Perl コミュニティーの一部など、 JSON 以前に YAML が広く用いられていた人達の中には、 JSON は YAML の部分集合であるとして、 YAML の実装を元にした JSON の実装が行われていました。
[275] JSON には、 XML に対する XML情報集合のような厳密なデータモデルは存在しません。 JSON が、それを処理するシステムでどのようなデータ構造で表現されたり、 どのような API でアクセスされたりするかは、完全にシステム依存となっています。
[276] JSON が限られた種類の (多くのプログラミング言語に共通して存在する) 値だけを表現でき、 (多くのプログラミング言語の実装で) ネイティブなデータ構造に直接自明に変換可能なことが、 JSON の利用のしやすさにつながっており、 XML や YAML にかわって開発者に広く支持され、普及した一因でしょう。
[278] 多くの実装において専用の機構が不要となっているために、 (JSON を入出力形式として採用した任意のアプリケーションのデータ構造上ではなく) 純粋な JSON のデータモデル上での操作を規定しても、 相互運用可能な形で広く普及するかどうかはわかりません。
[279] 例えば JSON Pointer のような JSON データモデル上の式言語は、 プログラミング言語ネイティブなデータ構造に変換した後だと直接適用できない、 あるいはしづらい操作が含まれているかもしれません。
[213] JSON にはバイナリーデータを表現する方法がありません。文字の列は文字列として表現できますが、 バイトの列を JSON に直接含めることはできません。
[214] 文字とバイトの区別が無いか曖昧な言語や環境では文字列がバイト列として使われることもありますが、 厳密にはそのような用法は JSON ではありません。
[215] バイト列その他のバイナリーデータを扱いたい時は、 MessagePack などバイナリーデータを扱えるデータ形式を使うか、 Base64 などバイト列を文字列に符号化する方法を使って JSON の文字列に埋め込むなどする必要があります。
[364] 文字列として ISO 8601の日時形式のいずれかを採用することや、 数値や文字列として Unix time を採用することが多いようですが、 どれが主流ということもなく、他の日時形式が使われることもあります。
[89] JSON の MIME型は application/json
です >>3 6.。
[90] この他 */*+json
により JSON を使った特定の応用を表すことがあります。
[447] JSON-LD の応用は更に細分化された
*/*+ld+json
を使っていることがあります。
[124] この他に text/json
>>331, text/x-json
,
text/jaavscript
, text/x-javascript
,
application/x-javascript
,
text/plain
が使われることもあります。
[333] JSON MIME型は、次のものです >>331。
[261] JSONP は JavaScript なので、 text/javascript
を使うのが正しいですが、
JSON の MIME型になっていることもあります。
[319] LDJSON / JSON Lines の類は JSON そのものではないので、
それぞれに適切な MIME型を使うべきですが、 application/json
が使われることもあります。
application/orchestrate-export-stream+json
のように空白区切りの JSON で +json
が使われることもあります。
[91] CTE としては、 UTF-8 を使う時は 8bit
、
UTF-16 や UTF-32 を使う時は binary
が適切です。 >>3 6.
[92] 公式には application/json
には引数が定義されていません。
charset
引数[93] たまに charset
引数が付けられていることがあります。
RFC などの仕様書や Web API のドキュメントの類などでも、
しばしば charset
引数が指定されています。
[125] charset
が指定されていないと UTF-8 であっても正しく復号できない実装があります。
[129] 他方、引数なしの「application/json
」でないと JSON
が指定されたとみなさない実装もあります。
The API does support UTF-8 characters. As per the HTTP spec http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1, you need to be sure to explicitly set the character set you are using in the Content-Type header. The default character set (ISO-8859-1) is not very i18n friendly.
[289] >>288 のように charset
が application/json
にも適用されると HTTP を根拠に主張する実装もあるようです。
+json
で終わる MIME 型+json
で終わる MIME型[162] JSON Pointer というものがあり、JSON の素片識別子として使われることが想定されています。
[368] application/vnd.hyper-item+json
は独自に素片識別子を規定しています。
[104] ES5 は、 RFC を引用しつつも独自に構文や解釈を規定しています。 Webブラウザーは ES5 を実装しており、現在ではこちらが JSON の定義として参照されるべきものでしょう。
[163] その後 ECMA-404 が出版されました。 ES6 は ECMA-404 を参照するように改められています。
ただし JSON
オブジェクトや構文解析、直列化の方法は ES 側に残されています。
[194] 2013年の初め頃、 IETF において RFC 4627 を改訂して標準化過程 RFC とすることを目指す動きが起こり、 IETF JSON 作業部会 (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 の仕様書を作成し、数週間で ECMA-404
として出版されました。 ES6 からは JSON の定義は削除され、 ECMA-404 を参照する形に改められました。
ただし 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 されました。
[202] Tim Bray と ietf-json による RFC の改訂版は、2014年3月に RFC 7158 として出版されました。ところがこのとき RFC Editor が誤って日付を「2013年3月」 としてしまったため、すぐに修正して RFC 7159 として再出版されました。
[203] これだけでも前代未聞の珍事ですが、どうやら RFC Editor も相当慌てていたらしく、 当初の RFC 7159 は Errata のリンクや IANA Considerations の章の記述が「RFC 7158」 のままになっていました。それらを修正したものがすぐに RFC 7159 のまま再出版されました。
[206] さすがに3つ目の RFC を発行することは憚られたのでしょうが、一度出版した RFC を置き換えないというポリシーを守るために日付だけ書き換えた RFC を再発行し、 日付が間違った RFC を (廃止状態とはいえ) 放置したり、 その直後にポリシーを歪めてより多くの箇所を変更した RFC を同じ番号で改版したりと、 RFC の発行手続きの運用上の大きな問題を曝け出す形になりましたが、なぜか IETF 界隈ではそれほど重大な問題として取り上げられていないようです。
[209] >>201 は RFC 7158 と新版 RFC 7159 の差分です。
[210] このような流れを皮肉ってか、 RFC 7159 への Errata として、 “全文を削除して「RFC 7158 参照」に置き換える”という修正案まで提案されています (>>263)。
[212] >>211 は RFC 4627 と新版 RFC 7159 の差分です。
[246] なお RFC 7159 には誤って RFC 607 と RFC 3607 を参照しているというおもしろ不具合があります。
[192] 現在ではありとあらゆる言語で JSON が実装されています。
[193] ただし JSON の仕様が (本項で長々と説明している通り) 半ば意図的に細部を曖昧にしていることもあり、 細部の実装はそれぞれに異なっており、境界ケースや独自拡張機能を使っていると他の実装で意図通り扱えないことがよくあります。
[269] そもそも細部が意図的に曖昧にされている理由でもありますが、 JSON は色々なプログラミング言語のネイティブのデータ型と直接対応付けることが想定され、 実際そのように実装されているため、 JSON が表すものを特定の意味に厳密に固定することが困難です。
[270] 例えば数値は、こんにちの多くの計算機は IEEE 754 を採用していますが、そうでない計算機もあります。プログラミング言語によっては、 値によって整数型などとの自動型変換が行われるかもしれません。 また、文字列の内部表現はプログラミング言語によって異なります。 UTF-8 であることもあれば、 UTF-16 のこともあり、 任意の文字コードが使える言語もあります。文字列型がなく、 バイト列型しかない言語もあります。オブジェクト (写像) の名前と値の組の順序が保存される言語もあれば、されない言語もあります。
[271] 従って、何をもって JSON が正しく実装されているかいないか判断すること自体が厳密には困難です。 同じプログラミング言語における JSON の実装であっても、 異なる対応付けの方法が存在し得ます。 JSON の構文の仕様に加えて、 JSON と特定の環境等との対応付けの仕様が決められて、初めて適合性を議論できます。
[272] 例えば ECMAScript は、 JSON
オブジェクトの定義において
JSON 文字列と JavaScript データとの相互変換の方法を厳密に決めています。
[169] Perl で JSON を扱うモジュールは多数あります。 Perl には boolean context はありますが、データ型としての boolean は存在していません。 JSON の boolean を Perl の SV の 1/0 に対応付けたり、 1/0 の scalar reference に対応付けたり、 モジュール独自のオブジェクトとして表現したりと、 モジュールごとに様々な表現方法が採られています。
[281] Perl のデータと JSON のデータの関係が規定されていない以上、 どの実装が正しいとも誤りだとも言えません。どの実装がより便利かという議論はもちろん可能です。
[282] 同じ Perl という言語を使っていても、あるモジュールで JSON に変換したデータを別のモジュールで Perl に変換した結果、 元のデータに戻るとは限りません。この意味で、あるモジュールが実装する“JSON” と別のモジュールが実装する“JSON”は別物かもしれません。
[321] JavaScript は JSON と JavaScript データ構造の相互変換のための
JSON
オブジェクトなどの API を提供しています。
[322] application/json
への navigate では、
テキストファイルとして扱われるのが普通です。
ただしこの動作は現時点で標準化されていない事実上の標準状態です。
[323] JSON を単なるテキストではなく、整形して表示するブラウザー拡張もあり、 Web開発者には好評です。
[324] 開発者ツールでは fetch の記録などの画面で JSON を単なるテキストではなく、整形して表示する機能が備わっていることがあります。
[325] DnD 処理ではマイクロデータを JSON 形式で表現する仕様がありますが、 実装されていないようです。
[326] Web App Manifest やブラウザー拡張の定義ファイルなどでは JSON 形式が使われています。
[327] report-uri
への報告や OAuth 2.0
の一部の処理などでは JSON 形式が使われています。
[328] Webアプリケーションの API などでは、00年代後半から XML にかわる標準的なデータ形式として広く採用されています。
app.json
application/vnd.api+json
contribute.json
application/webpush-options+json
[435] JSON_checker, http://www.json.org/JSON_checker/
[436] 公式テストデータ。受理するかしないかにわかれている。 取り出したデータについてまでは検査しない。 ライセンスが明記されていない。
[433] nst/JSONTestSuite: A comprehensive test suite for RFC 8259 compliant JSON parsers, https://github.com/nst/JSONTestSuite
[434] 構文解析器の適合性の検査用データ。 RFC 8259 に基づくため、 JSON の定義 (ECMA-404) に対して正しい解釈かどうかは疑義が残る。 結果は受理、不受理、受理してもしなくてもよいに分かれている (この辺がなんとも怪しい)。 取り出したデータについてまでは検査しない。 MITライセンス。
[437] test262/test/built-ins/JSON at master · tc39/test262, https://github.com/tc39/test262/tree/master/test/built-ins/JSON
[438]
JSON
JavaScript API のテスト。
JSON の構文解析や直列化のそのもののテストは豊富でない上に JavaScript
コードに埋め込まれているので再利用は難しい。
[172] JSON は XML とは構文的にもデータモデル的にも全く互換性も歴史的関係もありませんが、 しばしば対比して語られます。 XML は90年代末から00年代中頃にかけて、 文書とデータの両方の記述形式の大本命としてもてはやされていました。ところが JSON の登場により、データの情報交換形式として多くの場面で XML より JSON の方がより勘弁で扱い易いと認識されるようになりました。 JSON は元々 JavaScript のリテラルから派生したものですから、多くの近代的なプログラミング言語におけるオブジェクトとも自明な対応関係が存在しており、 多くのプログラマー達には XML よりも JSON の方が理解しやすいという性質もありました。
[173] Webアプリケーションのサーバーが提供する Web API のデータ形式としては、かつては
(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) などが提案されています。
[376] WCF は Mapping Between JSON and XML を使っています。
[373] XSLT 3.0 は XML Representation of JSON を定義しています。
[1] Introducing JSON http://www.crockford.com/JSON/
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.
[2] Semantic Interpretation for Speech Recognition (SISR) Version 1.0 http://www.w3.org/TR/semantic-interpretation/#SI7 (名無しさん 2006-01-19 03:31:05 +00:00)
[4] >>3 明記されていないけど BOM は使えないということでおk? (名無しさん)
[5] 不適合文書の扱いも明記されていないけど、構文解析器は不適合も処理して構わないことになっているから、 適当に理解するなりはじくなりでおk? (名無しさん)
[6] サロゲート・ペアの片割れだけが escape されている場合は >>5?
(名無しさん)
[7]
Matzにっき(2007-04-16) (Yukihiro -matz- Matsumoto 著, 2007-04-23 23:58:26 +09:00
版) http://www.rubyist.net/~matz/20070416.html#p01
(名無しさん 2007-05-05 03:25:51 +00:00)
[8] JSONLint - The JSON Validator. ( 版) http://www.jsonlint.com/
[17] IRC logs: freenode / #whatwg / 20090906 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20090906
[19] as3corelib の JSON.decode() をいい加減な JSON に対応させる - てっく煮ブログ ( 版) http://d.hatena.ne.jp/nitoyon/20091228/as3corelib_lazy_json
[20] IRC logs: freenode / #whatwg / 20100104 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20100104#l-342
[62] JSON の RFC はデータ型と構文上の要素と字句の関係を半ば暗黙のものとして扱っていて、 何がどう解釈されるかといったことを明確に規定していません。
[106] PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記 ( 版) http://d.hatena.ne.jp/ockeghem/20110907/p1
[107] An update is available for the native JSON feature in Internet Explorer 8 ( 版) http://support.microsoft.com/kb/976662/en-us
[108] Native JSON in IE8 - IEBlog - Site Home - MSDN Blogs ( 版) http://blogs.msdn.com/b/ie/archive/2008/09/10/native-json-in-ie8.aspx
[109] IRC logs: freenode / #whatwg / 20111005 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20111005#l-204
[111] draft-pbryan-http-json-resource-01 - A Convention for HTTP Access to JSON Resources ( ( 版)) http://tools.ietf.org/html/draft-pbryan-http-json-resource-01
[113] JSONIC - simple json encoder/decoder for java ( ( 版)) http://jsonic.sourceforge.jp/#liberalparsing
[114] dominictarr/JSON.sh · GitHub ( ( 版)) https://github.com/dominictarr/JSON.sh
[123] JSON::XSで作られる浮動小数点数でハマった話 - 北海道苫小牧市出身のPGが書くブログ ( ( 版)) http://d.hatena.ne.jp/hiratara/20121024/1351054828
[128] [whatwg] asynchronous JSON.parse and sending large structured data between threads without compromising responsiveness ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040391.html
[130] RFC 6839 - Additional Media Type Structured Syntax Suffixes ( ( 版)) http://tools.ietf.org/html/rfc6839#section-3.1
[137] XSL Transformations (XSLT) Version 3.0 ( ( 版)) http://www.w3.org/TR/xslt-30/#func-parse-json
[154] twitterのXSSとJSON in ECMAScriptと外部JSONを安全に取り扱うためのアプローチ - 金利0無利息キャッシング – キャッシングできます - subtech ( ( 版)) http://subtech.g.hatena.ne.jp/mala/20101122/1290436563
[164] PostgreSQL: Documentation: 9.3: JSON Functions and Operators ( ( 版)) http://www.postgresql.org/docs/9.3/static/functions-json.html
[166] Twitter の JSON に罪はない - ぐま あーかいぶ ( ( 版)) http://archive.guma.jp/2010/12/twitter-json.html
[167] IRC logs: freenode / #whatwg / 20140319 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20140319#l-228
[259] JSON JavaScript Object Notation - Yahoo Groups ( ( 版)) https://groups.yahoo.com/neo/groups/json/conversations/messages/1977
[260] JSON JavaScript Object Notation - Yahoo Groups ( ( 版)) https://groups.yahoo.com/neo/groups/json/conversations/messages/1966
[274] RedHanded » YAML is JSON ( ( 版)) http://viewsourcecode.org/why/redhanded/inspect/yamlIsJson.html
[280] [Json] Call for Volunteers for Liaison Manager to ECMA TC39 ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg03027.html
[283] JsonWireProtocol - selenium - A description of the protocol used by WebDriver to communicate with remote instances - Browser automation framework - Google Project Hosting ( ( 版)) https://code.google.com/p/selenium/wiki/JsonWireProtocol#Commands
'Content-Type' HTTP response header value MUST be :
Content-Type: text/json
[291] [Json] FYI: January 28 2015 Meeting Notes ( 版) http://www.ietf.org/mail-archive/web/json/current/msg03632.html
Noggit supports a number of extensions to the JSON grammar. All of these extensions are optional and may be disabled.
Comments
{ // This is a single line comment
# This is also a single line comment
/* This is a multi-line
* C-style comment.
*/
}
Unquoted Strings
{
first : Yonik,
last : Seeley
}
Single Quoted Strings
JSON strings are normally encapsulated by double quotes. It’s often desirable to use single quotes if for example you are embedding some JSON in another double quoted string in a program.
['how', 'now', 'brown', 'cow']
Backslash escape any character
Sometimes one may not know exactly what characters need to be backslash escaped. It can be useful to accept this without throwing an exception.
'This is just a " string'
Trailing commas / extra commas
Although flow outputs standard JSON, quotes and curly braces are omitted in the sample JSON listings in this document to make them easier to read. We call this light JSON format "JSON-L".
[299] [Json] Closing of the group ( 版) http://www.ietf.org/mail-archive/web/json/current/msg03646.html
The JSON working group will have as its only task the minor
revision of RFC 7159 to bring it to Internet Standard, and fully
acknowledge the syntax definition in ECMA-404. The work is essentially
a reclassification in place, with absolute minimal changes, though those
changes will require publication of a new RFC.
[303] Mail Archive ( 版) https://mailarchive.ietf.org/arch/search/?email_list=json
[304] [Json] WG Action: Formed Javascript Object Notation Update (jsonbis) ( 版) http://www.ietf.org/mail-archive/web/json/current/msg03665.html
[313] JSON can also be 1 or false or "hi!" · whatwg/fetch@1a1b977 ( 版) https://github.com/whatwg/fetch/commit/1a1b977b65afbaf5f6d55cff4ee29246db05abb1
[329] 1201632 – iframe does not fire onload when 404 is not text/html or text/plain ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=1201632
[330] Increase the number of MIME types rendered as text · Issue #124 · whatwg/html ( 版) https://github.com/whatwg/html/issues/124
[332] Fix #124: make more types follow text/plain navigate logic · whatwg/html@f94f3c4 ( 版) https://github.com/whatwg/html/commit/f94f3c4595fbc5fecb747ef52f46cdc5f2b3feec
The WG charter is at < https://datatracker.ietf.org/wg/jsonbis/charter/ >.
In a nutshell, the goal of this effort is to produce a bis to 7159 that:
* promotes JSON to IETF Internet Standard
* references ECMA-404 and is a reference for ECMA-404
Tim Bray has agreed to edit 7159bis.
As a start, I propose we start with rfc7159 and:
1) Apply verified errata from < https://www.rfc-editor.org/errata_search.php?rfc=7159 >
2) Change the reference to ECMA-404 from informative to normative
[336] draft-ietf-jsonbis-rfc7159bis-00 - The JavaScript Object Notation (JSON) Data Interchange Format ( 版) https://tools.ietf.org/html/draft-ietf-jsonbis-rfc7159bis-00
I have really major heartburn with introducing a Normative Reference to ECMA404 in 7159bis. Because language in standards documents should be used carefully, and “Normative Reference” has a very specific meaning, and that meaning clearly does not apply in this case. However, since there is apparently a feeling that there is some benefit to the community in achieving “standards harmony”, let me propose three ways forward:
1. Include a normative reference to ECMA404, but accompany it with text explaining that this reference is marked normative because it is considered authoritative in the community of _javascript_ language specifiers, not in the normal sense of “normative”; there is no necessity to read it in order too understand or implement RFC7159bis, nor does it specify any technology which must be present in an implementation that is not also described in 7159bis.”
2. Do not include a normative reference, but expand the note about ECMA404 in Section 1.2 to emphasize that ECMA404 may be considered authoritative in the community of _javascript_ implementers.
3. Conclude that this effort has no observable benefit to the community implementing JSON on the Internet and abandon the RFC7159bis project.
[338] Predictable Serialization for JSON Tools ( 版) http://webpki.org/ietf/draft-rundgren-predictable-serialization-for-json-tools-00.html
[339] [Json] Normative reference reasoning and logistics ( 版) http://www.ietf.org/mail-archive/web/json/current/msg03729.html
To request this format using $format, use the value jsonverbose. To request this format using the Accept header, use the MIME type application/json;odata=verbose.
[345] Technical Architecture Group Teleconference -- 17 Oct 2013 ( 版) http://www.w3.org/2001/tag/2013/10/17-minutes.html
[346] add "charset=utf-8" to content-type "application/json" · Issue #383 · request/request ( 版) https://github.com/request/request/issues/383
[347] encoding/json: serialization of angle brackets is incompatible with ES6 · Issue #14749 · golang/go ( 版) https://github.com/golang/go/issues/14749
[11] [Json] jsonbis - Not having a session at IETF 96 ( ()) https://www.ietf.org/mail-archive/web/json/current/msg03910.html
[12] [Json] Working Group Last Call of draft-ietf-jsonbis-rfc7159bis-02 () https://www.ietf.org/mail-archive/web/json/current/msg03940.html
[13] [Json] JSON irritants () https://www.ietf.org/mail-archive/web/json/current/msg03961.html
curlの場合
curl -i -H "Accept: application/json; version=0.5" -X GET http://localhost:8080/api/users
今回はversion<1.0.0だとerrorを返すようにしました。
Some examples use the combination of a JavaScript single-line comment
(//) followed by an ellipsis (...) as placeholder notation for
content deemed irrelevant by the authors. These placeholders must of
course be deleted or otherwise replaced, before attempting to
validate the corresponding JSON code example.
The only variation now compared to ES6 JSON.stringify is that
Go continues to encode negative zero as "-0", not "0", so that
the value continues to be preserved during JSON round trips.
[349] seriot.ch - Parsing JSON is a Minefield 💣 (Nicolas Seriot著, ) http://seriot.ch/parsing_json.php
[350] nst/JSONTestSuite: A comprehensive test suite for RFC 7159 compliant JSON parsers () https://github.com/nst/JSONTestSuite
I just noticed that the document went to state "Publication Requested" early December, with no notification of the working group, and (IMHO) some of the few feedback that the document received during WG LC being ignored
[352] RFC 7159 の改訂版である 7159bis が WG に何の断りもなく (未解決の問題もあるのに) RFC に進もうとしている、と気づいて問い合わせていますが、 いつの間にか話がすり替えられて ECMA との協調問題になっています。 IETF 側としてはさっさと RFC を出版して WG を閉鎖したいようです。 そして RFC を出版すれば ECMA-404 も改訂されると思っています (根拠は不明)。
[312] JSON データ (SQL Server) () https://msdn.microsoft.com/library/dn921897.aspx
[354] XPath and XQuery Functions and Operators 3.1 () https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#json
The input may contain deviations from the grammar of [RFC 7159], which are handled in an ·implementation-defined· way. (Note: some popular extensions include allowing quotes on keys to be omitted, allowing a comma to appear after the last item in an array, allowing leading zeroes in numbers, and allowing control characters such as tab and newline to be present in unescaped form.) Since the extensions accepted are implementation-defined, an error may be raised [err:FOJS0001] if the input does not conform to the grammar.
reject An error is raised [err:FOJS0003] if duplicate keys are encountered.
use-first If duplicate keys are present in a JSON object, all but the first of a set of duplicates are ignored.
use-last If duplicate keys are present in a JSON object, all but the last of a set of duplicates are ignored.
[357] XSLT and XQuery Serialization 3.1 () https://www.w3.org/TR/2017/REC-xslt-xquery-serialization-31-20170321/#json-output
[358] [Json] Last Call: <draft-ietf-jsonbis-rfc7159bis-03.txt> (The JavaScript Object Notation (JSON) Data Interchange Format) to Internet Standard () https://www.ietf.org/mail-archive/web/json/current/msg04022.html
[359] Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 () https://www.ietf.org/mail-archive/web/json/current/msg04046.html
[360] [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" () https://www.ietf.org/mail-archive/web/json/current/msg04062.html
[361] Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" () https://www.ietf.org/mail-archive/web/json/current/msg04101.html
[362] Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" () https://www.ietf.org/mail-archive/web/json/current/msg04126.html
Content-Type: application/json; profile="http://example.com/alpha"
[366] Issue 17906: JSON should accept lone surrogates - Python tracker () https://bugs.python.org/issue17906
The conversion only takes place if the "/" characters are escaped (that is, the JSON looks like "\/Date(700000+0500)\/"), and for this reason WCF's JSON encoder (enabled by the WebHttpBinding) always escapes the "/" character.
[370] Mapping Between JSON and XML () https://msdn.microsoft.com/en-us/library/bb924435(v=vs.110).aspx
If you specify no accept header, we’ll return human-readable JSON with comments. If you prefer to receive compact JSON with no whitespace or comments, add the "application/json" Accept header.
RFC7159 is taken as the definitive specification of JSON for the purposes of this document. The RFC explains its relationship with other JSON specifications such as [ECMA-404].
Many JSON implementations allow commas to be used after the last item in an object or array, although the specification does not permit it. The option spec="liberal" is provided to allow such deviations from the specification to be accepted. Some JSON implementations also allow constructors such as new Date("2000-12-13") to appear as values: specifying spec="liberal" allows such extensions to be accepted, but does not guarantee it.
[375] 「Many」というのは事実なのでしょうか。まあ most とはいっていないですし、 著者が many だと思えば many なのでしょうが...
[378] Add frozen array types to the list of JSON types (tobie著, ) https://github.com/heycam/webidl/commit/375b588732858cbf5fd815e9df4ed78727d62c6c
[379] Add frozen array types to the list of JSON types by tobie · Pull Request #373 · heycam/webidl () https://github.com/heycam/webidl/pull/373
[380] JSON clone: correct cycle detection (jugglinmike著, ) https://github.com/w3c/webdriver/commit/fe771535f9839b3be4845fc87b9685f034d8af9f
[381] ACTION-732: Investigate relationship between ECMA's JSON spec and IETF RFC 7159 - Efficient Extensible Interchange Working Group Tracker () https://www.w3.org/2005/06/tracker/exi/actions/732
[382] Re: [Json] Call for Consensus: Proposed Text for "8.1 Character Encoding" () https://www.ietf.org/mail-archive/web/json/current/msg04176.html
[383] JSON parsing is not a `tryable` function (shs96c著, ) https://github.com/w3c/webdriver/commit/f296a9966c726b4c4486cb8440e80b02557733c8
[385] Define parse JSON from bytes (annevk著, ) https://github.com/whatwg/infra/commit/7af92770c9c5f89df3b201784cc45eee7c9e9a8b
[386] Define parse JSON from bytes by annevk · Pull Request #156 · whatwg/infra () https://github.com/whatwg/infra/pull/156
[394] Use Infra for JSON parsing (annevk著, ) https://github.com/whatwg/fetch/commit/d095af0ebb3343d294c37fab5c124b1a2534b6a6
[395] Use Infra for JSON parsing by annevk · Pull Request #610 · whatwg/fetch () https://github.com/whatwg/fetch/pull/610
[396] Use Infra for JSON parsing by annevk · Pull Request #153 · whatwg/xhr () https://github.com/whatwg/xhr/pull/153
[397] Parse JSON from bytes · Issue #619 · w3c/manifest () https://github.com/w3c/manifest/issues/619
[401] Meta: export FormData's concepts (annevk著, ) https://github.com/whatwg/xhr/commit/1937a2e5509e5a7b2dd933ef0f2e8fa599666ff2
SafariDriverサーバーの スクリーンショットを取得するWebDriver API で返ってくるBASE64データが、ChromeDriverサーバーやGeckoDriverサーバーなどと違って、スラッシュ記号がエスケープされた状態になっています。これはJSON仕様としては正しい(エスケープしてもしなくてもいい)実装で、公式クライアントライブラリーもこれに対応して正しくスクリーンショットのデータを取得できる状態になっています。
2nd edition (December 2017)
[404] [Json] Corrected Announcement: STD 90, RFC 8259 on The JavaScript Object Notation (JSON) Data Interchange Format () https://www.ietf.org/mail-archive/web/json/current/msg04236.html
[405] [Json] [Editorial Errata Reported] RFC8259 (5210) () https://www.ietf.org/mail-archive/web/json/current/msg04238.html
[408] >>405 STD に進めることが目的の改訂だったはずなのに、 その肝心の STD 番号を書き忘れるとか、 相変わらず JSON の RFC は不遇だなwww
[409] こんな初歩的なミスばかりしている RFC Editor は一体何の仕事してる人達なんですか?
[406] [Json] WG Action: Conclusion of Javascript Object Notation Update (JSONBIS) () https://www.ietf.org/mail-archive/web/json/current/msg04239.html
[407] [Json] [Technical Errata Reported] RFC8259 (5218) () https://www.ietf.org/mail-archive/web/json/current/msg04240.html
[410] Move JavaScript and JSON MIME types from HTML (domenic著, ) https://github.com/whatwg/mimesniff/commit/2ca219fd45c764267d37506d989c77751c171e59
[411] Move JavaScript and JSON MIME types from HTML by domenic · Pull Request #58 · whatwg/mimesniff () https://github.com/whatwg/mimesniff/pull/58
[412] Editorial: update usage of the MIME Sniffing Standard (domenic著, ) https://github.com/whatwg/html/commit/fc82f4f8774a2e7e80f6c9477bd881f6c783b186
[413] Editorial: update usage of the MIME Sniffing Standard by domenic · Pull Request #3455 · whatwg/html () https://github.com/whatwg/html/pull/3455
[414] JSON-serialized client data is wrong · Issue #712 · w3c/webauthn () https://github.com/w3c/webauthn/issues/712
[415] Fix #712: Refer to the JSON object as %JSON% by emlun · Pull Request #813 · w3c/webauthn () https://github.com/w3c/webauthn/pull/813
[416] RFC Errata Report » RFC Editor () https://www.rfc-editor.org/errata/eid5318
[417] [Json] [Technical Errata Reported] RFC8259 (5355) () https://www.ietf.org/mail-archive/web/json/current/msg04309.html
Requests and responses with a JSON message body MUST have a Content-Type header value of application/json.
Requests MAY add the charset parameter to the content type. Allowed values are UTF-8, UTF-16, and UTF-32. If no charset parameter is present, UTF-8 MUST be assumed.
Responses MUST include the metadata parameter to specify the amount of metadata included in the response.
Responses MUST include the IEEE754Compatible parameter if Edm.Int64 and Edm.Decimal numbers are represented as strings.
Requests and responses MAY add the streaming parameter with a value of true or false, see section Payload Ordering Constraints.
[420] A dictionary inheriting from a non-JSON type can't be a JSON type. (#571 (bzbarsky著, ) https://github.com/heycam/webidl/commit/d3b317273c6e8b184ad6023ac145cf25c933a50e
[421] Is a dictionary which has an inherited dictionary with a non-JSON-type member a JSON type? · Issue #555 · heycam/webidl () https://github.com/heycam/webidl/issues/555
[422] A dictionary inheriting from a non-JSON type can't be a JSON type. by bzbarsky · Pull Request #571 · heycam/webidl () https://github.com/heycam/webidl/pull/571
[426] Add "serialize JSON to bytes" algorithm (equalsJeffH著, ) https://github.com/whatwg/infra/commit/25f6859e6faafdd3822f37efaa8efea3fd07153e
[427] Infra lacks a "JSON stringify and UTF-8 encode to bytes" operation · Issue #193 · whatwg/infra () https://github.com/whatwg/infra/issues/193
[428] add 'JSON stringify and UTF-8 encode to bytes' algorithm by equalsJeffH · Pull Request #207 · whatwg/infra () https://github.com/whatwg/infra/pull/207
[429] Editorial: Add %JSONStringify% intrinsic object by equalsJeffH · Pull Request #1272 · tc39/ecma262 () https://github.com/tc39/ecma262/pull/1272
[430] Use final name for "serialize JSON to bytes" by domenic · Pull Request #1024 · w3c/webauthn () https://github.com/w3c/webauthn/pull/1024
[431] proposal-json-superset/README.md at master · tc39/proposal-json-superset () https://github.com/tc39/proposal-json-superset/blob/master/README.md
[432] CORB: protecting certain nosniff and 206 responses (anforowicz著, ) https://github.com/whatwg/fetch/commit/794dd5452705564538440cc5b2c1f13d909e2f9a