+json

JSON (データ形式)

[31] JSON (ジェイソン) (JavaScript Object Notation / JavaScript オブジェクト記法) は、 JavaScript におけるオブジェクト・リテラル部分集合によってオブジェクト配列を表記するデータ交換書式です。 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] 現在 JSONECMA-404 によって定義されています。

[315] 以前は ES5 に定義が含まれていましたが、 ES6ECMA-404 を参照する形になっています。

[220] それとは別に RFC 7159 にもやや異なる定義があります。 ECMA-404 を参照しつつも、独自の異なる内容も含んでいます。 混乱を招きかねないので、あまり参照するべきではないでしょう。 ただし MIME型 application/jsonRFC 7159 で定義されています (ECMA-404 では定義されていません)。

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

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

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

JSON 値

[37] 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] オブジェクトとその名前や値の解釈は仕様上定義されていません。 JavaScript ではオブジェクトに、 Perl ではハッシュ参照に対応付けられるなど、言語と環境により異なります。 また JSON を利用するプロトコルWeb API などがそれぞれで認められる名前の種類と解釈を定めていたりします。

メンバーの順序

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

[418] 極めて稀に、実装が独自に順序に意味を持たせている場合があるようです。 しかし多くの実装はそれを想定した JSON を出力できず、 相互運用性の問題があります。

重複メンバー

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

[49] RFC ではオブジェクト内で名前は固有であるべき >>3 2.2., RFC 7159 とされていますが、 ECMA-404 ではそのような制限はありません。 ECMAScript 仕様書で定義される JSON から JavaScript への変換では、 同名のメンバーのうち最後のものが JavaScript オブジェクトに反映されます。

[223] 同名のメンバーに対する処理が定義されていないため、実装によりどの値を選択するかが異なり、 セキュリティー上問題となる危険性もあります。

[247] RFC 7159 の追加部分によると、重複の内最後を選択する実装の他、エラーとなる実装やすべてを返す実装もあるようです。

[224] しばしば注釈として他の正規のメンバーと衝突しない名前を採用する慣習が一部にあり、 同名のメンバーがあってもエラーにはならないことを仮定して複数の同名のメンバーによって複数の注釈を表すことがあるようです。

[287] OAuth 2.0 は重複した指定を禁止しているようです。

配列

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

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

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

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

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

[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

[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 数を使うと相互運用性の問題が生じるかもしれません。

[284] 64ビット整数を扱える環境で出力した数値は、 JavaScript の数値に変換される際に浮動小数点数に変換され、元の値と近くても異なる値に変わってしまうことがあるので、注意が必要です。

[57] 無限大NaNは表現できません。 >>132, >>3 2.4.

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

文字列

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

[236] ただしここでいう文字は、厳密には Unicode符号位置であり、以降でも同様です。 これについては >>216 を参照してください。

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

[59] 文字 (厳密には符号位置) は escape により表現することができます。特に ", \, U+0000 - U+001F については必ず escape しなければなりません。 >>132, >>3 2.5.

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

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

[66] escape 内の大文字小文字は一般に区別されます。 しかし十六進数大文字でも小文字でも構いません。 >>132, >>3 2.5.

[60] U+10000 以上文字UTF-16 サロゲート・ペアの2つの16ビット符号単位の列によって escape で表せます。 >>132, >>3 2.5.

[238] 16進数はなぜか Unicode ではなく ISO/IEC 10646:2012 により解釈する >>132 とされています。しかし実用上は Unicode の任意の版と理解して構わないでしょう。

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

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

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

[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 を利用するプロトコル等によっては、文字の数やどのような文字列が認められるかに制限があるかもしれません。

boolean

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

null

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

構文

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

[47] RFC 4627JSONテキストオブジェクトまたは配列を1つ直列化したもの >>3 2. と定義しており、文字列数値truefalsenull のような値は認めていませんでした。 これは RFC 7159 で改められていて、現在では RFC でも >>101 の定義に揃えられています。 IETF の立場からはこれは厳密には非互換変更になります。

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

字句解析

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

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

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

[216] JSONテキストは、Unicode符号位置の列として定義されています >>132

[217] ECMA-404Unicode 6.2.0 を引用していますが、実用上は任意の版の Unicode Standard と解釈して構わないでしょう。

[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 として構文的に正しいテキストでサロゲートを含み得るのは文字列だけです。

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

文字符号化方式

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

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

[71] 既定符号化UTF-8 です >>3 3.RFC 4627 ではこの「既定」 が何を表すのかは明記されていませんでした。特に意図がなければ UTF-8 を使うべきであるということとも、文字符号化方式が特定できないときに UTF-8 として解釈するべきということとも解釈できましたし、それ以外の解釈もあり得ました。 RFC 7159 では UTF-16UTF-32 に対応していない実装があり、 UTF-8 が最も相互運用性が高いという記述が追加されています。

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

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

Sniffing

[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セキュリティー上好ましくないと現在では考えられています。

BOM

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

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

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

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

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

[317] >>74 の通り RFC 4627BOM の扱いが明記されていなかったことから、 XHRJSON の変種を規定しているとみなす人もいます。 しかし UTF-8JSONUTF-16JSON は異なると主張するようなものですから、 「異なる JSON の処理方法がある」ならまだしも、 「JSON の異なる定義がある」と解するのは無茶でしょう。

NULL

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

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

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

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

構文解析器

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

[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 の文字の内容の制限というのが具体的に何を指しているかは不明確です。 特定の種類の文字から構成される文字列以外を処理できなくても構わないといったことでしょうか。

[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

処理

[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%未定義テキストのみを含むリストに適用した結果を返します。
[393] UTF-8復号により BOM は除去されます。
[400] UTF-8復号結果に JSON.parse を適用することを意味します。

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

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

JSON の変種

[258] RFC が拡張された JSON に対応することを認めていることもあり、また JSON が広い分野で用いられていることもあり、いろいろな JSON の変種が「JSON」 と呼ばれていることがあります。

[267] JSON と互換性のあるもの、ないもの、 JSON 自体で表現できないデータモデルを JSON として表現する方法を定義するもの、 JSON に触発されただけで実際には JSON と関係性が薄いもの、JSONプロファイルも含め、次のような名前がついた JSON の派生仕様が存在しています。

[286] CBORJSON データモデルとの互換性を大きな特徴として挙げています。

[268] いずれも JSON ほどの支持は集められておらず、提案段階にとどまっているか、 特定の実装にだけ採用されているものです。

[21] MessagePackJSON の派生仕様ではなく互換性はありませんが、 「It's like JSON. but fast and small.」と謳っています。各言語のライブラリーが存在し、 それなりに広く利用されているようですが、 JSON ほどとは言えなそうですし、 対象分野も必ずしも近いとは言えなそうです。少なくても Web API 等の疎結合API を通じた情報交換目的で MessagePackJSON と競合しているようには見えません。

JSON ストリーム

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

[292] バリエーションについても各項を参照。

[301] i3bar は、無限に長い (閉じない) 配列を使っています >>300

[300] i3: i3bar input protocol ( 版) <http://i3wm.org/docs/i3bar-protocol.html>

What follows is an infinite array (so it should be parsed by a streaming JSON parser, but as described above you can go for a simpler solution), whose elements are one array per status line.

JavaScript との互換性

[105] JavaScript文字列リテラルでは U+2028U+2029 を直接記述することは認められていませんが、 JSON では認められています >>36 15.12.2

[119] >>27 より

One of the problems is that U+2028 and U+2029 are valid characters inside JSON strings, but are not allowed in ECMAscript string literals

Another problem is that some javascript implementations reserve some property names for their own purposes (which probably makes them non-ECMAscript-compliant). For example, Iceweasel reserves the __proto__ property name for it's own purposes.

[118] また、 __proto__ のように JavaScript 自体の持つ機能の名前と衝突した場合に、 JSON を直接 JavaScript と解釈すると問題が起こり得ることも指摘されています (>>119)。

[120] このような JavaScript との非互換性は、 JSON オブジェクトのような正規の実装に依らず、 eval などで JavaScript 文字列として解釈する際に発症します。しかも通常は U+2028 などは使わない文字なので気づきにくく、時にサービス拒否攻撃のように悪用されることもあります。

[121] また、 JSON関数で括った“だけ”であるはずの JSONP も、 (JavaScript と解釈されるのが目的のものですから、 JavaScript コードであることになり、) 実は JSON とは非互換であることになります。

YAML との互換性

[176] Perl コミュニティーの一部など、 JSON 以前に YAML が広く用いられていた人達の中には、 JSONYAML部分集合であるとして、 YAML の実装を元にした JSON の実装が行われていました。

[26] しかし JSONYAML部分集合であるとの主張はとされています >>177

[70] 一部の人は真剣に YAML部分集合であると主張しているようですが、 周囲からは冷ややかな目で見られています。また JSON 関係者からは相手にされていないようです。

[178] このため JSON であると称しながら実際には JSON ではない YAML のデータが存在しています。

データモデル

[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] 実際にはあまり一般的ではありません。

[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 が使われることもあります。

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 は独自に素片識別子を規定しています。

歴史

[104] ES5 は、 RFC を引用しつつも独自に構文や解釈を規定しています。 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 側に残されています。

[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 を参照しているというおもしろ不具合があります。

実装

[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 の実装例

Web における JSON

[321] JavaScriptJSONJavaScript データ構造の相互変換のための JSON オブジェクトなどの API を提供しています。

[322] application/json への navigate では、 テキストファイルとして扱われるのが普通です。 ただしこの動作は現時点で標準化されていない事実上の標準状態です。

[323] JSON を単なるテキストではなく、整形して表示するブラウザー拡張もあり、 Web開発者には好評です。

[324] 開発者ツールでは fetch の記録などの画面で JSON を単なるテキストではなく、整形して表示する機能が備わっていることがあります。

[325] DnD 処理ではマイクロデータJSON 形式で表現する仕様がありますが、 実装されていないようです。

[326] Web App Manifestブラウザー拡張の定義ファイルなどでは JSON 形式が使われています。

[327] report-uri への報告や OAuth 2.0 の一部の処理などでは JSON 形式が使われています。

[328] WebアプリケーションAPI などでは、00年代後半から XML にかわる標準的なデータ形式として広く採用されています。

応用

[298] JSON は色々な形で使われています。

[353] 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 を参照。

メモ

[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

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