[31] JSONジェイソン は、 JavaScript におけるオブジェクト・リテラルの部分集合によってオブジェクトや配列を表記するデータ交換書式です。

[25] JavaScript を始め数多くの言語プログラミング言語でライブラリーが整備されており、 汎用的なデータ構造の交換形式データ形式の事実上の標準として広く用いられています。

[30] JSON ( 版) http://www.json.org/

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 が参照されている場合以外は、 これに従う必要はありません。

[490] ECMA-404 側からの見解: >>461

[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 はいろいろなプログラミング言語や応用での利用を想定して、 許容範囲を広く若干の曖昧性を持たせて規定されています。 それはプログラミング言語等各プラットフォームはそれぞれ異なるデータモデルを持っているのですから、 特定の利用方法に限定するよりは、一般化された構文を定めるだけで、 あとは各応用に委ねるべきという考えに依るものです。

[440] 無数の利用方法をすべて1つの仕様書にまとめるのも不可能ですし、 1つでも規定してしまうとその解釈に他が引きづられてしまうからよくないという判断なのでしょう。[471] このような仕様書の設計は意図的なもので、 しかも仕様の開発者にかなり重視されているようです。 版も既に前文でそのような説明をしていますが、 版はそれに加えて本文 1 Scope で構文だけを定め、意味や処理は他に任せると明記しています。 >>132

[470] これは多様な環境と前提の応用との相互変換の便宜を図るためではあるのですが、 その曖昧性が相互運用性を脅かすきらいもあります。 そのためもあって、 JSON は JavaScript から派生したものですから、 ECMAScript 仕様書に規定された JSON オブジェクトで用いられる JSON と JavaScript オブジェクトとの相互変換の規定が、 事実上の参照実装に相当するものと考えられています。 JSON とプログラミング言語等との対応関係で迷う所があれば、 ECMAScript における規定と整合する形を取るのが好ましいでしょう。

[441] なお、 JSON の最も一般的な利用形態の1つであろう Webプラットフォームでの取り扱いについては、 Infra Standard >>387 等に規定があります。 Infra Standard は ECMAScript の規定をベースに Webプラットフォームのデータモデルとの相互変換処理を定めています。 Web で JSON を使うときは、その規定と整合した形とするのが望ましいでしょう。

[117] 以上より、特に事情がないとき JSON の仕様として参照するべきなのは、

... ということになります。

[221] json.org にも定義が掲載されていますが、現在ではこれは仕様ではなく、半公式の解説と理解するべきでしょう。

[222] 以降の各項目では ECMA-404 での定義に加えて、各仕様での歴史的な定義についても触れます。 全体としての経緯は歴史の項を参照してください。

名称

[466] 名称の JSON は JavaScript Object Notation >>4041, >>4042 (JavaScriptジャバスクリプト オブジェクト記き法ほう) を略したものです。 JavaScript の構文から派生した歴史を物語っています。

[467] 発音は /ˈdʒeɪ·sən/ で、 Jason and The Argonauts (日本語版: アルゴ探検隊の大冒険) の 「Jason」 と同じと説明されています。 >>4042

JSON 値

[37] JSON における単位となるモノは値あたいvalueと呼ばれます。 JSONじぇいそん値ちJSON value には次の種類があります >>132, >>3 1.。

  1. *
    1. 空白
  2. |
    1. 文字列
    2. 数値
    3. true
    4. false
    5. null
    6. オブジェクト
    7. 配列
  3. *
    1. 空白

オブジェクト

[48] オブジェクトは、 { の後に0個以上のメンバーmemberを , で区切って並べ、最後に } が来る文字列として表されます。 >>132, >>3 2.2.

  1. {
  2. ?
    1. メンバー
    2. *
      1. ,
      2. メンバー
  3. }

[52] 最後のメンバーの後に , を入れることは認められていません。

[244] JSON の派生元である ES3 がこれを認めておらず、当時の IE も対応していなかったためです。

[273] メンバーは、名前と値の組であり、文字列の後に : が来て、 その後に値が来ます。 >>132, >>3 2.2.

  1. *
    1. 空白
  2. 文字列
  3. *
    1. 空白
  4. :
  5. *
    1. 空白
  6. JSON値

[226] メンバーの個数に制約はありません。

[225] オブジェクトとその名前や値の解釈は仕様上定義されていません。 応用に依ります。 >>4042 6

[501] このことは ECMA-404 旧版 >>4041 は明言していませんでした。

[500] JavaScript ではオブジェクトに、 Perl ではハッシュ参照に対応付けられるなど、言語と環境により異なります。 また JSON を利用するプロトコルや Web API などがそれぞれで認められる名前の種類と解釈を定めていたりします。

[444] 仕様書によれば、 オブジェクトはプログラミング言語で記録record、 構造体struct、 辞書dict、 写像map、 ハッシュhash、 オブジェクトobjectのように呼ばれている構造に相当するものと説明されています >>132。 多くのプログラミング言語はこうした構造がありますが、 複数あることもありますし、 1つもないこともあるかもしれません。 どれにどのような形で対応付けるかは、各応用に委ねられています。

[445] JavaScript では Object が最も近いですが、他に Map も似た構造を持っています。 一般的には Object だけを JSONオブジェクトに直接相当するものとします。

[446] JSONオブジェクトのことを map や hash と呼ぶ人もいるようですが、 混乱の元で不適切です。

メンバーの順序

[227] メンバーの順序に意味はあるかどうかは仕様上定められていません。

[165] ECMA-404 の第1版は特に言及していませんでした。 ECMA-404 の第2版は、順序に意味は与えないとし、 応用に依存するとしています。 >>132

[176] この条項の解釈に当っては、配列の規定との比較が必要です。 ECMA-404 の第1版は配列の要素の順序に意味はあるとしていました。 EMCA-404 の第2版は、順序に意味は与えないとし、 順序に意味があるところで使うことが多いと付け加えました。 (>>503) >>132 オブジェクトとの表現の違いをみると、 どちらの版でも配列の方がオブジェクトより意味有りげに書かれてはいるのですが、 第2版ではオブジェクトも配列も等しく JSON 層では意味がなく、 応用層では意味があるかもしれない、と解釈されるよう配慮されていることがわかります。

[418] 極めて稀に、実装が独自に順序に意味を持たせている場合があるようです。 >>120

[121] しかし多くの実装はそれを想定していないため、 相互運用性の問題があります。 多くの実装は順序を明示的に維持して JSON を出力できません。 多くのライブラリーは JSON 中の順序が保証された状態でアプリケーションに引き渡すことができません。

[248] RFC 7159 の追加部分によると、メンバーの順序を保持する実装と保持しない実装があるようです。 >>314

[158] 順序が意味を持つことを想定しない実装には、 事実上の参照実装であるところの ECMAScript JSON オブジェクトも含まれます。 ECMA-404 が順序に意味を持たせることを容認も禁止もしていないとはいえ、 それを利用する応用が好ましいとは到底言い得ません。

[177] RFC 7159 とその前の版である RFC 4627 は、 オブジェクトを順序のない集成unordered collectionだと説明していました。 >>314 これは ECMA-404 の定める本来の JSON 仕様には無い IETF 独自の解釈です。

  • [120] Package exports | webpack, , https://webpack.js.org/guides/package-exports/#notes-about-ordering

重複メンバー

[178] ECMA-404 第2版によれば、 オブジェクト内の名前が固有でなければならない (重複してはいけない) という制約は、 JSON としては、ありません。 >>4042 6

[258] ECMA-404 第1版は固有性に特に言及していませんでした。

[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 相当の動作のどちらかと決められています。 JOSEヘッダー, JWK, JWK集合

[223] 同名のメンバーに対する処理が JSON レベルでは定義されていないため、 セキュリティー上問題となる危険性もあります。

[512] 実装によりどの値を選択するかが異なり、 JSON を元に決定される処理が実装によって変化することがあります。 相互運用性に支障が出ていることは言うまでもありませんが、 セキュリティーに関わる挙動の食い違いも起こり得ます。

[513] 入力 JSON をまず検査し、次に本処理する2つのソフトウェア部品で構成されるソフトウェアを考えます。 1つ目が最初の値を選択して検査し、 2つ目が最後の値を選択して処理するなら、 未検査の値が処理してしまう脆弱性を有しています。

[506] 以上踏まえて、新しい応用は、次の方針を採るべきでしょう。

  • [507] 同名のメンバーを記述することを JSON の著者に要求しないこと
  • [511] テキストエディターに近い操作性のソフトウェアである場合を除き、 同名のメンバーを持つ JSON を生成しないこと
  • [508] 同名のメンバーがあるとき最後のもののみを指定された値として採用すること
  • [509] 同名のメンバーがあっても致死的エラーとはみなさないこと
    • [510] 警告を出す機能を持つならその機能により報告してもいいが、 それを除いて正常処理を継続すること

配列

[50] 配列は、 [ の後に0個以上の値を , で区切って並べ、最後に ] が来る文字列として表されます。 >>132, >>3 2.3.

[232] 値の個数に上限はありません。

[51] 最後の値の次に , を入れることは認められていません。 値なしに , が連続することも認められていません。

  1. [
  2. ?
    1. JSON値
    2. *
      1. ,
      2. JSON値
  3. ]

[231] 配列がどう解釈されるのか、順序に意味があるという以上には定義されていません。 一般的には各種プログラミング言語の配列に対応付けられています。

[502] ECMA-404 の旧版は、 順序に意味があるsignificantとしていました。 >>4041 7

[503] 新版は、 値の順序に特に意味meaningは定めないとしつつ、 順序に何らかの意味semanticsがある状況でしばしばoften使われる、 としています。 >>4042 7

[504] すなわち、旧版は順序に意味があるときに使わなければならないと強めに解釈される余地があるところ、 新版ではそこに意味を見ても見なくてもいい、 と実情により一致する厳密な表現に改められています。

[505] 汎用ライブラリーが配列の値の順序を保持して応用に引き渡さなければならないことには変わりありません。 応用はその順序情報を使っても無視してもいいということです。

[233] 値について、すべて同じ種類の値でなければならないなどの制約はありませんが、 JSON を利用するプロトコルその他によっては値の種類や可能な値に制約があるかもしれません。

数値

[53] 数値は、必要なら負符号の後、整数部が来て、 必要なら小数部が来て、最後に必要なら(十の)指数部が来る形を取ります。 >>132, >>3 2.4.

  • number = ["-"] int ["." 1*DIGIT] [ exp ]
  • int = "0" / ( (DIGIT - "0") *DIGIT )
  • exp = "e" ["-" / "+"] 1*DIGIT

[54] 先頭に正符号を使うことは認められていません。指数部では使えます。

  1. ?
    1. -
  2. |
    1. 0
    2. =
      1. 1-9
      2. *
        1. 0-9
  3. ?
    1. .
    2. +
      1. 0-9
  4. ?
    1. |
      1. E
      2. e
    2. |
      1. -
      2. +
    3. +
      1. 0-9

[234] 符号の意味は自明であるためか、明確には規定されていません。 「先頭には負符号 - を置くことができる」 >>132 との規定より、 - で始まるなら残りの部分で表される数値が絶対値であるような負数、 そうでなければ正数を表すと解釈するのが自然でしょう。 指数部では更に + も置くことができ >>132、 残りの部分で表される数値が絶対値であるような正数と解釈するのが自然でしょう。

[308] 0 と -0 の違いの扱いは、明記されていません。 構文上は -0 などの形で負の 0 を記述することは可能です。 JSON 仕様としては規定せず応用に委ねているのでしょう。 実際にはほとんどすべての場合に -0 は単に0 であるとして扱われ、 -0 とはみなされません。両者の違いに意味を持たせた用法は相互運用性が高くありません。

[309] JSON への変換は -0 を -0 と出力するかもしれませんが、 JSON からの変換が -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。 指数部では使えます。

[243] 先導0が排除されているのは、JavaScript において八進数と解釈されるからです。

[305] 小数部を含めることができます >>132。小数点は . です >>132。小数点のみ含めて小数部を何も含めないことは認められていません。 末尾が 0 であっても構いません。

[235] 表現できる数値の最小や最大、精度は規定されていません。 JSON を利用するプロトコルその他や実装するプログラミング言語によっては制限や限界があるかもしれません。

[306] 小数部の末尾に 0 が余分にある場合とない場合とで値の解釈に相違があるかどうかは明記されていません。 JSON 仕様としては規定せず応用に委ねているのでしょう。 実際にはほとんどすべての場合に小数部の桁数は意味を持たず、 末尾の 0 の有無や 0 のみの小数部の有無は、意味を持ちません。 意味を持たせた用法は相互運用性が高くありません。

[307] プログラミング言語によっては小数部が含まれれば実数、 含まれなければ整数と区別することがありますが、 JSON にはそのような違いはありません。 もっとも、プログラミング言語の JSON の実装によっては JSON からの変換時にこの違いからデータ型を決めたり、 JSON への変換時にデータ型により桁数を決めたりするかもしれません。

[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.

[575] そのようなJSONもどきが使われることはありますが、 JSON ではありません。 JSONもどき

[310] 次のような場合は、 JSON 数値ではなく、文字列として扱う方が安心です。

  • 桁数に意味がある場合 (例えば小数部の桁数で精度を表す場合)
  • 符号付き32ビット整数の範囲外の整数を正確に扱いたいとき
  • 倍精度浮動小数点数で表現できない数を扱いたいとき
  • 無限大を扱いたいとき
  • NaN を扱いたいとき
  • -0 を扱いたいとき
  • 数字列であって数値でないとき (例えば電話番号)

文字列

[58] 文字列は、0個以上の文字を引用符で括ることによって表されます >>132, >>3 2.5.。

[237] 文字列はJSON値の一種として、またはオブジェクトの名前の部分として用いられます。

[585] 引用符は、 " です。

[586] ' は使えません。

[236] 厳密には、文字列stringは、 Unicode符号点の列です。 >>4041 9, >>4042 9 これについては >>216 も参照してください。

[516] ECMA-404 旧版では一部文字characterと書かれていた規定も、 新版では厳密に符号点に改められています。 >>4041 9, >>4042 9

[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] 文字の数に上下限はありません。文字列は空文字列であっても構いません。

  1. "
  2. *
    1. |
      1. \、C0 以外の文字
      2. =
        1. \
        2. |
          1. "
          2. \
          3. /
          4. b
          5. f
          6. n
          7. r
          8. t
          9. =
            1. u
            2. 4十六進数字
  3. "

[240] JSON を利用するプロトコル等によっては、文字の数やどのような文字列が認められるかに制限があるかもしれません。

[64] サロゲートや非文字の符号位置を使うことは禁止されていません。

[61] 明記されていませんが、半分はサロゲート・ペアの符号位置そのまま、 もう半分は escape というような列で U+10000 より大きな文字を表現することは認められていないと解釈できます。

[115] ES5 の JSON の構文と構文解析の定義上は、 ECMAScript の UnicodeEscape と同じとなっており、従ってサロゲート・ペアの符号位置も単なる16ビット符号単位の文字列表現として普通に解釈されるべきものであるようです。[116] Perl モジュール JSON::XS はそのようなサロゲート・ペアの符号位置に遭遇するとエラーを出して構文解析を中止します。

[442] RFC 7515 は、 U+10000 以上が含まれても正しく扱えるべきとしつつ、 使用する JSON の実装が正しく扱えない時、 これを含む入力を拒絶しなければならないとしています。 >>439

[443] そのような JSON の実装は、一昔前ならともかく、 現在となっては致命的な不具合を抱えたものと言う他ありません。 RFC 7515 の規定する JWS のようなセキュリティーを扱う技術が、 救済措置とはいえ、致命的に壊れた実装を前提とした規定を含んでいるのは、 果たして望ましいものでしょうか。
  • [439] RFC 7515 - JSON Web Signature (JWS), https://tools.ietf.org/html/rfc7515#section-10.12

文字の escape

[65] escape とそれによって表される文字の対応関係は次の表の通りです。

JSON 表記 符号点
\""
\\\
\//
\bU+0008
\fU+000C
\nU+000A
\rU+000D
\tU+0009
\uHHHHU+HHHH

[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)
そのままでは記述できないので、必ず escape しなければなりません。
"
文字列の区切りに使われるため、必ず escape しなければなりません。
\
escape に使われるため、必ず escape しなければなりません。
+
UTF-7 と誤認されるセキュリティー問題があるため escape するのが安全と考えられていた時期がありました。 今ではまず問題となりませんが、当時の慣習が引き継がれている場合があります。
/
HTML の終了タグが含まれると困ることがあるので escape するのが安全と考えられることがあります。 >>569
<
HTML のタグと誤認されるセキュリティー問題があるため escape するのが安全と考えられることがあります。
[ U+007F, U+009F ]
制御文字なので escape した方が安全という考え方があります。
[ U+0080, U+10FFFF ]
非Unicode文字なので escape した方が安全という考え方があります。
U+2028, U+2029
JavaScript との互換性の問題のため escape した方が安全と考えられていました (>>565)。 今ではまず問題となりませんが、当時の慣習が引き継がれている場合があります。
サロゲート
可搬性のため現実的に escape しなければなりません。 ただし escape したとて相互運用性には問題があります (>>524)。
[ U+10000, U+10FFFF ]
BMP 外なので escape した方が安全という考え方があります。
非文字
応用によってうまく扱えないことがあるので、 escape した方が安全という考え方があります。
非Unicode文字
そのままでも escape でも表せません。

[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 のどちらでもこれらが認められる形で解消されました。

[568] 昔と違って JSON を eval で読み込むことはまずないので、 問題になることは少なくなっていましたが。 今でも便宜上オブジェクトを JSON 化して HTML 中の script 要素の JavaScript コード中に埋め込むようなことはあるので、 共通化にはやはり恩恵があります。
  • [564] GitHub - tc39/proposal-json-superset: Proposal to make all JSON text valid ECMA-262, https://github.com/tc39/proposal-json-superset
  • [563] ECMAScript ⊃ JSON - Chrome Platform Status, https://chromestatus.com/feature/6102319234023424

boolean

[67] true や false の意味は >>132 では定義されていませんが、それぞれ boolean の真と偽を表すと理解されています。これらは小文字でなければなりません。

null

[68] null の意味は >>132 では定義されていませんが、 null を表すと理解されています。 これは小文字でなければなりません。

入れ子の値

[556] オブジェクトの値や配列の値として、他のオブジェクトや配列を指定できます。 つまり値を入れ子に (ネストnest) できます。

[557] JSON 仕様としては入れ子の深さの制限はありません。 何重にでも深い構造を記述できます。

[558] Webプラットフォームでは明文規定はありませんが、 JSON を解釈する実装は、 ハードウェア制限条項に基づき十分深いところまでで対応を打ち切ることが可能です。 といってもWeb互換性のため、制限は10や20のような浅いレベルでは足りません。

[559] IETF の推奨が適用される仕様においては、 実装が制限を設けることが明文規定で認められています (>>81)。

[561] 実際に制限を設けている実装もあります。 例えば SQLite は (厳密に言えば JSON ではなく JSON と似て非なる JSON5 を更に独自に拡張したもの ( JSON5 ) ですが)、 入れ子の深さ1000を超えると非妥当とみなします >>560。

  • [560] JSON Functions And Operators, , https://www.sqlite.org/json1.html#compatibility

構文

[292] JSON はテキスト構文text syntax >>4042 (テキスト書式text format >>4041) で、 JSONテキストJSON textは Unicode符号位置の列文字列 >>4041, >>4042 だと説明されています。

[298] つまり JSON はバイト列ではありませんし、 (メモリー上の) オブジェクトモデルでもありません。 JSON をバイト列として送受信できますし (実際多いですし)、 それを処理するならメモリー上に読み込むのは当然ですが、 それら自体は JSON 本体規格がカバーする事項ではないということです。

[473] 「JSON は UTF-8」ということはなく、そういうこともありますしそうでないこともあります。 なぜなら、 JSON とは文字列の構文なので、 それがどんな文字コードで表現されているかは JSON 本体規格でカバーされていないからです。 >>218

[101] JSON テキストtextとは、JSON値1つです >>132。 なお ECMAScript の仕様上はこれは JSONText と呼ばれています >>36 15.12。

[47] RFC 4627 は JSONテキストをオブジェクトまたは配列を1つ直列化したもの >>3 2. と定義しており、文字列や数値や true や false や null のような値は認めていませんでした。

[474] これは RFC 7159 で改められていて、現在では RFC でも >>101 の定義に揃えられています。 IETF の立場からはこれは厳密には非互換変更になります。

[228] 空文字列は JSONテキストではありません。

字句解析

[46] JSONテキストは、次の字句により構成されます >>132, >>3 2.。

[457] 空白は JSON としておよび応用としての意味を持ちません。 空白を挿入したり削除したりしても、その JSONテキストが表すものは変化しません。

[458] 文字列中の空白は当然意味を持っています。 また数値やリテラルの途中に空白を挿入することも許されません。

[459] U+0000, U+000B, U+000C, U+FEFF は JSON では空白ではありません。

[245] 多くのプログラミング言語などと異なり、 JSON には注釈がありません。

符号化文字集合

[216] JSONテキストは、Unicode符号点の列文字列です >>132, >>4041, >>4042。

[520] これは JSONテキストの全体だけでなく、 JSON 構文要素の一種である文字列stringも、 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 これをどう解釈するべきかは説明されていません。 (このような問題は他の仕様書にもたまにあります。 ISO/IEC 10646 )

[521] 一般には JSON は escape もふくめてすべて Unicode と解釈されており、 ISO/IEC 10646 への参照は無視して構わないと考えられます。 規格の厳密な解釈spec lawyerの観点以外では、 それで特に問題はありません。

[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 は実装により扱いが異なり、エラーになることもあると述べています。

[242] このサロゲートの扱いが問題となるのは、文字列の中だけです。 JSON として構文的に正しいテキストでサロゲートを含み得るのは文字列だけです。[476] Encoding Standard によれば 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。

[523] これに関する ECMA-404 の規定は (符号点と文字の区別を厳密化した新版の他の箇所の修正を踏まえると) 1箇所符号点と改めるべきだった箇所が文字と書かれています >>4042 9。

[524] ECMA-404 の新版では、旧版になかった次のような規定が加わりました。すなわち、 JSONテキストの処理器はそのような2つの escape を単一の符号点として解釈しても良いし、 明示的なサロゲートペアであると解釈しても良く、 それは特定の処理器の意味的な決定semantic decisionにより決められることであります。 >>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 の挙動を模範とするのが良いでしょう。

  • [569] JSONの小ネタと、JSONに対する拡張, https://zenn.dev/mod_poppo/articles/json-and-extension

非文字

[241] 非文字の符号位置も禁止はされていません。

[110] プログラミング言語やマーク付け言語などの文字列系のデータ型は、 非文字の符号位置の利用を禁止していることがあります。 JSON の文字列との相互変換の際には注意が必要です。

その他の符号位置

[475] 未割当符号点も禁止されていません。

文字符号化方式

[218] JSON としてはこの Unicode符号位置の列をどのような文字符号化方式で表現するかまでは規定していません。

[27] 多くのプロトコルでは UTF-8 のバイト列として転送されます。 JavaScript では UTF-16スカラー値の列である文字列として表現されます。 場合によってはシフトJIS や ISO-8859-1 など旧来の文字符号化方式が使われます。

[28] 「JSON は UTF-8 で符号化しなければならない」と解説する人がいますが、 間違っています。 ECMA-404 にそのような制約は存在しません。

[300] JSONテキストは Unicode符号点の列文字列として定義されていますから、 非Unicodeの文字コードを採用するなら、 参照処理モデル的な解釈を採用することになります。

IETF における JSON の文字コード

[69] RFC の JSON には文字符号化の制約があります。 ECMA-404 の本来の JSON 仕様には含まれず、 IETF の規格など RFC を参照した仕様にのみ適用される制約です。

[546] RFC 8259 に従う JSONテキストは、 閉じた生態系closed ecosystemの内部を除いた系同士の交換において、 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

[71] 既定の符号化は UTF-8 です >>3 3.。

[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 はオプションであると解釈するのが妥当でしょう。

[251] そんなことで相互運用性はいいのでしょうか。

[549] RFC 8259 はそこから更に限定して原則 UTF-8 としました。 大多数の実装が UTF-8 を選んでいるので相互運用性が達成できるのはそれしかないのだと説明されています。 >>353

[576] 非互換変更のようにも思われますが、 閉じた環境の例外があるので、従来通り UTF-16 や UTF-32 を使ってもただちに不適合とはいえませんし、 一応互換性は保たれているといえます。

[72] RFC 4627 の規定していた JSONテキストは、 最初の2文字が必ず ASCII文字となります。 そのため、最初の4つのオクテットのパターンにより、
00 00 00 xxUTF-32BE
00 xx 00 xxUTF-16BE
xx 00 00 00UTF-32LE
xx 00 xx 00UTF-16LE
xx xx xx xxUTF-8

... と区別できるsniffingとされていました。 >>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 はこれを実装しているようです。

[285] また UTF-32 はセキュリティー上好ましくないと現在では考えられています。

Web における JSON の文字コード

[70] Web においては WHATWG の Infra Standard 等に基づき原則 UTF-8 が使われます (>>388, >>450)。

[477] Webにおける文字コードも参照。

BOM

[587] 一般論としていえば、 JSON に BOM があってもなくても構いません。

[160] ECMA-404 は BOM を使っても良いかどうか明記していません。 ただし ECMA-404 は文字符号化については触れずにUnicode符号位置の列文字列について定義しているに過ぎないので、 別の層の直交する問題 (つまり JSON を利用するプロトコルその他に依存する) と解するべきだと思われます。

[88] JSON の構文上、 先頭に ZWNBSP (BOM と同じ U+FEFF) が来ることは認められていません。 従って、 BOM を使えないプロトコルや文字コードで 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 の効力が及ぶ状況も少なかろうとは思われますから、 実効的には同じともいえます。

[250] BOM が含まれていると JSON でないとしてエラーとみなす実装も認めています。 そんなことで相互運用性はいいのでしょうか。[252] ZWNBSP (BOM と同じ U+FEFF) は文字列以外で現れることはありませんから、 BOM かどうかは明確に判断できます。

[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 に置き換えられたり、 除去されたりします。 Webにおける文字コード

[343] つまり、 JSON のバイト列を受信し、文字列に変換し、 更に JSON として解釈した場合と、バイト列を HTML として解釈し、その一部分を取り出し、その文字列を JSON として解釈した場合で、含まれている U+0000 の解釈が変わってしまうことがあります。

[344] JSON ファイルへの navigate でテキストファイルのDOM構築が行われた結果を JSON として解釈する場合も、 HTML に埋め込まれた場合同様となります。

[105] JSON を HTML やテキストファイルに埋め込んで出力し、 そこから取り出して利用することは Webアプリケーションでは定石ですから、 注意が必要です。

[112] C言語のような 0x00 を文字列の終端NULL終端と見なすプラットフォームでは、 JSON との相互変換の際に取り扱いに注意が必要です。

構文解析器

[256] ECMA-404 は構文を定めるのみで、構文解析の方法は定義していません。 JSON の利用側 (例えば ECMAScript) で定義するのが適当と考えているのでしょう。

[481] JSONテキストの適合処理器conforming processorは、 適合JSONテキストでない入力を受理するべきではありませんshould not。 >>4042 2

[480] ECMA-404 版にはありませんでしたが、 版で追加されました。 >>4042 2

[484] 適合しない入力を受理しないべきというのは、 過去様々に行われてきた (そして現在も一部で行われる) JSON の独自拡張 (>>301) に、 JSON の実装が対応するべきではないということです。

[485] もちろん、 「JSON と似た JSON でないもの」 に対応することについて JSON の仕様書は何ら制限できる立場にないのですが、 それは JSON ではない何かに過ぎず、 JSON の実装と称するものが行うべきではないということです。[486] JSON と 「JSON に似たもの」の両対応で自動判別してます、 と称して形式的にこの規定を無視することはできますが、 不誠実の誹りは免れ得ないでしょう。 不具合と脆弱性の温床で、相互運用性を危険に晒すだけです。

[482] JSONテキストの適合処理器conforming processorは、 その処理する適合JSONテキストの集合を制限する意味的semanticな制約を課しても構いませんmay。 >>4042 2

[483] ECMA-404 版にはありませんでしたが、 版で追加されました。 >>4042 2

[487] ここで認められているのは意味的な制限だけであって、構文的な制限を認める規定はありません。 ということは、例えば文字列中のescapeは認めないような実装は、 適合処理器ではないということです。 想定されているのは、応用Aに特化しているので応用Aのオブジェクト形式を JSON で表現しているものにしか対応できない、という類でしょう。

[488] 現在流通している JSON の実装のほとんどは汎用ライブラリーでしょうから、 そのような制限のある単体の JSON の実装がどれだけあるか、 今後どれだけ作られるかは疑問ではあります。 応用と不可分で外形的にそのように見える実装は多々あるかもしれません。

[489] この規定が追加された版の ECMA-404 では IETF の RFC 8259 の存在が公認されています (>>461)。そして RFC 8259 は意味的な制約を定義していると ECMA-404 は述べています。 >>4042 3 この規定は RFC 8259 の独自の規定の存在を明示的に承認する意図で追加されたようです。 つまり、

  • [577] ECMA-404 = JSON、
  • [578] RFC 8259 = JSON + 独自の意味的な制約、

という整理になります。

[580] なお、受理するべきJSONテキストの長さや構造の入れ子の深さの制約は、 意味的制約というよりは構文・構造的な制約と考えられますが、 こうしたものが認められるのか明らかではない、どちらかというと認められないようにも思われます。

[581] しかし現実の実装にはそうした制約が必須です。 Web ではハードウェア制限条項によって包括的に認められていると解されます。 RFC では独自の規定があります (>>80, >>81, >>83)。

ECMAScript における JSON 構文解析

[102] ES5 の JSON.parse は、 >>79 の拡張は認めておらず、 ES5 の規定に厳密に従って構文解析しなければなりません >>36 15.12。

Web における JSON 構文解析

[582] Web では基本的に ECMAScript の構文解析法が準用されています。

IETF の RFC における JSON 構文解析

[77] RFC の定義するJSON 構文解析器parserは、 JSONテキストを他の表現に変形するものです >>3 4., RFC 7159。

[78] JSON構文解析器は、 JSON の文法に適合するすべてのテキストを受理しなければなりません >>3 4., RFC 7159。

[79] JSON構文解析器は、 JSON ではない形式や拡張を受理しても構いません >>3 4., RFC 7159。

[579] これは ECMA-404 の規定 (>>481) に合理的理由なく違反する脱法的 (>>485) 規定です。

[80] 受理するテキストのサイズを制限して構いません >>3 4., RFC 7159。

[81] 入れ子の深さを制限して構いません >>3 4., RFC 7159。

[82] 数値の範囲を制限して構いません >>3 4., RFC 7159。

[83] 文字列の長さや文字の内容を制限して構いません >>3 4., RFC 7159。

[84] これらの制限に抵触する場合にどのように処理しなければならないかは規定されていません。 また、 >>83 の文字の内容の制限というのが具体的に何を指しているかは不明確です。 特定の種類の文字から構成される文字列以外を処理できなくても構わないといったことでしょうか。

生成器

[257] ECMA-404 は JSON の構文を定義するのみで、その生成の方法は定義していません。 プログラミング言語等の概念と JSON との対応関係は JSON の定義するところではなくそれぞれで定めるべきと考えているため、 構文は定義できても、その構文に従う文字列をどのように生成するかは定義できないのでしょう。

[583] 生成の方法が規定されていないということは、 構文に一致する限り、 実装の裁量で自由な方法で生成できるということです。 例えば escape を使うか使わないかを選べますし、 字句間に空白を挿入するかしないかを選べます。 汎用ライブラリーはこうした挙動を呼び出し側に指定させることもできます。

[584] JSON の応用は、生成の方法を独自に定めることもできます。 JSON を利用する場面によっては特定の生成方法しか選べないこともあります。 例えば JSON Lines では行指向の処理のため、 改行を挿入しないことが求められます。

[85] RFC の定義する JSON 生成器generatorは、 JSONテキストを生産するものです >>3 5., RFC 7159。

[86] JSON生成器が生産するテキストは、JSON の文法に厳密に適合しなければなりません >>3 5., RFC 7159。

[318] RFC は自身の定義に違反するものを受理することを認めていますが (>>79)、 違反するものを生成することは認めていないのです。 つまり IETF の伝統であるPostelの法則です。

[103] ES5 の JSON.stringify は、 RFC ではなく ES5 の規定に従って JSON を生成しなければなりません >>36 15.12。

処理

[479] 構文解析の項も参照。

[391] 文字列から JSON を得る方法は、 ECMAScript で規定されています。 JavaScript のプログラムからは JSON.parse により呼び出せます。

[392] バイト列から JSON を得る方法は、 Infra Standard で ECMAScript を参照する形で規定されています。

[388] バイト群ぐんからJSONを構文解析こうぶんかいせきparse JSON from bytesするには、 バイト群を次のようにします。 >>387

  1. [389] テキストを、バイト群に UTF-8復号を適用した結果に設定します。
  2. [390] ?? (ES) Call (%JSONParse%, undefined, テキストのみを含むリスト) の結果を返します。
[393] UTF-8復号により BOM は除去されます。[400] UTF-8復号結果に JSON.parse を適用することを意味します。

[449] 得られる結果は JavaScript値です。

[398] 次の場面で使われます。

[399] バイト群からJSONを構文解析するもの

[450] JSONをInfra値ちに構文解析こうぶんかいせきparse JSON into Infra valuesするには、 文字列JSONテキストを、 次のようにします。 >>387

  1. [451] JavaScript値を、 ?? (ES) Call (%JSONParse%, undefined, JSONテキストのみを含むリスト) の結果に設定します。
  2. [452] JavaScript値を converting a JSON-derived JavaScript value to an Infra value した結果に設定します。

[423] JSONをバイト群に直列化serialize JSON to bytesするには、 JavaScript 値値を次のようにします >>387。

  1. [424] 文字列を、 ?? (JavaScript) Call (%JSONStringify%, undefined, ««・» 値 »«・») の結果に設定します。
  2. [425] 文字列に UTF-8符号化を適用した結果を返します。

JSON の変種

[301] JSON は単純で今後の拡張も予定されていないと明言されています。 >>4041, >>4042

[16] JSON と似ているようでどこかが違う、 いろいろな JSONの変種が「JSON」 と呼ばれていることがあります。 相互運用性やセキュリティーの障害となっており、 注意が必要です。 JSONの変種

[21] JSON の不便な点を解消した、拡張したと称するものや、 特定用途向けに改造したもの、 マーケティング目的で JSON の名前を出しているものなど、 JSON の影響を受けているのに JSON と大なり小なり違いがあるデータ形式も、 いろいろあります。 JSON や JSON を実装したライブラリー等と名前が似ていて紛らわしいものもあり、 注意が必要です。 JSONの変種

JSON ストリーム

[294] 複数の JSON 値の連続を表すJSONストリームのデータ形式も幾つか存在しています。 JSONストリーミング

JavaScript との互換性

[22] JavaScript から派生した JSON ですが、 微妙な違いがあり、取り扱いには意外と注意が必要だったりします。 JSONの変種

YAML との互換性

[18] 一部 YAML の支持者が YAML は JSON と互換性があるなどと喧伝したため、 JSON ではない YAML が JSON と呼ばれたり、 YAML を読み書きする実装が JSON に対応していると (実態に反して) 主張したりしていました。 JSONの変種

データモデル

[275] JSON には、 XML に対する XML情報集合のような厳密なデータモデルは存在しません。 JSON が、それを処理するシステムでどのようなデータ構造で表現されたり、 どのような API でアクセスされたりするかは、完全にシステム依存となっています。

[276] JSON が限られた種類の (多くのプログラミング言語に共通して存在する) 値だけを表現でき、 (多くのプログラミング言語の実装で) ネイティブなデータ構造に直接自明に変換可能なことが、 JSON の利用のしやすさにつながっており、 XML や YAML にかわって開発者に広く支持され、普及した一因でしょう。

[277] 例えば XML の場合、ほとんどの実装は要素やテキストなどに相当するオブジェクトとそれを操作する API を提供していて、プログラミング言語のネイティブのデータ構造やアプリケーション独自のデータ構造との相互変換は、 アプリケーションごとに設計し実装する必要があります。また YAML にも型などプログラミング言語によっては自明に対応付けられない機構が備わっています。

[278] 多くの実装において専用の機構が不要となっているために、 (JSON を入出力形式として採用した任意のアプリケーションのデータ構造上ではなく) 純粋な JSON のデータモデル上での操作を規定しても、 相互運用可能な形で広く普及するかどうかはわかりません。

[279] 例えば JSON Pointer のような JSON データモデル上の式言語は、 プログラミング言語ネイティブなデータ構造に変換した後だと直接適用できない、 あるいはしづらい操作が含まれているかもしれません。

バイナリー

[213] JSON にはバイナリーデータを表現する方法がありません。文字の列は文字列として表現できますが、 バイトの列を JSON に直接含めることはできません。

[214] 文字とバイトの区別が無いか曖昧な言語や環境では文字列がバイト列として使われることもありますが、 厳密にはそのような用法は JSON ではありません。

[215] バイト列その他のバイナリーデータを扱いたい時は、 MessagePack などバイナリーデータを扱えるデータ形式を使うか、 Base64 などバイト列を文字列に符号化する方法を使って JSON の文字列に埋め込むなどする必要があります。

日時

[363] JSON には日時型はありません。

[364] 文字列として ISO 8601の日時形式のいずれかを採用することや、 数値や文字列として Unix time を採用することが多いようですが、 どれが主流ということもなく、他の日時形式が使われることもあります。

JSON 内データの識別・演算

[311] JSON式言語参照。

MIME 型

[89] JSON の MIME型は application/json です >>3 6.。

[90] この他 */*+json により JSON を使った特定の応用を表すことがあります。

[320] 実際にはあまり一般的ではありません。

[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型JSON MIME typeは、次のものです >>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 に濫用されることがあります。 REST

CTE

[91] CTE としては、 UTF-8 を使う時は 8bit、 UTF-16 や UTF-32 を使う時は binary が適切です。 >>3 6.

引数

[92] 公式には application/json には引数が定義されていません。

[147] 現実には次の引数が存在します。

  • charset
  • ieee754compatible
  • odata
  • odata.metadata
  • odata.streaming

charset 引数

[93] たまに charset 引数が付けられていることがあります。 RFC などの仕様書や Web API のドキュメントの類などでも、 しばしば charset 引数が指定されています。

[125] charset が指定されていないと UTF-8 であっても正しく復号できない実装があります。

[129] 他方、引数なしの「application/json」でないと JSON が指定されたとみなさない実装もあります。

[288] REST API for MongoLab | MongoLab Documentation & Support ( 版) http://docs.mongolab.com/restapi/

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 を根拠に主張する実装もあるようです。

この解釈は RFC 2616 を誤読しています。

+json で終わる MIME 型

[367] +json で終わる MIME型
  • [98] application/jsonml+json
  • [122] application/ld+json
  • [99] application/microdata+json
  • application/vnd.hyper-item+json
  • application/vnd.elasticsearch+json

拡張子

[94] JSON の拡張子には .json >>3 6. がしばしば使われます。

Macintosh ファイル型

[95] 古い Mac OS でファイルの種類を表す符号としては TEXT が使われます >>3 6.。

素片識別子

[96] RFC では素片識別子には言及されていません。

[97] JSON では素片識別子は使われていません。

[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 コードに埋め込まれているので再利用は難しい。

応用

JSON応用

Web における JSON

JSON応用

実装

[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”は別物かもしれません。

[10] JSON の実装例

関連

XML との関係

[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 を定義しています。

[377] XML を JSON で記述する方法も幾つか提案されています。 XML/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 側に残されています。

ietf-json と ECMA-404

[194] 2013年の初め頃、 IETF において RFC 4627 を改訂して標準化過程 RFC とすることを目指す動きが起こり、 IETF JSON 作業部会working group (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 側に残されています。

[469] に郵便投票で承認されました。 >>4041

[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 されました。

  • [179] [Json] Coordinating publication of 4627bis with ECMA ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg00267.html
  • [180] charter-ietf-json-01 ( ( 版)) https://datatracker.ietf.org/doc/charter-ietf-json/
  • [181] JavaScript Object Notation (json) - Charter ( ( 版)) https://datatracker.ietf.org/wg/json/charter/
  • [182] json Discussion Archive - Thread Index ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/threads.html
  • [183] [Json] Possible next work for the WG ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg01856.html
  • [184] [Json] Authorship ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg01623.html
  • [185] [Json] JSON & ECMA ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg00222.html
  • [186] [Json] Two Documents ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg00822.html
  • [187] Re: [Json] Two Documents ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg00894.html
  • [188] [Json] 2-step proposal 4627bis + I-JSON ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg01145.html
  • [189] [Json] Consensus call: document title ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg00916.html
  • [190] [Json] What are we trying to do? ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg01087.html
  • [191] Appropriate list for JSON standardization disussion ( ( 版)) https://mail.mozilla.org/pipermail/es-discuss/2013-June/031070.html
  • [126] ( ( 版)) http://www.ietf.org/proceedings/86/slides/slides-86-json-2.pdf
  • [127] [apps-discuss] JSON mailing list and BoF ( ( 版)) http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08912.html
  • [131] Next Steps on JSON + Proposed TAG Resolution ( (Appelquist Daniel (UK) 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Oct/0029.html
  • [133] draft-ietf-json-rfc4627bis-04 - The JSON Data Interchange Format ( ( 版)) http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-04
  • [134] draft-ietf-json-rfc4627bis-06 - The JSON Data Interchange Format ( ( 版)) http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-06
  • [135] Re: XHR vs JSON, was: Next Steps on JSON + Proposed TAG Resolution ( (Bjoern Hoehrmann 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Oct/0037.html
  • [136] Re: [Json] I-JSON vs. JSON-S ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg01206.html
  • [138] Re: [Json] Comments on proposed charter for JSON ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg00193.html
  • [139] Re: Next Steps on JSON + Proposed TAG Resolution ( (Tim Bray 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Oct/0041.html
  • [140] Technical Architecture Group Teleconference -- 02 Oct 2013 ( ( 版)) http://www.w3.org/2001/tag/2013/10/02-minutes.html#item03
  • [141] tc39-notes/es6/2013-03/mar-12.md at master · rwaldron/tc39-notes ( ( 版)) https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-03/mar-12.md#49-json-ietf-changes
  • [142] tc39-notes/es6/2013-07/july-24.md at master · rwaldron/tc39-notes ( ( 版)) https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-24.md#9-json-continued
  • [143] Re: [Json] FYI ECMA, W3C, IETF coordination on JSON ( (Allen Wirfs-Brock 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Oct/0015.html
  • [144] Re: [Json] FYI ECMA, W3C, IETF coordination on JSON ( (John Cowan 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Oct/0007.html
  • [145] Re: [Json] Streaming JSON parsers ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg01090.html
  • [146] Re: [Json] Streaming JSON parsers ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg01090.html
  • [148] JSON Duplicate Keys ( ( 版)) https://mail.mozilla.org/pipermail/es-discuss/2013-June/031057.html
  • [149] JSON specification WAS: Re: JSON Duplicate Keys ( ( 版)) https://mail.mozilla.org/pipermail/es-discuss/2013-June/031063.html
  • [150] May 21, 22, 23 TC39 Meeting Notes ( ( 版)) https://mail.mozilla.org/pipermail/es-discuss/2013-June/030958.html
  • [151] JSON feedback we could submit ( (Anne van Kesteren 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Nov/0061.html
  • [152] JSON: remove gap between Ecma-404 and IETF draft ( (Anne van Kesteren 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Nov/0074.html
  • [153] Concerns from the W3C Technical Architecture Group regarding JSON ( (Philippe Le Hegaret 著, 版)) http://lists.w3.org/Archives/Public/public-ietf-w3c/2013Nov/0000.html
  • [155] Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft) ( (Tim Bray 著, 版)) http://lists.w3.org/Archives/Public/www-tag/2013Nov/0204.html
  • [156] [Json] Response to Statement from Ecma International TC39 ( ( 版)) http://www.ietf.org/mail-archive/web/json/current/msg02131.html
  • [157] TAG Teleconference -- 05 Dec 2013 ( ( 版)) http://www.w3.org/2001/tag/2013/12/05-minutes.html

[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 のまま再出版されました。

[205] この旧版 RFC 7159 は2014年3月20日の時点で Google のキャッシュに HTML 版と PDF 版が残っています。 RFC Editor のサイトでも >>204 には PDF 版がまだ残っています。イレギュラーな操作で改版してここだけ差し替えを忘れているのでしょうか。

[206] さすがに3つ目の RFC を発行することは憚られたのでしょうが、一度出版した RFC を置き換えないというポリシーを守るために日付だけ書き換えた RFC を再発行し、 日付が間違った RFC を (廃止状態とはいえ) 放置したり、 その直後にポリシーを歪めてより多くの箇所を変更した RFC を同じ番号で改版したりと、 RFC の発行手続きの運用上の大きな問題を曝け出す形になりましたが、なぜか IETF 界隈ではそれほど重大な問題として取り上げられていないようです。

[207] このような再出版に関する RFC Editor と著者の間のやり取りも個別に行われていたと見られ、 ietf-json などのメーリングリストには記録は特に残っていません。

[209] >>201 は RFC 7158 と新版 RFC 7159 の差分です。

[210] このような流れを皮肉ってか、 RFC 7159 への Errata として、 “全文を削除して「RFC 7158 参照」に置き換える”という修正案まで提案されています (>>263)。

[262] >>210 は >>208 に掲載されていたのですが、 残念なことにいつの間にか (却下ではなく) 削除されてしまいました。 なお RFC 7158 に対して報告されていた Errata 2件 (>>264、>>265) も (却下ではなく) 削除されています。現時点で残っているのは RFC 7159 に対する >>266 だけです。

[212] >>211 は RFC 4627 と新版 RFC 7159 の差分です。

  • [199] RFC 7158 - The JavaScript Object Notation (JSON) Data Interchange Format ( 版) http://tools.ietf.org/html/rfc7158
  • [200] RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format ( 版) http://tools.ietf.org/html/rfc7159
  • [201] wdiff rfc7158.txt rfc7159.txt ( 版) http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=rfc7158&url2=rfc7159
  • [204] ( 版) http://www.rfc-editor.org/pdfrfc/rfc7159.txt.pdf
    • [171] 魚拓 ( ( 版)) http://megalodon.jp/2014-0321-0110-13/www.rfc-editor.org/pdfrfc/rfc7159.txt.pdf
  • [211] wdiff rfc4627.txt rfc7159.txt ( 版) http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=rfc4627&url2=rfc7159
  • [264] [Json] [Technical Errata Reported] RFC7158 (3907) ( 版) http://www.ietf.org/mail-archive/web/json/current/msg02522.html
  • [265] [Json] [Technical Errata Reported] RFC7158 (3908) ( 版) http://www.ietf.org/mail-archive/web/json/current/msg02523.html
  • [208] RFC Errata Report ( 版) http://www.rfc-editor.org/errata_search.php?rfc=7159
  • [266] [Json] [Technical Errata Reported] RFC7159 (3915) ( 版) http://www.ietf.org/mail-archive/web/json/current/msg02546.html
  • [263] [Json] [Editorial Errata Reported] RFC7159 (3922) ( 版) http://www.ietf.org/mail-archive/web/json/current/msg02726.html
  • [168] ongoing by Tim Bray · JSON Redux AKA RFC7159 ( ( 版)) https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON
  • [170] RFC 7159 — the JSON Data Interchange Format ( ( 版)) http://rfc7159.net/

[246] なお RFC 7159 には誤って RFC 607 と RFC 3607 を参照しているというおもしろ不具合があります。

  • [314] RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format ( 版) http://tools.ietf.org/html/rfc7159

メモ

[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.

[29] リンク切れ

[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

[33] JSON の構文解析における互換性について。 RFC は非標準の拡張を理解することを認めている。 ES5 はより厳密に定義している。古い案では注釈を認めていたが、 非標準の指令の埋込みに使われるようになったため、結局認めないことになった。

[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

[32] JSON の文字符号化について。

[62] JSON の RFC はデータ型と構文上の要素と字句の関係を半ば暗黙のものとして扱っていて、 何がどう解釈されるかといったことを明確に規定していません。

[63] こういうのが、 Hixie が BNF を使わない理由の1つだよなー。

[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

[293] Draft 1: OAuth Extension for Response Data Format - Draft 1 ( 版) http://oauth.googlecode.com/svn/spec/ext/response_data_format/1.0/drafts/1/oauth_response_data_format_ext.html

'Content-Type' HTTP response header value MUST be :

Content-Type: text/json

RFC 8259 へ

[291] [Json] FYI: January 28 2015 Meeting Notes ( 版) http://www.ietf.org/mail-archive/web/json/current/msg03632.html

[296] Noggit, the JSON Streaming Parser - Solr 'n Stuff ( 版) http://yonik.com/noggit-json-parser/

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

[297] flow.io API Reference ( 版) http://flow.io/api.html

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

[302] Archive ( 版) https://mailarchive.ietf.org/arch/msg/ietf-announce/Kd_XXq_67T-iqyGOXGnVgXJbIxk

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

[334] [Json] Kicking Off JSONbis ( 版) http://www.ietf.org/mail-archive/web/json/current/msg03673.html

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

[337] Re: [Json] Kicking Off JSONbis ( 版) http://www.ietf.org/mail-archive/web/json/current/msg03693.html

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

[340] JSON Verbose Format (OData Version 3.0) · OData - the Best Way to REST ( 版) http://www.odata.org/documentation/odata-version-3-0/json-verbose-format/

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

[14] マイクロサービスのための綺麗なAPI設計 by Go Takagi | Wantedly Engineer Blog () https://www.wantedly.com/companies/wantedly/post_articles/32977

curlの場合

curl -i -H "Accept: application/json; version=0.5" -X GET http://localhost:8080/api/users

今回はversion<1.0.0だとerrorを返すようにしました。

[15] RFC 7946 - The GeoJSON Format () https://tools.ietf.org/html/rfc7946

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.

[348] encoding/json: use standard ES6 formatting for numbers during marshal (rsc著, ) https://github.com/golang/go/commit/92b3e3651dc44f54b458f171f641779f10fbaec0

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

[351] [Json] Status of 7159bis () https://www.ietf.org/mail-archive/web/json/current/msg03993.html

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

[355] XPath and XQuery Functions and Operators 3.1 () https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#json-to-xml-mapping

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.

[356] XPath and XQuery Functions and Operators 3.1 () https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#json-to-xml-mapping

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

[365] draft-wright-json-schema-hyperschema-01 - JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON () https://tools.ietf.org/html/draft-wright-json-schema-hyperschema-01

Content-Type: application/json; profile="http://example.com/alpha"

[366] Issue 17906: JSON should accept lone surrogates - Python tracker () https://bugs.python.org/issue17906

[369] Stand-Alone JSON Serialization () https://msdn.microsoft.com/en-us/library/bb412170(v=vs.110).aspx#mt154

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

[371] CircleCI API v1.1 Reference - CircleCI () https://circleci.com/docs/api/v1-reference/

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.

[372] XSL Transformations (XSLT) Version 3.0 () https://www.w3.org/TR/2017/REC-xslt-30-20170608/#json

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].

[374] XSL Transformations (XSLT) Version 3.0 () https://www.w3.org/TR/2017/REC-xslt-30-20170608/#json-to-xml-mapping

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

[402] Safari 10 の WebDriver ネイティブサポート - Qiita () https://qiita.com/hiroshitoda/items/6ee3ad892357cda3f0e0

SafariDriverサーバーの スクリーンショットを取得するWebDriver API で返ってくるBASE64データが、ChromeDriverサーバーやGeckoDriverサーバーなどと違って、スラッシュ記号がエスケープされた状態になっています。これはJSON仕様としては正しい(エスケープしてもしなくてもいい)実装で、公式クライアントライブラリーもこれに対応して正しくスクリーンショットのデータを取得できる状態になっています。

[403] Standard ECMA-404 () https://www.ecma-international.org/publications/standards/Ecma-404.htm

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

  • [325] RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format, https://www.rfc-editor.org/rfc/rfc8259.html
  • [326] RFC Errata Report » RFC Editor, https://www.rfc-editor.org/errata/rfc8259
  • [353] Diff: rfc7159.txt - rfc8259.txt, https://www.ietf.org/rfcdiff?url1=rfc7159&url2=rfc8259&difftype=--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件もあるの、一体どうなってるんですかね。 開発・出版プロセスに致命的問題があるのでは?

[328] といいたいところだけど他の RFC もこんなもんなんだよなー、 JSON 部門固有ではなく組織の体質なんでしょう。

[544] 実は旧 RFC 7159 には

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 の使い方です。

[539] 更に RFC 8259 は

を明記しています。 >>353 これは ECMA-404 新版側にあるのと同内容です (>>491)。

[542] ただし、 相互運用性の最大化のため RFC 8259 が避けることを推奨recommendするいくつかの慣習several practicesを ECMA-404 は認めているallows >>353 とし、 RFC 8259 独自の「推奨」の存在を正当化しています。

[543] ところで ECMA-404 と RFC 8259 の構文が同じもので、 RFC 8259 が一定の「推奨」をしているだけなら、 それは RFC 8259 も「認めて」いる (が推奨はしていない) のでなければなりません。 RFC 8259 が「認め」ないとは書いていませんから、 嘘ではないのですが、ミスリーディングです。

ECMA-404 の改訂

[460] に ECMA-404 の改訂版である第2版が出版されました。 >>4042

[461] IETF の RFC 8259 に合わせて出版されたもので、 第1版になかった次のような歴史の説明が追加されました。

JSON was first presented to the world at the JSON.org website 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 でもなく) 追加したのは、 政治的判断と推測するほかありません。

[538] そしてまさしく IETF 側は政治的判断だと明言しています (>>537)。

[419] OData JSON Format Version 4.01 () http://docs.oasis-open.org/odata/odata-json-format/v4.01/cs01/odata-json-format-v4.01-cs01.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

[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