[31] JSON は、 JavaScript におけるオブジェクト・リテラルの部分集合によってオブジェクトや配列を表記するデータ交換書式です。
[25] 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 第2版 >>4042 によって定義されています。
[268] その前は制定の ECMA-404 第1版 >>4041 によって定義されていました。
[315] それ以前は ES5 に定義が含まれていました。 ES6 とそれ以降は ECMA-404 を参照する形になっています。
[454] ECMA-404 は JSON の開発者らによって策定され、 JavaScript と同じ標準化団体が管掌しています。
[220] それとは別に IETF の RFC 8259 (旧版: RFC 7159 >>314) にもやや異なる定義があります。 ECMA-404 を参照しつつも、独自の異なる内容も含んでいます。
[290] 混乱を招きかねないので、あまり参照するべきではないでしょう。 明示的に IETF の RFC が参照されている場合以外は、 これに従う必要はありません。
[286]
ただし MIME型 application/json は
RFC 8259 (旧版: RFC 7159)
で定義されています (ECMA-404 では定義されていません)。
[316] RFC 7159 は RFC 7158 を再出版したもので、 RFC 4627 の改訂版でもあります。 RFC 8259 はそれらの改訂版です。
[324] RFC 4627 はながらく JSON の定義として参照されていましたが、 現行仕様とは異なるため、歴史的文脈以外で参照するべきではありません。
[295] ECMA-404 はいろいろなプログラミング言語や応用での利用を想定して、 許容範囲を広く若干の曖昧性を持たせて規定されています。 それはプログラミング言語等各プラットフォームはそれぞれ異なるデータモデルを持っているのですから、 特定の利用方法に限定するよりは、一般化された構文を定めるだけで、 あとは各応用に委ねるべきという考えに依るものです。
[470] これは多様な環境と前提の応用との相互変換の便宜を図るためではあるのですが、
その曖昧性が相互運用性を脅かすきらいもあります。
そのためもあって、
JSON は JavaScript から派生したものですから、
ECMAScript
仕様書に規定された JSON オブジェクトで用いられる
JSON と JavaScript オブジェクトとの相互変換の規定が、
事実上の参照実装に相当するものと考えられています。
JSON とプログラミング言語等との対応関係で迷う所があれば、
ECMAScript
における規定と整合する形を取るのが好ましいでしょう。
[441] なお、 JSON の最も一般的な利用形態の1つであろう Webプラットフォームでの取り扱いについては、 Infra Standard >>387 等に規定があります。 Infra Standard は ECMAScript の規定をベースに Webプラットフォームのデータモデルとの相互変換処理を定めています。 Web で JSON を使うときは、その規定と整合した形とするのが望ましいでしょう。
[117] 以上より、特に事情がないとき JSON の仕様として参照するべきなのは、
JSON および関連する規定... ということになります。
[222] 以降の各項目では ECMA-404 での定義に加えて、各仕様での歴史的な定義についても触れます。 全体としての経緯は歴史の項を参照してください。
[466] 名称の JSON は JavaScript Object Notation >>4041, >>4042 (JavaScript オブジェクト記法) を略したものです。 JavaScript の構文から派生した歴史を物語っています。
[467] 発音は /ˈdʒeɪ·sən/ で、 Jason and The Argonauts (日本語版: アルゴ探検隊の大冒険) の 「Jason」 と同じと説明されています。 >>4042
[37] JSON における単位となるモノは値と呼ばれます。 JSON値 には次の種類があります >>132, >>3 1.。
[48] オブジェクトは、 { の後に0個以上のメンバーを
, で区切って並べ、最後に } が来る文字列として表されます。
>>132, >>3 2.2.
[52] 最後のメンバーの後に , を入れることは認められていません。
[273] メンバーは、名前と値の組であり、文字列の後に : が来て、
その後に値が来ます。 >>132, >>3 2.2.
[225] オブジェクトとその名前や値の解釈は仕様上定義されていません。 応用に依ります。 >>4042 6
[500] JavaScript ではオブジェクトに、 Perl ではハッシュ参照に対応付けられるなど、言語と環境により異なります。 また JSON を利用するプロトコルや Web API などがそれぞれで認められる名前の種類と解釈を定めていたりします。
[444] 仕様書によれば、 オブジェクトはプログラミング言語で記録、 構造体、 辞書、 写像、 ハッシュ、 オブジェクトのように呼ばれている構造に相当するものと説明されています >>132。 多くのプログラミング言語はこうした構造がありますが、 複数あることもありますし、 1つもないこともあるかもしれません。 どれにどのような形で対応付けるかは、各応用に委ねられています。
[445]
JavaScript
では
Object
が最も近いですが、他に
Map
も似た構造を持っています。
一般的には
Object
だけを
JSONオブジェクトに直接相当するものとします。
[446] JSONオブジェクトのことを map や hash と呼ぶ人もいるようですが、 混乱の元で不適切です。
[227] メンバーの順序に意味はあるかどうかは仕様上定められていません。
[165] ECMA-404 の第1版は特に言及していませんでした。 ECMA-404 の第2版は、順序に意味は与えないとし、 応用に依存するとしています。 >>132
[418] 極めて稀に、実装が独自に順序に意味を持たせている場合があるようです。 >>120
[121] しかし多くの実装はそれを想定していないため、 相互運用性の問題があります。 多くの実装は順序を明示的に維持して JSON を出力できません。 多くのライブラリーは JSON 中の順序が保証された状態でアプリケーションに引き渡すことができません。
[248] RFC 7159 の追加部分によると、メンバーの順序を保持する実装と保持しない実装があるようです。 >>314
[158]
順序が意味を持つことを想定しない実装には、
事実上の参照実装であるところの
ECMAScript JSON オブジェクトも含まれます。
ECMA-404
が順序に意味を持たせることを容認も禁止もしていないとはいえ、
それを利用する応用が好ましいとは到底言い得ません。
[177] RFC 7159 とその前の版である RFC 4627 は、 オブジェクトを順序のない集成だと説明していました。 >>314 これは ECMA-404 の定める本来の JSON 仕様には無い IETF 独自の解釈です。
[178] ECMA-404 第2版によれば、 オブジェクト内の名前が固有でなければならない (重複してはいけない) という制約は、 JSON としては、ありません。 >>4042 6
[49] RFC はオブジェクト内で名前は固有であるべき >>3 2.2., RFC 7159 としていますが、 ECMA-404 の本来の JSON 仕様にはない IETF 独自の制限です。
[267] 実質的な参照実装である ECMAScript 仕様書で定義される JSON から JavaScript への変換では、 同名のメンバーのうち最後のものが JavaScript オブジェクトに反映されます。
[247] RFC 7159 の新規追加部分によると、重複の内最後を選択する実装の他、エラーとなる実装やすべてを返す実装もあるようです。
[224] しばしば注釈として他の正規のメンバーと衝突しない名前を採用する慣習が一部にあり、 同名のメンバーがあってもエラーにはならないことを仮定して複数の同名のメンバーによって複数の注釈を表すことがあるようです。
[287] OAuth 2.0 は重複した指定を禁止しているようです。
[555]
JOSEヘッダーや JWK
や JWK集合では拒絶または JSON.parse 相当の動作のどちらかと決められています。
[223] 同名のメンバーに対する処理が JSON レベルでは定義されていないため、 セキュリティー上問題となる危険性もあります。
[512] 実装によりどの値を選択するかが異なり、 JSON を元に決定される処理が実装によって変化することがあります。 相互運用性に支障が出ていることは言うまでもありませんが、 セキュリティーに関わる挙動の食い違いも起こり得ます。
[50] 配列は、 [ の後に0個以上の値を ,
で区切って並べ、最後に ] が来る文字列として表されます。 >>132, >>3 2.3.
[232] 値の個数に上限はありません。
[51] 最後の値の次に , を入れることは認められていません。
値なしに , が連続することも認められていません。
[231] 配列がどう解釈されるのか、順序に意味があるという以上には定義されていません。 一般的には各種プログラミング言語の配列に対応付けられています。
[502] ECMA-404 の旧版は、 順序に意味があるとしていました。 >>4041 7
[503] 新版は、 値の順序に特に意味は定めないとしつつ、 順序に何らかの意味がある状況でしばしば使われる、 としています。 >>4042 7
[504] すなわち、旧版は順序に意味があるときに使わなければならないと強めに解釈される余地があるところ、 新版ではそこに意味を見ても見なくてもいい、 と実情により一致する厳密な表現に改められています。
[505] 汎用ライブラリーが配列の値の順序を保持して応用に引き渡さなければならないことには変わりありません。 応用はその順序情報を使っても無視してもいいということです。
[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。
[514] ECMA-404 旧版は 「base 10」と書いていました。 >>4041 8 新版は「decimal」と書いています。 >>4042 8 どちらも同じ意味ですが、旧版の方が意味が明瞭だったように思われます。 (新版の方が英語としては自然なのかもしれませんが。)
[56] 整数部で先導0は認められていません >>132。 指数部では使えます。
[305] 小数部を含めることができます >>132。小数点は .
です >>132。小数点のみ含めて小数部を何も含めないことは認められていません。
末尾が 0 であっても構いません。
[235] 表現できる数値の最小や最大、精度は規定されていません。 JSON を利用するプロトコルその他や実装するプログラミング言語によっては制限や限界があるかもしれません。
[306] 小数部の末尾に 0 が余分にある場合とない場合とで値の解釈に相違があるかどうかは明記されていません。
JSON 仕様としては規定せず応用に委ねているのでしょう。
実際にはほとんどすべての場合に小数部の桁数は意味を持たず、
末尾の 0 の有無や 0 のみの小数部の有無は、意味を持ちません。
意味を持たせた用法は相互運用性が高くありません。
[249] RFC 7159 は次のような追加の規定を設けています。 すなわち、 IEEE 754-2008 binary64 (倍精度) 数が広く実装されておりますので、その範囲・精度で JSON 数を実装すると相互運用性が高くなります。その範囲外の JSON 数を使うと相互運用性の問題が生じるかもしれません。
[515] これは ECMA-404 にはない記述で、 JSON としての仕様上の制約ではありません。 また RFC 7159 においても強制ではありません。 現実にその範囲外の数値が含まれる JSON が使われる場合もあるにはあります。 しかし同時に相互運用性の問題が生じているのも事実なので、 避けるのが無難なのは事実です。
[284] 64ビット整数を扱える環境で出力した数値は、 JavaScript の数値に変換される際に浮動小数点数に変換され、元の値と近くても異なる値に変わってしまうことがあるので、注意が必要です。
[57] 無限大やNaNは表現できません。 >>132, >>3 2.4.
[310] 次のような場合は、 JSON 数値ではなく、文字列として扱う方が安心です。
[58] 文字列は、0個以上の文字を引用符で括ることによって表されます >>132, >>3 2.5.。
[237] 文字列はJSON値の一種として、またはオブジェクトの名前の部分として用いられます。
[236] 厳密には、文字列は、 Unicode符号点の列です。 >>4041 9, >>4042 9 これについては >>216 も参照してください。
[59] Unicode符号点は、 それを直接記述するか、 escape により表現することができます。 >>132, >>3 2.5.
[517]
Unicode符号点のうち、
",
\, U+0000 - U+001F
については必ず escape しなければなりません。
>>132, >>3 2.5.
それ以外の Unicode符号点も escape することができます。
[519] ほとんどのUnicode符号点は、2つ以上の方法で記述できます。 どの方法で記述しても、意味するものは同じで、等価です。 原記述の違いを JSON を解釈する実装が応用に引き渡して応用がその違いを使ってもいいのかどうか、 ECMA-404 仕様上は不明瞭です。 一般にはそうした違いを応用が区別して処理することはないと考えられています。 つまり JSON の著者は、編集上の都合で好きな方法で記述できます。
[239] 文字の数に上下限はありません。文字列は空文字列であっても構いません。
[240] JSON を利用するプロトコル等によっては、文字の数やどのような文字列が認められるかに制限があるかもしれません。
[64] サロゲートや非文字の符号位置を使うことは禁止されていません。
[61] 明記されていませんが、半分はサロゲート・ペアの符号位置そのまま、
もう半分は escape というような列で U+10000
より大きな文字を表現することは認められていないと解釈できます。
[442]
RFC 7515
は、
U+10000
以上が含まれても正しく扱えるべきとしつつ、
使用する
JSON
の実装が正しく扱えない時、
これを含む入力を拒絶しなければならないとしています。
>>439
[65] escape とそれによって表される文字の対応関係は次の表の通りです。
[66] escape では、大文字と小文字の区別があります。 ここに示した通りに書かなければなりません。 ただし十六進数 HHHH は大文字でも小文字でも構いません。 >>132, >>3 2.5.
[518]
\uHHHH の HHHH は、4桁の16進数です。
[ U+0000, U+FFFF ]
の範囲の符号点の値を意味します。
そしてこの escape はその符号点を表します。
>>4041 9, >>4042 9
これについては >>216 も参照してください。
[60]
[ U+10000, U+10FFFF ]
の範囲のUnicode符号点は
UTF-16
サロゲートペアの2つの16ビット符号単位の列によって escape
で表せます。 >>132, >>3 2.5.
これについてはも >>216 を参照してください。
[573] escape してもしなくても表せるUnicode符号位置を escape するかどうかは、 実装により様々です。いろいろな流派があります。
U+0000, U+001F ] (C0)"\+/<U+007F, U+009F ]U+0080, U+10FFFF ]U+2028, U+2029U+10000, U+10FFFF ][574] すべて escape してしまえば安全で可搬性は高まりますが、長くなる上に可読性は落ちます。 人間が読み書きできるという JSON の大きなメリットを潰してしまいます。 機械同士の通信にだけ使って人間が介在しない場面ではそれほど問題にはならないのでしょうが、 デバッグやトラブル解決が面倒になります。
U+2028, U+2029#✎[565]
かつては JSON で文字列リテラルにそのまま書ける
U+2028 LINE SEPARATOR
と
U+2029 PARAGRAPH SEPARATOR
が
JavaScript
では書けないという違いがありました。
[566] 滅多に遭遇しないのにたまに発生して不具合を発生させる発覚しにくい障害と脆弱性の温床となっていました。
[567] 頃に JavaScript 側で仕様変更があって >>564, >>563、 JSON と JavaScript のどちらでもこれらが認められる形で解消されました。
[67] true や false の意味は >>132 では定義されていませんが、それぞれ boolean
の真と偽を表すと理解されています。これらは小文字でなければなりません。
[68] null の意味は >>132 では定義されていませんが、 null を表すと理解されています。
これは小文字でなければなりません。
[556] オブジェクトの値や配列の値として、他のオブジェクトや配列を指定できます。 つまり値を入れ子に (ネスト) できます。
[557] JSON 仕様としては入れ子の深さの制限はありません。 何重にでも深い構造を記述できます。
[558] Webプラットフォームでは明文規定はありませんが、 JSON を解釈する実装は、 ハードウェア制限条項に基づき十分深いところまでで対応を打ち切ることが可能です。 といってもWeb互換性のため、制限は10や20のような浅いレベルでは足りません。
[559] IETF の推奨が適用される仕様においては、 実装が制限を設けることが明文規定で認められています (>>81)。
[561]
実際に制限を設けている実装もあります。
例えば SQLite は (厳密に言えば JSON ではなく JSON と似て非なる
JSON5 を更に独自に拡張したもの (
[292] JSON はテキスト構文 >>4042 (テキスト書式 >>4041) で、 JSONテキストは Unicode符号位置の列 >>4041, >>4042 だと説明されています。
[298] つまり JSON はバイト列ではありませんし、 (メモリー上の) オブジェクトモデルでもありません。 JSON をバイト列として送受信できますし (実際多いですし)、 それを処理するならメモリー上に読み込むのは当然ですが、 それら自体は JSON 本体規格がカバーする事項ではないということです。
[101] JSON テキストとは、JSON値1つです >>132。
なお ECMAScript の仕様上はこれは JSONText と呼ばれています >>36 15.12。
[47] RFC 4627 は JSONテキストをオブジェクトまたは配列を1つ直列化したもの >>3 2. と定義しており、文字列や数値や true や false や null のような値は認めていませんでした。
[474] これは RFC 7159 で改められていて、現在では RFC でも >>101 の定義に揃えられています。 IETF の立場からはこれは厳密には非互換変更になります。
[46] JSONテキストは、次の字句により構成されます >>132, >>3 2.。
[457] 空白は JSON としておよび応用としての意味を持ちません。 空白を挿入したり削除したりしても、その JSONテキストが表すものは変化しません。
[216] JSONテキストは、Unicode符号点の列です >>132, >>4041, >>4042。
[520] これは JSONテキストの全体だけでなく、 JSON 構文要素の一種である文字列も、 Unicode符号点の列とされています (>>236)。
[238] ところが文字列中の escape における16進数だけはなぜか Unicode ではなく ISO/IEC 10646 により解釈するとされています >>132, >>4041 9, >>4042 9。
[499]
そのためなのか、
ECMA-404
はなぜか
The Unicode Standard
と
ISO/IEC 10646
の両方を Normative References で引用しています。
>>4041 3, >>4041 2
これをどう解釈するべきかは説明されていません。
(このような問題は他の仕様書にもたまにあります。
[521] 一般には JSON は escape もふくめてすべて Unicode と解釈されており、 ISO/IEC 10646 への参照は無視して構わないと考えられます。 規格の厳密な解釈の観点以外では、 それで特に問題はありません。
[217] ECMA-404 旧版は Unicode 6.2.0 と ISO/IEC 10646:2012 を引用していて、 仕様書には特定版を参照しているのだと明言されています。 >>4041 固定する意図は不明で、 実用上は任意のUnicodeの版と解釈して構わないでしょう。
[472] 新版は最新版の The Unicode Standard と ISO/IEC 10646 を参照するよう改められました。 >>4042
[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 は実装により扱いが異なり、エラーになることもあると述べています。
utf-8 や utf-16
の復号時に不正なサロゲートは U+FFFD
に置き換えられますから、
受信したバイト列を復号して得られたJSONデータにサロゲート符号点が含まれることはありません。
しかし Webページ中の JavaScript コードで作成された文字列データや、
Encoding Standard に従わずに復号するプログラムを使って得られた文字列データなど、
不正なサロゲート符号点が含まれるUnicode符号点列は発生し得ます。[522]
文字列の escape では、
[ U+10000, U+10FFFF ]
の範囲のUnicode符号点をそのままの形で記述することができません。
そのかわりに、
UTF-16 のサロゲートペアに相当するサロゲート符号点2つの
escape
の組み合わせによって記述できます
>>4041 9, >>4042 9。
[524] ECMA-404 の新版では、旧版になかった次のような規定が加わりました。すなわち、 JSONテキストの処理器はそのような2つの escape を単一の符号点として解釈しても良いし、 明示的なサロゲートペアであると解釈しても良く、 それは特定の処理器の意味的な決定により決められることであります。 >>4042 9
[525] この「意味的」という区分は、 ECMA-404 の規定する JSON の適用範囲は構文のみであること (>>295) や、 応用が対象とする JSON の意味的な制約を課しても構わないとすること (>>482) に関係してきます。
[526] より実際的には、現在市場の主要な Unicode の実装が UTF-8 ベースのものと UTF-16 ベースのものに分かれており、 UTF-8 ではこの範囲の符号点を 1つの単位で扱う一方、 UTF-16 ではサロゲートペアの2つの 16ビット符号単位として扱うことを、そのまま受け入れたものといえます。
[527] ただ、この2つの escape が構文上の表現方法の違いに過ぎず応用からは不可視なものとは捉えず、 「意味的」な判断により処理方法を変更可能としてしまったことは、 相互運用性に幾ばくかの悪影響を与えているおそれもあります。
[528] ECMA-404 は、サロゲートペアの片方がそのまま記述され、 もう片方が escape になっているようなものに、 何も言及していません。 構文上はそのような記述も認められますが、 それが何を表すか (サロゲートペアを表すのか、そうでない何かを表すのか) はよくわかりません。
[529] ECMA-404 は、サロゲート符号点が単独で記述され、 または escape されたサロゲート符号点が単独で記述されたものに、 何も言及していません。 構文上はそのような記述も認められ、 サロゲート符号点そのものを表すと解釈する他ありません。
[530]
文字列データを UTF-8 (WTF-8) で扱う実装では、
サロゲート符号点はただのサロゲート符号点でしかありません。
それが2つ並んでいても、サロゲートペアとして解釈されることはありません。
従って、例えば
「"サロゲート1\uHHHHサロゲート2"」
をサロゲート1サロゲート2の2つの符号点の列とする解釈があり得ます。
[531]
文字列データを UTF-16 で扱う実装では、
サロゲート符号点が2つ正規の形で並ぶと必ずサロゲートペアとして解釈されてしまいます。
従って、
例えば
「"サロゲート1\uHHHHサロゲート2"」
をサロゲート1サロゲート2の2つの16ビット符号単位の列とした段階で、
それはサロゲートペアが表す1つの符号点の列にしかなりません。
[532]
HTML の文字参照はこのような不整合を防ぐため、
単独のサロゲート符号点は U+FFFD に置き換えることとしています。
JSON の実装もそのような解釈を採るのが1案ではありますし、
それによって ECMA-404 に違反するとはいえません。
[533] しかしどの実装方法も ECMA-404 が認めた「唯一の方法」ではありません。 相互運用性は無いものと思うしかありません。
[570] 実装によっては単独のサロゲートが出現したときエラーを出したり、 おかしな動作をしたりします。 >>569
[571] ライブラリー等の利用者はこのような境界ケースまで一々注意しきれないことが多いと予想されますので、 ライブラリー等の制作者は安全な挙動を標準とするように配慮するべきです。 どうするのが好ましいかは、そのプラットフォームの文字列型の仕様は例外機構の挙動などによって変わってくることでしょうが、 ここでもやはり JavaScript の挙動を模範とするのが良いでしょう。
[110] プログラミング言語やマーク付け言語などの文字列系のデータ型は、 非文字の符号位置の利用を禁止していることがあります。 JSON の文字列との相互変換の際には注意が必要です。
[218] JSON としてはこの Unicode符号位置の列をどのような文字符号化方式で表現するかまでは規定していません。
[27] 多くのプロトコルでは UTF-8 のバイト列として転送されます。 JavaScript では UTF-16スカラー値の列である文字列として表現されます。 場合によってはシフトJIS や ISO-8859-1 など旧来の文字符号化方式が使われます。
[69] RFC の JSON には文字符号化の制約があります。 ECMA-404 の本来の JSON 仕様には含まれず、 IETF の規格など RFC を参照した仕様にのみ適用される制約です。
[546] RFC 8259 に従う JSONテキストは、 閉じた生態系の内部を除いた系同士の交換において、 RFC 3629 UTF-8 で符号化しなければなりません。 >>353
[548] 「閉じた生態系」かどうかの判定基準は示されていないので、 この規定がどのような状況で適用され、どのような状況で適用されないのかは、 明らかにし難い場合もあります。
[552] IETF が規定するプロトコルでその RFC が RFC 8259 を参照するようなものは、 「IETF の公開プロトコル」 という閉じていない生態系に属するものですから、 この規定が適用され、 UTF-8 を使わなければならないと解釈するのが妥当でしょう。
[553]
特定のウェブサーバーが出力し、それと対応関係にある特定のクライアント側
JavaScript プログラムだけが処理するような JSON
データは、
たとえそれが IETF の定義する application/json
MIME型でラベル付けされていようとも、
閉じた生態系に属するものと解して良さそうに思われます。
その場合 UTF-8 を使おうが使うまいが、
特定少数の開発者間の意思決定だけで相互運用性は確保できます。
[87] RFC 4627 では、 Unicode で符号化しなければならない >>3 3. とされていました。 UTF-8、UTF-16、UTF-32 を使って構わないという記述はありましたが >>3 6.、 それ以外を使ってはいけないとは明確に規定されていませんでした。
[547] RFC 7159 では更に制約され、 UTF-8、UTF-16、UTF-32 で符号化しなければならないとされていました。 >>353
[550] RFC 4627 ではこの「既定」 が何を表すのかは明記されていませんでした。特に意図がなければ UTF-8 を使うべきであるということとも、文字符号化方式が特定できないときに UTF-8 として解釈するべきということとも解釈できましたし、それ以外の解釈もあり得ました。
[551] RFC 7159 では、 UTF-16 と UTF-32 に対応していない実装があり、 UTF-8 が最も相互運用性が高いという記述が追加されました。
[75] 実装はこれらの符号化方式のいずれ、あるいはすべてに対応しなければならないのか、 しなくてもよいのか、といったことは RFC 4627 ではまったく規定されておらず、 RFC 7159 でも明記はされていませんが、 UTF-8 は実装しなければならず、 UTF-16 と UTF-32 はオプションであると解釈するのが妥当でしょう。
[549] RFC 8259 はそこから更に限定して原則 UTF-8 としました。 大多数の実装が UTF-8 を選んでいるので相互運用性が達成できるのはそれしかないのだと説明されています。 >>353
[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 はこれを実装しているようです。
[70] Web においては WHATWG の Infra Standard 等に基づき原則 UTF-8 が使われます (>>388, >>450)。
[477] Webにおける文字コードも参照。
[160] ECMA-404 は BOM を使っても良いかどうか明記していません。 ただし ECMA-404 は文字符号化については触れずにUnicode符号位置の列について定義しているに過ぎないので、 別の層の直交する問題 (つまり JSON を利用するプロトコルその他に依存する) と解するべきだと思われます。
[88]
JSON の構文上、
先頭に
ZWNBSP
(BOM と同じ U+FEFF)
が来ることは認められていません。
従って、
BOM を使えないプロトコルや文字コードで使ってしまった場合、
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 を無視しても構わないとしています。
[554] RFC 8259 は、「ネットワーク転送される」 JSONテキストのみにと当該規定の対象を限定しました。 >>353 その意図は不明です。もっとも、そもそもネットワーク転送されない JSONテキストに RFC 8259 の効力が及ぶ状況も少なかろうとは思われますから、 実効的には同じともいえます。
[161] かつて XHR は JSON の解釈の際に BOM があれば無視するよう規定していました。
[317] >>74 の通り RFC 4627 で BOM の扱いが明記されていなかったことから、 XHR が JSON の変種を規定しているとみなす人もいました。
[26] しかし、 その程度で変種と判定されるとなると、 UTF-8 の JSON と UTF-16 の JSON は異なることになってしまいます。 「異なる JSON の利用方法がある」ならまだしも、 「JSON の異なる定義がある」と解するのは無茶でしょう。
[478]
現在の XMLHttpRequest Standard は
Webプラットフォームの共通の定義を参照するのみで、
独自の規定を持っていません。
(想定される挙動は同じで、
BOM
はあってもなくても構いません。)
NULL#✎[341] JSON の構文上は U+0000 NULL
文字の直接の記述は認められていません。
[572] それが出現したときどう処理するべきかを JSON 本体仕様は規定していないので (ただし >>481)、 実装依存ということになります。
[342] HTML や CSS のような Web の各種言語に U+0000
が含まれていると、(文脈に依存して) U+FFFD に置き換えられたり、
除去されたりします。
[343] つまり、 JSON のバイト列を受信し、文字列に変換し、
更に JSON として解釈した場合と、バイト列を HTML
として解釈し、その一部分を取り出し、その文字列を JSON
として解釈した場合で、含まれている U+0000
の解釈が変わってしまうことがあります。
[105] JSON を HTML やテキストファイルに埋め込んで出力し、 そこから取り出して利用することは Webアプリケーションでは定石ですから、 注意が必要です。
[112] C言語のような 0x00 を文字列の終端と見なすプラットフォームでは、 JSON との相互変換の際に取り扱いに注意が必要です。
[256] ECMA-404 は構文を定めるのみで、構文解析の方法は定義していません。 JSON の利用側 (例えば ECMAScript) で定義するのが適当と考えているのでしょう。
[481] JSONテキストの適合処理器は、 適合JSONテキストでない入力を受理するべきではありません。 >>4042 2
[484] 適合しない入力を受理しないべきというのは、 過去様々に行われてきた (そして現在も一部で行われる) JSON の独自拡張 (>>301) に、 JSON の実装が対応するべきではないということです。
[482] JSONテキストの適合処理器は、 その処理する適合JSONテキストの集合を制限する意味的な制約を課しても構いません。 >>4042 2
[487] ここで認められているのは意味的な制限だけであって、構文的な制限を認める規定はありません。 ということは、例えば文字列中のescapeは認めないような実装は、 適合処理器ではないということです。 想定されているのは、応用Aに特化しているので応用Aのオブジェクト形式を JSON で表現しているものにしか対応できない、という類でしょう。
[489] この規定が追加された版の ECMA-404 では IETF の RFC 8259 の存在が公認されています (>>461)。そして RFC 8259 は意味的な制約を定義していると ECMA-404 は述べています。 >>4042 3 この規定は RFC 8259 の独自の規定の存在を明示的に承認する意図で追加されたようです。 つまり、
という整理になります。
[580] なお、受理するべきJSONテキストの長さや構造の入れ子の深さの制約は、 意味的制約というよりは構文・構造的な制約と考えられますが、 こうしたものが認められるのか明らかではない、どちらかというと認められないようにも思われます。
[581] しかし現実の実装にはそうした制約が必須です。 Web ではハードウェア制限条項によって包括的に認められていると解されます。 RFC では独自の規定があります (>>80, >>81, >>83)。
[102] ES5 の JSON.parse は、 >>79 の拡張は認めておらず、
ES5 の規定に厳密に従って構文解析しなければなりません >>36 15.12。
[582] Web では基本的に 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。
[257] ECMA-404 は JSON の構文を定義するのみで、その生成の方法は定義していません。 プログラミング言語等の概念と JSON との対応関係は JSON の定義するところではなくそれぞれで定めるべきと考えているため、 構文は定義できても、その構文に従う文字列をどのように生成するかは定義できないのでしょう。
[583] 生成の方法が規定されていないということは、 構文に一致する限り、 実装の裁量で自由な方法で生成できるということです。 例えば escape を使うか使わないかを選べますし、 字句間に空白を挿入するかしないかを選べます。 汎用ライブラリーはこうした挙動を呼び出し側に指定させることもできます。
[584] JSON の応用は、生成の方法を独自に定めることもできます。 JSON を利用する場面によっては特定の生成方法しか選べないこともあります。 例えば JSON Lines では行指向の処理のため、 改行を挿入しないことが求められます。
[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
[449] 得られる結果は JavaScript値です。
[398] 次の場面で使われます。
[450] JSONをInfra値に構文解析するには、 文字列JSONテキストを、 次のようにします。 >>387
%JSONParse%, undefined, JSONテキストのみを含むリスト)
の結果に設定します。[423] JSONをバイト群に直列化するには、 JavaScript 値値を次のようにします >>387。
[301] JSON は単純で今後の拡張も予定されていないと明言されています。 >>4041, >>4042
[16]
JSON と似ているようでどこかが違う、
いろいろな JSONの変種が「JSON」 と呼ばれていることがあります。
相互運用性やセキュリティーの障害となっており、
注意が必要です。
[21]
JSON の不便な点を解消した、拡張したと称するものや、
特定用途向けに改造したもの、
マーケティング目的で JSON の名前を出しているものなど、
JSON の影響を受けているのに JSON
と大なり小なり違いがあるデータ形式も、
いろいろあります。
JSON
や
JSON を実装したライブラリー等と名前が似ていて紛らわしいものもあり、
注意が必要です。
[294] 複数の JSON 値の連続を表すJSONストリームのデータ形式も幾つか存在しています。
[22] JavaScript から派生した JSON ですが、
微妙な違いがあり、取り扱いには意外と注意が必要だったりします。
[18]
一部 YAML の支持者が YAML は JSON と互換性があるなどと喧伝したため、
JSON ではない YAML が JSON と呼ばれたり、
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
が使われることもあります。
[562]
Web API の versioning に濫用されることがあります。
[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 は独自に素片識別子を規定しています。
[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
コードに埋め込まれているので再利用は難しい。
[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”は別物かもしれません。
[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 を定義しています。
[321]
JSON はに JSON.org で発表されたとされます。
>>4041, >>4042
[322] に IETF で RFC 4627 として標準化されました。 >>3
[104] の ES5 は、 RFC 4627 を引用しつつも独自に構文や解釈を規定しています。
[323] 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 を参照しているというおもしろ不具合があります。
[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
[327] これだけ何度も RFC 出版してるのに RFC 8259 に対して承認された Errata が5件もあるの、一体どうなってるんですかね。 開発・出版プロセスに致命的問題があるのでは?
Also, a small number of errata have been reported (see RFC Errata IDs 607 [Err607] and 3607 [Err3607]).
と書かれていました。そして新 RFC 8259 には
Also, a small number of errata have been reported regarding RFC 4627 (see RFC Errata IDs 607 [Err607] and 3607 [Err3607]) and regarding RFC 7159 (see RFC Errata IDs 3915 [Err3915], 4264 [Err4264], 4336 [Err4336], and 4388 [Err4388]).
と書かれていました。 >>353
RFC 7159 も RFC 8259 もまったくの新文書ではなく旧版からの改訂ですし、 それぞれの出版前に何度も I-D を公開して改訂を続けています。 その過程で著者らはもちろん、 WG、 IESG、 RFC Editor と膨大な数の人々が何度も繰り返しチェックしています。
それだけの体制で、この程度の長さの文書で2件も誤りがあるのは多すぎます。 それを「少数」だと反省の色を見せない RFC 7159 もちょっとどうかと思うのですが、 それを踏襲した RFC 8259 が 2 + 4 件あってもまだ「少数」 だと言い張っているのは図々しい。
そんな編集態度だから、 RFC 8259 にも「少数」の誤りが報告されたのは必然という他ありません。
[545] 次の RFC では 2 + 4 + 6 件で「少数」と言い張るのをみたいですねw
でも現時点で報告済5件、却下1件なので、これ以上増えるのは難しいかなあ
[534] 旧版 RFC 7159 は、 Informative References として ES5.1 と ECMA-404 旧版を参照しつつ、 JSON はそれらでも説明されている、と述べていました。 更に古い RFC 4627 も含め、すべての JSON 仕様の構文は一致している、と述べていました。 >>353 これは嘘で、4仕様のうち RFC 4627 は明らかに違う構文でした。
[535] 新版 RFC 8259 はその記述を改め、 ECMA-404 新版を Normative References に含めました。その意味を次のように説明していました。 >>353
The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term "JSON text" in any of its specifications.
[536] これによると、通常は normative reference とは実装者が参照元を理解するために参照する必要があるような文書を意味するところ、 本件においては RFC 8259 と ECMA-404 の用語「JSON text」 の定義に不整合がないことを協調するためのものであるというのです。
[537] これはなかなか独創的な normative reference の使い方です。
を明記しています。 >>353 これは ECMA-404 新版側にあるのと同内容です (>>491)。
[542] ただし、 相互運用性の最大化のため RFC 8259 が避けることを推奨するいくつかの慣習を ECMA-404 は認めている >>353 とし、 RFC 8259 独自の「推奨」の存在を正当化しています。
[543] ところで ECMA-404 と RFC 8259 の構文が同じもので、 RFC 8259 が一定の「推奨」をしているだけなら、 それは RFC 8259 も「認めて」いる (が推奨はしていない) のでなければなりません。 RFC 8259 が「認め」ないとは書いていませんから、 嘘ではないのですが、ミスリーディングです。
[460] に ECMA-404 の改訂版である第2版が出版されました。 >>4042
[461] IETF の RFC 8259 に合わせて出版されたもので、 第1版になかった次のような歴史の説明が追加されました。
JSON was first presented to the world at the
JSON.orgwebsite in 2001. A definition of the JSON syntax was subsequently published as IETF RFC 4627 in July 2006. ECMA-262, Fifth Edition (2009) included a normative specification of the JSON grammar. This specification, ECMA-404, replaces those earlier definitions of the JSON syntax. Concurrently, the IETF published RFC 7158/7159 and in 2017 RFC 8259 as updates to RFC 4627. The JSON syntax specified by this specification and by RFC 8259 are intended to be identical.
[462]
IETF の RFC による定義が存在することを認めています。
(第1版は JSON.org の部分しか書いていませんでした。 >>4041)
[463] その上で、 RFC 4627 と ES5 が ECMA-404 によって置き換えられたという ECMA 側の認識を表明しています。
[464] また、 ECMA-404 と RFC 8259 が規定する JSON 構文は同等 (identical) を意図 (intended) しているとの見解を表明しています。
[491] 新版は旧版と違って Normative References に RFC 8259 を挙げています。そして、
を述べています。 >>4042 3 (RFC 8259 側にも同じことが書かれています。 >>539)
[494] RFC 8259 が「同等」の構文以外に独特の内容を多く含んでいることについては、
としています。 >>4042
[465] ECMA は IETF を完全に無視しても良かったはずですが、 歩み寄りの姿勢を見せています。 そして双方協力関係を保ち両仕様書の内容を同期させる、 との合意事項を明文化して示しています。
[497] ただし ECMA は IETF の独自規定は存在に言及するにとどめ、 それを採用するまでには至っていません。 IETF の独自規定は採用してしまうと本来の JSON と非互換になってしまいますから、当然の判断でしょう。
[498] そうなると「Normative References」の1つに挙げられているのはおかしなことです。 文法は技術的に同等の内容で、 それ以外は不採用なら、 ECMA-404 の規定に RFC 8259 は何ら影響を与えないのですから、わざわざ参照する必要はないのです。 それでもわざわざこの改訂で (non-normative な reference でもなく) 追加したのは、 政治的判断と推測するほかありません。
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
[448] Add "parse JSON into Infra values" (domenic, , ) https://github.com/whatwg/infra/commit/9bf763869b84aac00c8a1883ddb70485835ae861
[453] Add "parse JSON into maps and lists" by domenic · Pull Request #249 · whatwg/infra () https://github.com/whatwg/infra/pull/249
[23] ECMA-404 を日本語に翻訳したものが JIS X 3061:2021 となっています。
[24] Working with JSON data in Standard SQL | BigQuery | Google Cloud (, ) https://cloud.google.com/bigquery/docs/reference/standard-sql/json-data