*/*+json

JSON (データ形式)

[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-404JSON の開発者らによって策定され、 JavaScript と同じ標準化団体が管掌しています。


[220] それとは別に IETFRFC 8259 (旧版: RFC 7159 >>314) にもやや異なる定義があります。 ECMA-404 を参照しつつも、独自の異なる内容も含んでいます。

[290] 混乱を招きかねないので、あまり参照するべきではないでしょう。 明示的に IETFRFC が参照されている場合以外は、 これに従う必要はありません。

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

[286] ただし MIME型 application/jsonRFC 8259 (旧版: RFC 7159) で定義されています (ECMA-404 では定義されていません)

[316] RFC 7159RFC 7158 を再出版したもので、 RFC 4627 の改訂版でもあります。 RFC 8259 はそれらの改訂版です。

[324] RFC 4627 はながらく JSON の定義として参照されていましたが、 現行仕様とは異なるため、歴史的文脈以外で参照するべきではありません。


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

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

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

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


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

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

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

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

名称

[466] 名称の JSONJavaScript 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 独自の解釈です。

重複メンバー

[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ヘッダーJWKJWK集合では拒絶または 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] 逆に JavaScriptJSON.parse-0-0 と解釈しますが、 JSON.stringifyJSON.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.

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

文字列

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

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


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

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

[443] そのような JSON の実装は、一昔前ならともかく、 現在となっては致命的な不具合を抱えたものと言う他ありません。 RFC 7515 の規定する JWS のようなセキュリティーを扱う技術が、 救済措置とはいえ、致命的に壊れた実装を前提とした規定を含んでいるのは、 果たして望ましいものでしょうか。

文字の escape

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

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

[66] escape では、大文字と小文字の区別があります。 ここに示した通りに書かなければなりません。 ただし十六進数 HHHH大文字でも小文字でも構いません。 >>132, >>3 2.5.

[518] \uHHHHHHHH は、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 を参照してください。

U+2028, U+2029

[565] かつては JSON文字列リテラルにそのまま書ける U+2028 LINE SEPARATORU+2029 PARAGRAPH SEPARATORJavaScript では書けないという違いがありました。

[566] 滅多に遭遇しないのにたまに発生して不具合を発生させる発覚しにくい障害と脆弱性の温床となっていました。

[567] 頃に JavaScript 側で仕様変更があって >>564, >>563JSONJavaScript のどちらでもこれらが認められる形で解消されました。

[568] 昔と違って JSONeval で読み込むことはまずないので、 問題になることは少なくなっていましたが。 今でも便宜上オブジェクトJSON 化して HTML 中の script 要素JavaScript コード中に埋め込むようなことはあるので、 共通化にはやはり恩恵があります。

boolean

[67] truefalse の意味は >>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

構文

[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 4627JSONテキストオブジェクトまたは配列を1つ直列化したもの >>3 2. と定義しており、文字列数値truefalsenull のような値は認めていませんでした。

[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+FEFFJSON では空白ではありません

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

符号化文字集合とサロゲート

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

[520] これは JSONテキストの全体だけでなく、 JSON 構文要素の一種である文字列 (string) も、 Unicod3符号点とされています (>>236)。

[238] ところが文字列中の escape における16進数だけはなぜか Unicode ではなく ISO/IEC 10646 により解釈するとされています >>132, >>4041 9, >>4042 9

[499] そのためなのか、 ECMA-404 はなぜか The Unicode StandardISO/IEC 10646 の両方を Normative References引用しています。 >>4041 3, >>4041 2 これをどう解釈するべきかは説明されていません。 (このような問題は他の仕様書にもたまにあります。 ISO/IEC 10646 )

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

[217] ECMA-404 旧版は Unicode 6.2.0ISO/IEC 10646:2012引用していて、 仕様書には特定版を参照しているのだと明言されています。 >>4041 固定する意図は不明で、 実用上は任意のUnicodeの版と解釈して構わないでしょう。

[472] 新版は最新版の The Unicode StandardISO/IEC 10646 を参照するよう改められました。 >>4042

[229] Unicode文字ではなくUnicode符号位置ですから、 サロゲート符号点も含まれます。

[230] ES5JSON は、 BNF により SourceCharacter、すなわち UTF-1616ビット符号単位について定義していました >>36 15.12。この定義では、 サロゲートが正しく2つ連続する場合にサロゲート符号位置が2つ分と解釈されるのではなく、 文字が1つと解釈されるので、厳密には >>216 の定義と違うことになりますが、 実用上は同じと言っても構わないでしょう。

[100] RFC 4627JSON文字の列として定義されていました。 RFC 7159Unicode文字の列であるとより明確に述べています。従ってサロゲートは認められていません。 ただし ABNF 構文および escape の定義でサロゲートは除外されていません。 それらの意味は、 escape されたサロゲート2つ分として使われる場合を除き、明確に定義されていません。 RFC 7159 は実装により扱いが異なり、エラーになることもあると述べています。

[242] このサロゲートの扱いが問題となるのは、文字列の中だけです。 JSON として構文的に正しいテキストでサロゲートを含み得るのは文字列だけです。
[476] Encoding Standard によれば utf-8utf-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 が認めた「唯一の方法」ではありません。 相互運用性は無いものと思うしかありません。


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

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

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

文字符号化方式

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

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

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

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

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

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

[546] RFC 8259 に従う JSONテキストは、 閉じた生態系 (closed ecosystem) の内部を除いた同士の交換において、 RFC 3629 UTF-8符号化しなければなりません>>353

[548] 「閉じた生態系」かどうかの判定基準は示されていないので、 この規定がどのような状況で適用され、どのような状況で適用されないのかは、 明らかにし難い場合もあります。

[552] IETF が規定するプロトコルでその RFCRFC 8259 を参照するようなものは、 「IETF の公開プロトコル」 という閉じていない生態系に属するものですから、 この規定が適用され、 UTF-8 を使わなければならないと解釈するのが妥当でしょう。

[553] 特定のウェブサーバーが出力し、それと対応関係にある特定のクライアントJavaScript プログラムだけが処理するような JSON データは、 たとえそれが IETF の定義する application/json MIME型でラベル付けされていようとも、 閉じた生態系に属するものと解して良さそうに思われます。 その場合 UTF-8 を使おうが使うまいが、 特定少数の開発者間の意思決定だけで相互運用性は確保できます。

[87] RFC 4627 では、 Unicode符号化しなければならない >>3 3. とされていました。 UTF-8UTF-16UTF-32 を使って構わないという記述はありましたが >>3 6.、 それ以外を使ってはいけないとは明確に規定されていませんでした。

[547] RFC 7159 では更に制約され、 UTF-8UTF-16UTF-32 で符号化しなければならないとされていました。 >>353

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

[550] RFC 4627 ではこの「既定」 が何を表すのかは明記されていませんでした。特に意図がなければ UTF-8 を使うべきであるということとも、文字符号化方式が特定できないときに UTF-8 として解釈するべきということとも解釈できましたし、それ以外の解釈もあり得ました。

[551] RFC 7159 では、 UTF-16UTF-32 に対応していない実装があり、 UTF-8 が最も相互運用性が高いという記述が追加されました。

[75] 実装はこれらの符号化方式のいずれ、あるいはすべてに対応しなければならないのか、 しなくてもよいのか、といったことは RFC 4627 ではまったく規定されておらず、 RFC 7159 でも明記はされていませんが、 UTF-8 は実装しなければならず、 UTF-16UTF-32 はオプションであると解釈するのが妥当でしょう。

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

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

[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

... と区別できるとされていました。 >>3 3. xx00 以外のオクテットを表すのでしょう。 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 においては WHATWGInfra Standard 等に基づき原則 UTF-8 が使われます (>>388, >>450)。

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

BOM

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

[88] JSON の構文上、 先頭に ZWNBSP (BOM と同じ U+FEFF) が来ることは認められていません。 従って、 BOM を使えないプロトコル文字コードで使ってしまった場合、 JSON としては構文エラーになります。

[74] RFC 4627BOM について言及していませんでした。 BOM がある場合は >>72 のパターンに当てはまらず、 UTF-16UTF-32 であっても UTF-8 と判定されてしまいます。ただし RFC のこの部分は単なる事実の記述であって、そう解釈しなければならないなどと規定されているわけではなく、 また明確に BOM を使用してはならないと規定されているわけでもありませんから、 どう理解するべきか難しいところです。RFC 4627 の改訂にあたっても BOM が認められているかどうかは議論になっていました。

[159] RFC 7159JSON を生成するときに BOM を含めてはならずJSON を解釈するときに BOM を無視しても構わないとしています。

[554] RFC 8259 は、「ネットワーク転送される」 JSONテキストのみにと当該規定の対象を限定しました。 >>353 その意図は不明です。もっとも、そもそもネットワーク転送されない JSONテキストRFC 8259 の効力が及ぶ状況も少なかろうとは思われますから、 実効的には同じともいえます。

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

[161] かつて XHRJSON の解釈の際に BOM があれば無視するよう規定していました。

[317] >>74 の通り RFC 4627BOM の扱いが明記されていなかったことから、 XHRJSON変種を規定しているとみなす人もいました。

[26] しかし、 その程度で変種と判定されるとなると、 UTF-8JSONUTF-16JSON は異なることになってしまいます。 「異なる JSON の利用方法がある」ならまだしも、 「JSON の異なる定義がある」と解するのは無茶でしょう。

[478] 現在の XMLHttpRequest StandardWebプラットフォームの共通の定義を参照するのみで、 独自の規定を持っていません。 (想定される挙動は同じで、 BOM はあってもなくても構いません。)

文字 NULL

[341] JSON の構文上は U+0000 NULL 文字は認められていません。どう処理するべきかは JSON 本体仕様は規定していないので、 実装依存ということになります。

[342] HTMLCSS のような Web の各種言語に U+0000 が含まれていると、(文脈に依存して) U+FFFD に置き換えられたり、 除去されたりします。 Webにおける文字コード

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

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

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

[112] C言語のような 0x00文字列の終端と見なすプラットフォームでは、 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 では IETFRFC 8259 の存在が公認されています (>>461)。そして RFC 8259 は意味的な制約を定義していると ECMA-404 は述べています。 >>4042 3 この規定は RFC 8259 の独自の規定の存在を明示的に承認する意図で追加されたようです。

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

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

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

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

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

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

ECMAScript における JSON 構文解析

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

生成器

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

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

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

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

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

処理

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

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


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

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

  1. [389] テキストを、バイト群UTF-8復号を適用した結果に設定します。
  2. [390] ? 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値を、 ? 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] 文字列を、 ? Call (%JSONStringify%, undefined, « ») の結果に設定します。
  2. [425] 文字列UTF-8符号化を適用した結果を返します。

JSON の変種

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

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

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

JSON ストリーム

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

JavaScript との互換性

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

YAML との互換性

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

データモデル

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

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

[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] JSONMIME型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] JSONPJavaScript なので、 text/javascript を使うのが正しいですが、 JSONMIME型になっていることもあります。

[319] LDJSON / JSON Lines の類は JSON そのものではないので、 それぞれに適切な MIME型を使うべきですが、 application/json が使われることもあります。 application/orchestrate-export-stream+json のように空白区切りの JSON+json が使われることもあります。

[562] Web APIversioning に濫用されることがあります。 REST

CTE

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

引数

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

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

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 のように charsetapplication/json にも適用されると HTTP を根拠に主張する実装もあるようです。

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

+json で終わる MIME 型

[367] +json で終わる MIME型

拡張子

[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] PerlJSON を扱うモジュールは多数あります。 Perl には boolean context はありますが、データ型としての boolean は存在していません。 JSONbooleanPerlSV1/0 に対応付けたり、 1/0scalar reference に対応付けたり、 モジュール独自のオブジェクトとして表現したりと、 モジュールごとに様々な表現方法が採られています。

[281] PerlデータJSONデータの関係が規定されていない以上、 どの実装が正しいとも誤りだとも言えません。どの実装がより便利かという議論はもちろん可能です。

[282] 同じ Perl という言語を使っていても、あるモジュールJSON に変換したデータを別のモジュールPerl に変換した結果、 元のデータに戻るとは限りません。この意味で、あるモジュールが実装する“JSON” と別のモジュールが実装する“JSON”は別物かもしれません。

[10] JSON の実装例

関連

XML との関係

[172] JSONXML とは構文的にもデータモデル的にも全く互換性も歴史的関係もありませんが、 しばしば対比して語られます。 XML は90年代末から00年代中頃にかけて、 文書データの両方の記述形式の大本命としてもてはやされていました。ところが JSON の登場により、データの情報交換形式として多くの場面で XML より JSON の方がより勘弁で扱い易いと認識されるようになりました。 JSON は元々 JavaScriptリテラルから派生したものですから、多くの近代的なプログラミング言語におけるオブジェクトとも自明な対応関係が存在しており、 多くのプログラマー達には XML よりも JSON の方が理解しやすいという性質もありました。

[173] Webアプリケーションのサーバーが提供する Web API のデータ形式としては、かつては (XMLHttpRequest というインターフェイス名に象徴されるように) XML を用いるのが最善策であると考えられていた時期もありましたが、現在では専ら JSON が用いられています。10年代の最初期には (AtomRSS を含め) XML ベースの形式と JSON の両方を提供する Web API も少なくありませんでしたが、10年代中頃には後方互換性のために必要な場合を除き、 XML ベースの Web API は見られなくなっています。

[174] アプリケーションの設定ファイルの類の記述形式としても、 XML (や YAML その他の独自形式) から JSON へのシフトが同時期に起こっています。 例えば Widgets 1.0XML 形式の設定ファイルを使っていますが、 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 (WSDLAtomPub) などが提案されています。


[376] WCFMapping Between JSON and XML を使っています。

[373] XSLT 3.0XML Representation of JSON を定義しています。


[377] XMLJSON で記述する方法も幾つか提案されています。 XML/JSON を参照。

歴史

[321] JSONJSON.org で発表されたとされます。 >>4041, >>4042

[322] IETFRFC 4627 として標準化されました。 >>3

[104] ES5 は、 RFC 4627 を引用しつつも独自に構文や解釈を規定しています。

[323] WebブラウザーES5 を実装しており、現在ではこちらが JSON の定義として参照されるべきものでしょう。

[163] その後 ECMA-404 が出版されました。 ES6ECMA-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 Brayietf-json 側の関係者は JSON の標準化を行っているのは ietf-json であって TC 39 では無い、 TC 39 とは協力関係にあったはずなのに連絡もなかったなどと非難しますが、 TC 39 側はほとんど相手にしていません。互いの仕様の不備を主張し合うなど、両者の溝は埋まりません。 そこへ一見無関係な W3CTAG も乱入してきて、 RFC の改訂版は ECMA-404 の定義を参照するべきとするコメントを IETF 側に送付するなど、ちょっとした騒ぎになりました。

[198] 結局 RFC の改訂版は ECMA-404 を参照していますが、違いを説明するために引用しているに過ぎず、 独自に JSON を定義しています。ただし JSON 全体はオブジェクト配列だけでなく、 任意の値となるよう拡張されました (ECMA-404 と同等になりました。 >>47>>101 を参照。) その他にも旧 RFCECMA-404 にない規定が追加されています。更に JSON の拡張や部分集合を定義することが引き続き ietf-json で検討されています。 こうして IETF によって JSONfork されました。

[202] Tim Brayietf-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] >>201RFC 7158 と新版 RFC 7159 の差分です。

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

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

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

[246] なお RFC 7159 には誤って RFC 607RFC 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

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

[63] こういうのが、 HixieBNF を使わない理由の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 の改訂版である 7159bisWG に何の断りもなく (未解決の問題もあるのに) 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

[408] >>405 STD に進めることが目的の改訂だったはずなのに、 その肝心の STD 番号を書き忘れるとか、 相変わらず JSONRFC は不遇だな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 7159RFC 8259 もまったくの新文書ではなく旧版からの改訂ですし、 それぞれの出版前に何度も I-D を公開して改訂を続けています。 その過程で著者らはもちろん、 WGIESGRFC Editor と膨大な数の人々が何度も繰り返しチェックしています。

それだけの体制で、この程度の長さの文書で2件も誤りがあるのは多すぎます。 それを「少数」だと反省の色を見せない RFC 7159 もちょっとどうかと思うのですが、 それを踏襲した RFC 8259 が 2 + 4 件あってもまだ「少数」 だと言い張っているのは図々しい。

そんな編集態度だから、 RFC 8259 にも「少数」の誤りが報告されたのは必然という他ありません。

[545] 次の RFC では 2 + 4 + 6 件で「少数」と言い張るのをみたいですねw

でも現時点で報告済5件、却下1件なので、これ以上増えるのは難しいかなあ


[534] 旧版 RFC 7159 は、 Informative References として ES5.1ECMA-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 8259ECMA-404 の用語「JSON text」 の定義に不整合がないことを協調するためのものであるというのです。

[537] これはなかなか独創的な normative reference の使い方です。

[539] 更に RFC 8259

  • [540] 両者の JSON 文法は同じで、説明の方法が違うのみであること
  • [541] 両者に違いが見つかった場合には、双方協力して解決を目指すこと

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

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

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

ECMA-404 の改訂

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

[461] IETFRFC 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] IETFRFC による定義が存在することを認めています。 (第1版は JSON.org の部分しか書いていませんでした。 >>4041)

[463] その上で、 RFC 4627ES5ECMA-404 によって置き換えられたという ECMA 側の認識を表明しています。

[464] また、 ECMA-404RFC 8259 が規定する JSON 構文は同等 (identical) を意図 (intended) しているとの見解を表明しています。

[491] 新版は旧版と違って Normative ReferencesRFC 8259 を挙げています。そして、

  • [492] 両者の JSON 文法は同じで、形式化の方法が違うのみであること
  • [493] 両者に違いが見つかった場合には、双方協力して解決を目指すこと

を述べています。 >>4042 3 (RFC 8259 側にも同じことが書かれています。 >>539)

[494] RFC 8259 が「同等」の構文以外に独特の内容を多く含んでいることについては、

としています。 >>4042

[465] ECMAIETF を完全に無視しても良かったはずですが、 歩み寄りの姿勢を見せています。 そして双方協力関係を保ち両仕様書の内容を同期させる、 との合意事項を明文化して示しています。

[497] ただし ECMAIETF の独自規定は存在に言及するにとどめ、 それを採用するまでには至っていません。 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