[31] [DFN[[RUBY[[[JSON]]][ジェイソン]]]]
は、 [[JavaScript]] における[[オブジェクト・リテラル]]の[[部分集合]]によって[[オブジェクト]]や[[配列]]を表記する[[データ交換書式]]です。
[25]
[[JavaScript]] を始め数多くの[[言語][プログラミング言語]]で[[ライブラリー]]が整備されており、
汎用的な[[データ構造]]の交換[[形式][データ形式]]の[[事実上の標準]]として広く用いられています。
[FIG(quote)[
[FIGCAPTION[
[30] [CITE@en[JSON]] ([TIME[2011-07-09 12:55:13 +09:00]] 版)
]FIGCAPTION]
>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.
]FIG]
* 仕様書
[219] 現在 [[JSON]] は[TIME[平成29(2017)年12月][2017-12]]制定の
[DFN[[[ECMA-404]]]] 第2版 [SRC[>>4042]] によって定義されています。
[HISTORY[
[268]
その前は[TIME[平成25(2013)年10月][2013-10]]制定の
[[ECMA-404]]
第1版 [SRC[>>4041]]
によって定義されていました。
[315] それ以前は [[ES5]] に定義が含まれていました。
[[ES6]] とそれ以降は [[ECMA-404]] を参照する形になっています。
[454]
[[ECMA-404]]
は
[[JSON]]
の開発者らによって策定され、
[[JavaScript]] と同じ[[標準化団体]]が管掌しています。
]HISTORY]
[REFS[
- [132] '''[CITE[Standard ECMA-404]] ([TIME[2013-10-09 12:19:30 +09:00]] 版) '''
--
[4041]
[CITE[[[ECMA-404]], 1st edition, October 2013 - ECMA-404_1st_edition_october_2013.pdf]], [TIME[2022-02-04T10:37:07.000Z]], [TIME[2022-09-03T11:31:03.399Z]]
--
[4042]
[CITE[[[ECMA-404]], 2nd edition, December 2017 - ECMA-404_2nd_edition_december_2017.pdf]], [TIME[2022-02-04T10:38:33.000Z]], [TIME[2022-09-03T11:31:20.311Z]]
]REFS]
-*-*-
[220] それとは別に [[IETF]] の [[RFC 8259]] (旧版: [[RFC 7159]] [SRC[>>314]])
にもやや異なる定義があります。
[[ECMA-404]] を参照しつつも、独自の異なる内容も含んでいます。
[290]
混乱を招きかねないので、あまり参照するべきではないでしょう。
明示的に [[IETF]] の [[RFC]] が参照されている場合以外は、
これに従う必要はありません。
;; [490] [[ECMA-404]] 側からの見解: >>461
[286]
ただし [[MIME型]] [CODE(MIME)@en[[[application/json]]]] は
[[RFC 8259]] (旧版: [[RFC 7159]])
で定義されています [WEAK[([[ECMA-404]] では定義されていません)]]。
[HISTORY[
[316] [[RFC 7159]] は [[RFC 7158]]
を再出版したもので、 [[RFC 4627]] の改訂版でもあります。
[[RFC 8259]] はそれらの改訂版です。
[324]
[[RFC 4627]] はながらく [[JSON]] の定義として参照されていましたが、
現行仕様とは異なるため、歴史的文脈以外で参照するべきではありません。
]HISTORY]
-*-*-
[295]
[[ECMA-404]]
はいろいろな[[プログラミング言語]]や[[応用]]での利用を想定して、
許容範囲を広く若干の曖昧性を持たせて規定されています。
それは[[プログラミング言語]]等各[[プラットフォーム]]はそれぞれ異なる[[データモデル]]を持っているのですから、
特定の利用方法に限定するよりは、一般化された構文を定めるだけで、
あとは各[[応用]]に委ねるべきという考えに依るものです。
;;
[440]
無数の利用方法をすべて1つの[[仕様書]]にまとめるのも不可能ですし、
1つでも規定してしまうとその解釈に他が引きづられてしまうからよくないという判断なのでしょう。
;; [471]
このような[[仕様書]]の設計は意図的なもので、
しかも仕様の開発者にかなり重視されているようです。
[TIME[西暦2013年][2013]]版も既に前文でそのような説明をしていますが、
[TIME[西暦2017年][2017]]版はそれに加えて本文 [CSECTION[1 Scope]]
で構文だけを定め、意味や処理は他に任せると明記しています。
[SRC[>>132]]
[470] これは多様な環境と前提の[[応用]]との相互変換の便宜を図るためではあるのですが、
その曖昧性が[[相互運用性]]を脅かすきらいもあります。
そのためもあって、
[[JSON]] は [[JavaScript]] から派生したものですから、
[CITE[[[ECMAScript]]]]
仕様書に規定された [CODE[JSON]] [[オブジェクト]]で用いられる
[[JSON]] と [[JavaScript]] [[オブジェクト]]との相互変換の規定が、
事実上の[[参照実装]]に相当するものと考えられています。
[[JSON]] と[[プログラミング言語]]等との対応関係で迷う所があれば、
[CITE[[[ECMAScript]]]]
における規定と整合する形を取るのが好ましいでしょう。
[441]
なお、
[[JSON]]
の最も一般的な利用形態の1つであろう
[[Webプラットフォーム]]での取り扱いについては、
[CITE[Infra Standard]]
[SRC[>>387]]
等に規定があります。
[CITE[Infra Standard]]
は
[[ECMAScript]]
の規定をベースに
[[Webプラットフォーム]]の[[データモデル]]との相互変換処理を定めています。
[[Web]] で [[JSON]] を使うときは、その[[規定]]と整合した形とするのが望ましいでしょう。
[REFS[
- [331] [CITE@en-GB-x-hixie[HTML Standard]] ([TIME[2015-09-30 22:54:01 +09:00]] 版)
- [387] [CITE@en[Infra Standard]] ([TIME[2017-10-03 21:36:23 +09:00]])
]REFS]
-*-*-
[117]
以上より、特に事情がないとき [[JSON]] の仕様として参照するべきなのは、
- [CITE[ECMA-404]] 第2版 [SRC[>>4042]]
- [CITE[ECMAScript]] の最新版の [CODE[JSON][JSON object]] および関連する[[規定]]
- [CITE[Infra Standard]] の最新版の [[JSON]] 関連の[[規定]] [SRC[>>387]]
... ということになります。
[HISTORY[
[221] [[json.org]] にも定義が掲載されていますが、現在ではこれは仕様ではなく、半公式の解説と理解するべきでしょう。
]HISTORY]
[222] 以降の各項目では [[ECMA-404]] での定義に加えて、各仕様での歴史的な定義についても触れます。
全体としての経緯は歴史の項を参照してください。
* 名称
[466]
名称の [[JSON]] は
[DFN[JavaScript Object Notation]] [SRC[>>4041, >>4042]]
([DFN[[RUBY[JavaScript][ジャバスクリプト]] オブジェクト[RUBY[記][き]][RUBY[法][ほう]]]])
を略したものです。
[[JavaScript]] の構文から派生した歴史を物語っています。
[467]
[[発音]]は
/ˈdʒeɪ·sən/
で、
[CITE[Jason and The Argonauts]]
[WEAK[(日本語版: [CITE[アルゴ探検隊の大冒険]])]]
の
「Jason」
と同じと説明されています。
[SRC[>>4042]]
[REFS[
-
[468]
[CITE@en-us[Amazon.co.jp: [[Jason & the Argonauts]] / '''['''Blu-ray''']''' [Import] : DVD]], [TIME[2022-09-03T13:14:36.000Z]]
]REFS]
* JSON 値
[37]
[[JSON]] における単位となるモノは[RUBY[[[値]]][あたい][value]]と呼ばれます。
[DFN[[RUBYB[[RUBY[JSON][じぇいそん]][RUBY[値][ち]]][JSON value]]]] には次の種類があります [SRC[>>132, >>3 1.]]。
- [38] [RUBYB[[[プリミティブ型]]]@en[primitive types]]
-- [39] [RUBYB[[[文字列]]]@en[string]]
-- [40] [RUBYB[[[数値]]]@en[number]]
-- [41] [[boolean]] - [[true]], [[false]]
-- [42] [[null]]
- [43] [RUBYB[[[構造化型]]]@en[structured types]]
-- [44] [RUBYB[[[オブジェクト]]]@en[object]]
-- [45] [RUBYB[[[配列]]]@en[array]]
[FIG(railroad)[
= *
== 空白
= |
== [[文字列]]
== [[数値]]
== [CODE[[[true]]]]
== [CODE[[[false]]]]
== [CODE[[[null]]]]
== [[オブジェクト]]
== [[配列]]
= *
== 空白
]FIG]
** オブジェクト
[48] [[オブジェクト]]は、 [CODE(char)[[['''{''']]]] の後に0個[[以上]]の[RUBYB[[[メンバー]]]@en[member]]を
[CODE(char)[[[,]]]] で区切って並べ、最後に [CODE(char)[[['''}''']]]] が来る文字列として表されます。
[SRC[>>132, >>3 2.2.]]
[FIG(railroad)[
= [CODE[[[{]]]]
= ?
== メンバー
== *
=== [CODE[[[,]]]]
=== メンバー
= [CODE[[[}]]]]
]FIG]
[52] 最後の[[メンバー]]の後に [CODE(char)[[[,]]]] を入れることは認められていません。
;; [244] [[JSON]] の派生元である [[ES3]] がこれを認めておらず、当時の [[IE]] も対応していなかったためです。
[273] メンバーは、名前と値の組であり、[[文字列]]の後に [CODE(char)[[[:]]]] が来て、
その後に値が来ます。 [SRC[>>132, >>3 2.2.]]
[FIG(railroad)[
= *
== 空白
= [[文字列]]
= *
== 空白
= [CODE[[[:]]]]
= *
== 空白
= [[JSON値]]
]FIG]
[226] [[メンバー]]の個数に制約はありません。
-*-*-
[225] [[オブジェクト]]とその[[名前]]や値の解釈は仕様上定義されていません。
[[応用]]に依ります。
[SRC[>>4042 6]]
[HISTORY[
[501] このことは [[ECMA-404]] 旧版 [SRC[>>4041]] は明言していませんでした。
]HISTORY]
[500]
[[JavaScript]]
では[[オブジェクト]]に、 [[Perl]] では[[ハッシュ参照]]に対応付けられるなど、[[言語]]と環境により異なります。
また [[JSON]] を利用する[[プロトコル]]や [[Web API]] などがそれぞれで認められる名前の種類と解釈を定めていたりします。
[444]
[[仕様書]]によれば、
[[オブジェクト]]は[[プログラミング言語]]で[RUBYB[[[記録]]][record]]、
[RUBYB[[[構造体]]][struct]]、
[RUBYB[[[辞書]]][dict]]、
[RUBYB[[[写像]]][map]]、
[RUBYB[[[ハッシュ]]][hash]]、
[RUBYB[[[オブジェクト]]][object]]のように呼ばれている構造に相当するものと説明されています
[SRC[>>132]]。
多くの[[プログラミング言語]]はこうした構造がありますが、
複数あることもありますし、
1つもないこともあるかもしれません。
どれにどのような形で対応付けるかは、各[[応用]]に委ねられています。
[EG[
[445]
[[JavaScript]]
では
[CODE[Object]]
が最も近いですが、他に
[CODE[Map]]
も似た構造を持っています。
一般的には
[CODE[Object]]
だけを
[[JSONオブジェクト]]に直接相当するものとします。
]EG]
[446]
[[JSONオブジェクト]]のことを map や hash と呼ぶ人もいるようですが、
混乱の元で不適切です。
*** メンバーの順序
[227] [[メンバー]]の順序に意味はあるかどうかは仕様上定められていません。
[165]
[[ECMA-404]] の第1版は特に言及していませんでした。
[[ECMA-404]] の第2版は、順序に意味は与えないとし、
[[応用]]に依存するとしています。
[SRC[>>132]]
;; [176] この条項の解釈に当っては、[[配列]]の規定との比較が必要です。
[[ECMA-404]] の第1版は[[配列]]の要素の順序に意味はあるとしていました。
[[EMCA-404]] の第2版は、順序に意味は与えないとし、
順序に意味があるところで使うことが多いと付け加えました。 (>>503)
[SRC[>>132]]
[[オブジェクト]]との表現の違いをみると、
どちらの版でも[[配列]]の方が[[オブジェクト]]より意味有りげに書かれてはいるのですが、
第2版では[[オブジェクト]]も[[配列]]も等しく [[JSON]] 層では意味がなく、
[[応用]]層では意味があるかもしれない、と解釈されるよう配慮されていることがわかります。
[418] 極めて稀に、実装が独自に順序に意味を持たせている場合があるようです。
[SRC[>>120]]
[121]
しかし多くの実装はそれを想定していないため、
[[相互運用性]]の問題があります。
多くの実装は順序を明示的に維持して [[JSON]] を出力できません。
多くの[[ライブラリー]]は [[JSON]] 中の順序が保証された状態で[[アプリケーション]]に引き渡すことができません。
[248] [[RFC 7159]] の追加部分によると、[[メンバー]]の順序を保持する実装と保持しない実装があるようです。
[SRC[>>314]]
[158]
順序が意味を持つことを想定しない実装には、
事実上の[[参照実装]]であるところの
[[ECMAScript]] [CODE[JSON]] [[オブジェクト]]も含まれます。
[[ECMA-404]]
が順序に意味を持たせることを容認も禁止もしていないとはいえ、
それを利用する[[応用]]が好ましいとは到底言い得ません。
[177]
[[RFC 7159]] とその前の版である [[RFC 4627]] は、
[[オブジェクト]]を[RUBYB[順序のない集成][unordered collection]]だと説明していました。
[SRC[>>314]]
これは
[[ECMA-404]] の定める本来の [[JSON]] 仕様には無い [[IETF]]
独自の解釈です。
[REFS[
- [120] [CITE@en[Package exports | [[webpack]]]], [TIME[2022-08-21T00:11:01.000Z]], [TIME[2022-08-21T12:27:46.595Z]]
]REFS]
*** 重複メンバー
[178]
[[ECMA-404]] 第2版によれば、
[[オブジェクト]]内の[[名前]]が固有でなければならない
(重複してはいけない)
という制約は、
[[JSON]] としては、ありません。
[SRC[>>4042 6]]
[HISTORY[
[258]
[[ECMA-404]] 第1版は固有性に特に言及していませんでした。
]HISTORY]
[49] [[RFC]] は[[オブジェクト]]内で名前は固有である[SHOULD[べき]]
[SRC[>>3 2.2., [[RFC 7159]]]]
としていますが、
[[ECMA-404]] の本来の [[JSON]] 仕様にはない
[[IETF]] 独自の制限です。
[267]
実質的な[[参照実装]]である
[[ECMAScript]] 仕様書で定義される [[JSON]] から [[JavaScript]] への変換では、
同名の[[メンバー]]のうち最後のものが [[JavaScript]] [[オブジェクト]]に反映されます。
[247] [[RFC 7159]] の新規追加部分によると、重複の内最後を選択する実装の他、エラーとなる実装やすべてを返す実装もあるようです。
[224] しばしば[[注釈]]として他の正規の[[メンバー]]と衝突しない名前を採用する慣習が一部にあり、
同名の[[メンバー]]があってもエラーにはならないことを仮定して複数の同名の[[メンバー]]によって複数の[[注釈]]を表すことがあるようです。
[287] [[OAuth 2.0]] は重複した指定を禁止しているようです。
[SEE[ [[トークンエンドポイント]] ]]
[555]
[[JOSEヘッダー]]や [[JWK]]
や [[JWK集合]]では拒絶または [CODE[JSON.parse]] 相当の動作のどちらかと決められています。
[SEE[ [[JOSEヘッダー]], [[JWK]], [[JWK集合]] ]]
[223] 同名の[[メンバー]]に対する処理が [[JSON]] レベルでは定義されていないため、
[[セキュリティー]]上問題となる危険性もあります。
[EG[
[512]
実装によりどの値を選択するかが異なり、
[[JSON]] を元に決定される処理が実装によって変化することがあります。
[[相互運用性]]に支障が出ていることは言うまでもありませんが、
[[セキュリティー]]に関わる挙動の食い違いも起こり得ます。
]EG]
[EG[
[513]
入力 [[JSON]] をまず検査し、次に本処理する2つのソフトウェア部品で構成されるソフトウェアを考えます。
1つ目が最初の値を選択して検査し、
2つ目が最後の値を選択して処理するなら、
未検査の値が処理してしまう[[脆弱性]]を有しています。
]EG]
[506]
以上踏まえて、新しい[[応用]]は、次の方針を採るべきでしょう。
- [507] 同名の[[メンバー]]を記述することを [[JSON]] の[[著者]]に要求しないこと
- [511] テキストエディターに近い操作性のソフトウェアである場合を除き、
同名の[[メンバー]]を持つ [[JSON]] を生成しないこと
- [508] 同名の[[メンバー]]があるとき最後のもののみを指定された値として採用すること
- [509] 同名の[[メンバー]]があっても致死的エラーとはみなさないこと
-- [510] 警告を出す機能を持つならその機能により報告してもいいが、
それを除いて正常処理を継続すること
** 配列
[50] [[配列]]は、 [CODE(char)[[['''[''']]]] の後に0個[[以上]]の値を [CODE(char)[[[,]]]]
で区切って並べ、最後に [CODE(char)[[[''']''']]]] が来る文字列として表されます。 [SRC[>>132, >>3 2.3.]]
[232] 値の個数に上限はありません。
[51] 最後の値の次に [CODE(char)[[[,]]]] を入れることは認められていません。
値なしに [CODE(char)[[[,]]]] が連続することも認められていません。
[FIG(railroad)[
= [CODE[ [ ]]
= ?
== [[JSON値]]
== *
=== [CODE[[[,]]]]
=== [[JSON値]]
= [CODE[ ] ]]
]FIG]
[231] [[配列]]がどう解釈されるのか、順序に意味があるという以上には定義されていません。
一般的には各種[[プログラミング言語]]の[[配列]]に対応付けられています。
[HISTORY[
[502]
[[ECMA-404]] の旧版は、
順序に[RUBYB[意味がある][significant]]としていました。
[SRC[>>4041 7]]
[503]
新版は、
値の順序に特に[RUBYB[意味][meaning]]は定めないとしつつ、
順序に何らかの[RUBYB[意味][semantics]]がある状況で[RUBYB[しばしば][often]]使われる、
としています。
[SRC[>>4042 7]]
[504] すなわち、旧版は順序に意味があるときに使わなければならないと強めに解釈される余地があるところ、
新版ではそこに意味を見ても見なくてもいい、
と実情により一致する厳密な表現に改められています。
[505]
汎用ライブラリーが[[配列]]の値の順序を保持して[[応用]]に引き渡さなければならないことには変わりありません。
[[応用]]はその順序情報を使っても無視してもいいということです。
]HISTORY]
[233] 値について、すべて同じ種類の値でなければならないなどの制約はありませんが、
[[JSON]] を利用する[[プロトコル]]その他によっては値の種類や可能な値に制約があるかもしれません。
** 数値
[53] [[数値]]は、必要なら[[負符号]]の後、[[整数部]]が来て、
必要なら[[小数部]]が来て、最後に必要なら([[十]]の)[[指数部]]が来る形を取ります。
[SRC[>>132, >>3 2.4.]]
[FIG[
- number = ["-"] int ["." 1*DIGIT] [ exp ]
- int = "0" / ( (DIGIT - "0") *DIGIT )
- exp = "e" ["-" / "+"] 1*DIGIT
]FIG]
[54] 先頭に[[正符号]]を使うことは認められていません。[[指数部]]では使えます。
[FIG(railroad)[
= ?
== [CODE[[[-]]]]
= |
== [CODE[[[0]]]]
== =
=== [CODE[[[1]]]]-[CODE[[[9]]]]
=== *
==== [CODE[[[0]]]]-[CODE[[[9]]]]
= ?
== [CODE[[[.]]]]
== +
=== [CODE[[[0]]]]-[CODE[[[9]]]]
= ?
== |
=== [CODE[[[E]]]]
=== [CODE[[[e]]]]
== |
=== [CODE[[[-]]]]
=== [CODE[[[+]]]]
== +
=== [CODE[[[0]]]]-[CODE[[[9]]]]
]FIG]
[234] [[符号]]の意味は自明であるためか、明確には規定されていません。
「先頭には[[負符号]] [CODE[-]] を置くことができる」 [SRC[>>132]] との規定より、 [CODE[-]]
で始まるなら残りの部分で表される[[数値]]が[[絶対値]]であるような[[負数]]、
そうでなければ[[正数]]を表すと解釈するのが自然でしょう。
[[指数部]]では更に [CODE[+]] も置くことができ [SRC[>>132]]、
残りの部分で表される[[数値]]が[[絶対値]]であるような[[正数]]と解釈するのが自然でしょう。
[308] [CODE[0]] と [CODE[-0]] の違いの扱いは、明記されていません。
構文上は [CODE[-0]] などの形で[[負]]の [[0]] を記述することは可能です。
[[JSON]] 仕様としては規定せず[[応用]]に委ねているのでしょう。
実際にはほとんどすべての場合に [CODE[-0]] は単に[[0]] であるとして扱われ、
[[-0]] とはみなされません。両者の違いに意味を持たせた用法は[[相互運用性]]が高くありません。
[EG[
[309] [[JSON]] への変換は [[-0]] を [CODE[-0]] と出力するかもしれませんが、
[[JSON]] からの変換が [CODE[-0]] を [[+0]] と解釈するかもしれません。
]EG]
[EG[
[335] 逆に [[JavaScript]] の [CODE(JS)@en[[[JSON.parse]]]] は [CODE[-0]] を [[-0]]
と解釈しますが、 [CODE(JS)@en[[[JSON.stringify]]]] は [CODE(JS)@en[JSON.parse ("-0")]]
の結果を与えると [CODE[0]] と出力します。
]EG]
[55] [[十進数]]により表記します [SRC[>>132, [[RFC 7159]]]]。
[HISTORY[
[514]
[[ECMA-404]] 旧版は 「base 10」と書いていました。 [SRC[>>4041 8]]
新版は「decimal」と書いています。 [SRC[>>4042 8]]
どちらも同じ意味ですが、旧版の方が意味が明瞭だったように思われます。
(新版の方が英語としては自然なのかもしれませんが。)
]HISTORY]
[56] [[整数部]]で[[先導0]]は認められていません [SRC[>>132]]。
[[指数部]]では使えます。
;; [243] [[先導0]]が排除されているのは、[[JavaScript]] において[[八進数]]と解釈されるからです。
[305] [[小数部]]を含めることができます [SRC[>>132]]。[[小数点]]は [CODE[[[.]]]]
です [SRC[>>132]]。[[小数点]]のみ含めて[[小数部]]を何も含めないことは認められていません。
末尾が [CODE[0]] であっても構いません。
[235] 表現できる数値の最小や最大、精度は規定されていません。 [[JSON]]
を利用する[[プロトコル]]その他や実装する[[プログラミング言語]]によっては制限や限界があるかもしれません。
[306] [[小数部]]の末尾に [CODE[0]] が余分にある場合とない場合とで値の解釈に相違があるかどうかは明記されていません。
[[JSON]] 仕様としては規定せず[[応用]]に委ねているのでしょう。
実際にはほとんどすべての場合に[[小数部]]の桁数は意味を持たず、
末尾の [CODE[0]] の有無や [CODE[0]] のみの[[小数部]]の有無は、意味を持ちません。
意味を持たせた用法は[[相互運用性]]が高くありません。
;; [307] [[プログラミング言語]]によっては[[小数部]]が含まれれば[[実数]]、
含まれなければ[[整数]]と区別することがありますが、 [[JSON]] にはそのような違いはありません。
もっとも、[[プログラミング言語]]の [[JSON]] の実装によっては [[JSON]]
からの変換時にこの違いから[[データ型]]を決めたり、
[[JSON]] への変換時に[[データ型]]により桁数を決めたりするかもしれません。
[249] [[RFC 7159]] は次のような追加の規定を設けています。
すなわち、
[[IEEE 754]]-2008 [[binary64]]
([[倍精度]]) 数が広く実装されておりますので、その範囲・精度で [[JSON]]
数を実装すると[[相互運用性]]が高くなります。その範囲外の [[JSON]] 数を使うと[[相互運用性]]の問題が生じるかもしれません。
[515]
これは [[ECMA-404]] にはない記述で、 [[JSON]] としての仕様上の制約ではありません。
また [[RFC 7159]] においても強制ではありません。
現実にその範囲外の数値が含まれる [[JSON]] が使われる場合もあるにはあります。
しかし同時に[[相互運用性]]の問題が生じているのも事実なので、
避けるのが無難なのは事実です。
[EG[
[284] 64ビット整数を扱える環境で出力した数値は、 [[JavaScript]] の数値に変換される際に[[浮動小数点数]]に変換され、元の値と近くても異なる値に変わってしまうことがあるので、注意が必要です。
]EG]
[57] [[無限大]]や[[NaN]]は表現できません。 [SRC[>>132, >>3 2.4.]]
;; [575] そのような[[JSONもどき]]が使われることはありますが、 [[JSON]] ではありません。
[SEE[ [[JSONもどき]] ]]
[310] 次のような場合は、 [[JSON]] [[数値]]ではなく、[[文字列]]として扱う方が安心です。
[FIG(list)[
- [[桁数]]に意味がある場合 (例えば[[小数部]]の[[桁数]]で[[精度]]を表す場合)
- [[符号付き32ビット整数]]の範囲外の[[整数]]を正確に扱いたいとき
- [[倍精度浮動小数点数]]で表現できない[[数]]を扱いたいとき
- [[無限大]]を扱いたいとき
- [[NaN]] を扱いたいとき
- [[-0]] を扱いたいとき
- [[数字列]]であって[[数値]]でないとき (例えば[[電話番号]])
]FIG]
** 文字列
[58] [[文字列]]は、0個以上の[[文字]]を[[引用符]]で括ることによって表されます
[SRC[>>132, >>3 2.5.]]。
[237] [[文字列]]は[[JSON値]]の一種として、または[[オブジェクト]]の[[名前]]の部分として用いられます。
-*-*-
[585] [[引用符]]は、 [CH["]] です。
;; [586] [CH[']] は使えません。
-*-*-
[236]
厳密には、[RUBYB[[[文字列]]][string]]は、
[[Unicode符号点]]の[[列]]です。
[SRC[>>4041 9, >>4042 9]]
これについては >>216 も参照してください。
[HISTORY[
[516]
[[ECMA-404]] 旧版では一部[RUBYB[文字][character]]と書かれていた規定も、
新版では厳密に[[符号点]]に改められています。
[SRC[>>4041 9, >>4042 9]]
]HISTORY]
[59] [[Unicode符号点]]は、
それを直接記述するか、
[[escape]] により表現することができます。
[SRC[>>132, >>3 2.5.]]
[517]
[[Unicode符号点]]のうち、
[CODE(char)[[["]]]],
[CODE(char)[[[\]]]], [CODE(char)[[[U+0000]]]] - [CODE(char)[[[U+001F]]]]
については必ず [[escape]] しなければなりません。
[SRC[>>132, >>3 2.5.]]
それ以外の [[Unicode符号点]]も [[escape]] することができます。
[519]
ほとんどの[[Unicode符号点]]は、2つ[[以上]]の方法で記述できます。
どの方法で記述しても、意味するものは同じで、等価です。
原記述の違いを [[JSON]] を解釈する実装が[[応用]]に引き渡して[[応用]]がその違いを使ってもいいのかどうか、
[[ECMA-404]] 仕様上は不明瞭です。
一般にはそうした違いを[[応用]]が区別して処理することはないと考えられています。
つまり [[JSON]] の[[著者]]は、編集上の都合で好きな方法で記述できます。
-*-*-
[239] [[文字]]の数に上下限はありません。[[文字列]]は[[空文字列]]であっても構いません。
[FIG(railroad)[
= [CODE[[["]]]]
= *
== |
=== [CODE[\]]、[[C0]] 以外の[[文字]]
=== =
==== [CODE[[[\]]]]
==== |
===== [CODE[[["]]]]
===== [CODE[[[\]]]]
===== [CODE[[[/]]]]
===== [CODE[[[b]]]]
===== [CODE[[[f]]]]
===== [CODE[[[n]]]]
===== [CODE[[[r]]]]
===== [CODE[[[t]]]]
===== =
====== [CODE[[[u]]]]
====== 4[[十六進数字]]
= [CODE[[["]]]]
]FIG]
-*-*-
[240] [[JSON]] を利用する[[プロトコル]]等によっては、[[文字]]の数やどのような[[文字列]]が認められるかに制限があるかもしれません。
[64] [[サロゲート]]や[[非文字]]の[[符号位置]]を使うことは禁止されていません。
[61] 明記されていませんが、半分は[[サロゲート・ペア]]の[[符号位置]]そのまま、
もう半分は [[escape]] というような列で [CODE(char)[[[U+10000]]]]
より大きな[[文字]]を表現することは認められていないと解釈できます。
;; [115] [[ES5]] の [[JSON]] の構文と構文解析の定義上は、 [[ECMAScript]] の [[UnicodeEscape]]
と同じとなっており、従って[[サロゲート・ペア]]の[[符号位置]]も単なる[[16ビット符号単位]]の文字列表現として普通に解釈されるべきものであるようです。
;; [116] [[Perl]] モジュール [CODE(perl)[[[JSON::XS]]]] はそのような[[サロゲート・ペア]]の[[符号位置]]に遭遇するとエラーを出して構文解析を中止します。
[442]
[[RFC 7515]]
は、
[CODE[U+10000]]
[[以上]]が含まれても正しく扱える[SHOOLD[べき]]としつつ、
使用する
[[JSON]]
の実装が正しく扱えない時、
これを含む入力を拒絶しなければ[MUST[ならない]]としています。
[SRC[>>439]]
;; [443] そのような [[JSON]] の実装は、一昔前ならともかく、
現在となっては致命的な不具合を抱えたものと言う他ありません。
[[RFC 7515]] の規定する [[JWS]] のような[[セキュリティー]]を扱う技術が、
救済措置とはいえ、致命的に壊れた実装を前提とした規定を含んでいるのは、
果たして望ましいものでしょうか。
[REFS[
- [439] [CITE@en[[[RFC 7515]] - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]]
]REFS]
*** 文字の escape
[65] [[escape]] とそれによって表される[[文字]]の対応関係は次の表の通りです。
[FIG(list)[
,* [[JSON]] 表記,* [[符号点]]
,[CODE(JS)[\"]],[CODE(char)[[["]]]]
,[CODE(JS)[\\]],[CODE(char)[[[\]]]]
,[CODE(JS)[\/]],[CODE(char)[[[/]]]]
,[CODE(JS)[\b]],[CODE(char)[[[U+0008]]]]
,[CODE(JS)[\f]],[CODE(char)[[[U+000C]]]]
,[CODE(JS)[\n]],[CODE(char)[[[U+000A]]]]
,[CODE(JS)[\r]],[CODE(char)[[[U+000D]]]]
,[CODE(JS)[\t]],[CODE(char)[[[U+0009]]]]
,[CODE(JS)[\u[VAR[HHHH]]]],[CODE(char)[U+[VAR[HHHH]]]]
]FIG]
[66] [[escape]] では、[[大文字と小文字]]の区別があります。
ここに示した通りに書かなければなりません。
ただし[[十六進数]] [VAR[HHHH]] は[[大文字]]でも[[小文字]]でも構いません。
[SRC[>>132, >>3 2.5.]]
[518]
[CODE[\u[VAR[HHHH]]]] の [VAR[HHHH]] は、4桁の[[16進数]]です。
[ [CODE[U+0000]], [CODE[U+FFFF]] ]
の範囲の[[符号点]]の値を意味します。
そしてこの [[escape]] はその[[符号点]]を表します。
[SRC[>>4041 9, >>4042 9]]
これについては >>216 も参照してください。
[60]
[ [CODE(char)[U+10000]], [CODE[U+10FFFF]] ]
の範囲の[[Unicode符号点]]は
[[UTF-16]]
[[サロゲートペア]]の2つの[[16ビット符号単位]]の列によって [[escape]]
で表せます。 [SRC[>>132, >>3 2.5.]]
これについてはも >>216 を参照してください。
[573]
[[escape]] してもしなくても表せる[[Unicode符号位置]]を [[escape]] するかどうかは、
実装により様々です。いろいろな流派があります。
: [ [CC[U+0000]], [CC[U+001F]] ] ([[C0]]) :
そのままでは記述できないので、必ず [[escape]] しなければなりません。
: [CH["]] :
[[文字列]]の区切りに使われるため、必ず [[escape]] しなければなりません。
: [CH[\]] :
[[escape]] に使われるため、必ず [[escape]] しなければなりません。
: [CH[+]] :
[[UTF-7]] と誤認される[[セキュリティー]]問題があるため [[escape]]
するのが安全と考えられていた時期がありました。
今ではまず問題となりませんが、当時の慣習が引き継がれている場合があります。
: [CH[/]] :
[[HTML]] の[[終了タグ]]が含まれると困ることがあるので [[escape]]
するのが安全と考えられることがあります。
[SRC[>>569]]
: [CH[<]] :
[[HTML]] の[[タグ]]と誤認される[[セキュリティー]]問題があるため [[escape]]
するのが安全と考えられることがあります。
: [ [CC[U+007F]], [CC[U+009F]] ] :
[[制御文字]]なので [[escape]] した方が安全という考え方があります。
: [ [CC[U+0080]], [CC[U+10FFFF]] ] :
[[非Unicode文字]]なので [[escape]] した方が安全という考え方があります。
: [CC[U+2028]], [CC[U+2029]] :
[[JavaScript]] との互換性の問題のため [[escape]] した方が安全と考えられていました (>>565)。
今ではまず問題となりませんが、当時の慣習が引き継がれている場合があります。
: [[サロゲート]] :
可搬性のため現実的に [[escape]] しなければなりません。
ただし [[escape]] したとて[[相互運用性]]には問題があります (>>524)。
: [ [CC[U+10000]], [CC[U+10FFFF]] ] :
[[BMP]] 外なので [[escape]] した方が安全という考え方があります。
: [[非文字]] :
[[応用]]によってうまく扱えないことがあるので、 [[escape]] した方が安全という考え方があります。
: [[非Unicode文字]] :
そのままでも [[escape]] でも表せません。
[574]
すべて [[escape]] してしまえば安全で可搬性は高まりますが、長くなる上に可読性は落ちます。
[[人間]]が読み書きできるという [[JSON]] の大きなメリットを潰してしまいます。
機械同士の通信にだけ使って[[人間]]が介在しない場面ではそれほど問題にはならないのでしょうが、
[[デバッグ]]やトラブル解決が面倒になります。
*** [CC[U+2028]], [CC[U+2029]]
[565]
かつては [[JSON]] で[[文字列]]リテラルにそのまま書ける
[CC[U+2028]] [CN[LINE SEPARATOR]]
と
[CC[U+2029]] [CN[PARAGRAPH SEPARATOR]]
が
[[JavaScript]]
では書けないという違いがありました。
[566]
滅多に遭遇しないのにたまに発生して[[不具合]]を発生させる発覚しにくい障害と脆弱性の温床となっていました。
[567]
[TIME[平成30(2018)年][2018]]頃に [[JavaScript]] 側で仕様変更があって
[SRC[>>564, >>563]]、
[[JSON]] と [[JavaScript]] のどちらでもこれらが認められる形で解消されました。
;; [568]
昔と違って [[JSON]] を [CODE[eval]] で読み込むことはまずないので、
問題になることは少なくなっていましたが。
今でも便宜上[[オブジェクト]]を [[JSON]] 化して [[HTML]] 中の
[CODE[script]]
[[要素]]の [[JavaScript]] コード中に埋め込むようなことはあるので、
共通化にはやはり恩恵があります。
[REFS[
- [564]
[CITE@en[GitHub - tc39/proposal-json-superset: Proposal to make all JSON text valid ECMA-262]], [TIME[2024-02-29T08:59:32.000Z]]
- [563]
[CITE@en[ECMAScript ⊃ JSON - Chrome Platform Status]], [TIME[2024-02-29T08:56:11.000Z]]
]REFS]
** boolean
[67] [CODE(JS)[[[true]]]] や [CODE(JS)[[[false]]]] の意味は >>132 では定義されていませんが、それぞれ [[boolean]]
の[[真]]と[[偽]]を表すと理解されています。これらは[[小文字]]でなければなりません。
** null
[68] [CODE(JS)[[[null]]]] の意味は >>132 では定義されていませんが、 [[null]] を表すと理解されています。
これは[[小文字]]でなければなりません。
** 入れ子の値
[556]
[[オブジェクト]]の値や[[配列]]の値として、他の[[オブジェクト]]や[[配列]]を指定できます。
つまり値を[[入れ子]]に ([RUBYB[[[ネスト]]][nest]]) できます。
[557]
[[JSON]] 仕様としては[[入れ子]]の深さの制限はありません。
何重にでも深い構造を記述できます。
[558]
[[Webプラットフォーム]]では明文規定はありませんが、
[[JSON]] を解釈する実装は、
[[ハードウェア制限条項]]に基づき十分深いところまでで対応を打ち切ることが可能です。
といっても[[Web互換性]]のため、制限は10や20のような浅いレベルでは足りません。
[559]
[[IETF]] の推奨が適用される仕様においては、
実装が制限を設けることが明文規定で認められています (>>81)。
[561]
実際に制限を設けている実装もあります。
例えば [[SQLite]] は (厳密に言えば [[JSON]] ではなく [[JSON]] と似て非なる
[[JSON5]] を更に独自に拡張したもの ([SEE[ [[JSON5]] ]]) ですが)、
[[入れ子]]の深さ1000を超えると[[非妥当]]とみなします
[SRC[>>560]]。
[REFS[
- [560]
[CITE[JSON Functions And Operators]], [TIME[2023-06-23T13:20:40.000Z]], [TIME[2023-06-29T01:38:39.716Z]]
]REFS]
* 構文
[292]
[[JSON]] は[RUBYB[テキスト構文][text syntax]] [SRC[>>4042]]
[WEAK[([RUBYB[テキスト書式][text format]] [SRC[>>4041]])]]
で、
[RUBYB[[[JSONテキスト]]][JSON text]]は
[[Unicode符号位置]]の[[列][文字列]] [SRC[>>4041, >>4042]]
だと説明されています。
[NOTE[
[298] つまり [[JSON]] は[[バイト列]]ではありませんし、
([[メモリー]]上の) [[オブジェクトモデル]]でもありません。
[[JSON]] を[[バイト列]]として送受信できますし (実際多いですし)、
それを処理するなら[[メモリー]]上に読み込むのは当然ですが、
それら自体は [[JSON]] 本体規格がカバーする事項ではないということです。
[EG[
[473] 「JSON は UTF-8」ということはなく、そういうこともありますしそうでないこともあります。
なぜなら、 [[JSON]] とは[[文字列]]の構文なので、
それがどんな[[文字コード]]で表現されているかは
[[JSON]] 本体規格でカバーされていないからです。
[SEE[ >>218 ]]
]EG]
]NOTE]
[101] [DFN[[[JSON]] [RUBYB[テキスト]@en[text]]]]とは、[[JSON値]]1つです [SRC[>>132]]。
なお [[ECMAScript]] の仕様上はこれは [DFN[[CODE[[[JSONText]]]]]] と呼ばれています [SRC[>>36 15.12]]。
[HISTORY[
[47] [[RFC 4627]] は [[JSONテキスト]]を[[オブジェクト]]または[[配列]]を1つ[[直列化]]したもの
[SRC[>>3 2.]] と定義しており、[[文字列]]や[[数値]]や [[true]] や [[false]] や [[null]] のような値は認めていませんでした。
[474]
これは [[RFC 7159]] で改められていて、現在では [[RFC]] でも >>101 の定義に揃えられています。
[[IETF]] の立場からはこれは厳密には[[非互換変更]]になります。
]HISTORY]
[228] [[空文字列]]は [[JSONテキスト]]ではありません。
** 字句解析
[46] [[JSONテキスト]]は、次の[[字句]]により構成されます [SRC[>>132, >>3 2.]]。
- [455] [RUBYB[構造的文字]@en[structual character]]
-- [CODE(char)[[['''[''']]]], [CODE(char)[[[''']''']]]], [CODE(char)[[[{]]]],
[CODE(char)[[[}]]]], [CODE(char)[[[:]]]], [CODE(char)[[[,]]]]
-- 前後に[[空白]]があっても構いません。
-- [[空白]]は、0[[文字]][[以上]]の [CODE(char)[[[U+0009]]]], [CODE(char)[[[U+000A]]]],
[CODE(char)[[[U+000D]]]], [CODE(char)[[[U+0020]]]] です。
- [456] JSON [RUBYB[値]@en[value]]
-- [[文字列]]
-- [[数値]]
-- [[リテラル名]]
--- [CODE(char)[[[true]]]], [CODE(char)[[[false]]]], [CODE(char)[[[null]]]]
--- [[小文字]]でなければ[['''なりません''']]。
[457]
[[空白]]は [[JSON]] としておよび[[応用]]としての意味を持ちません。
[[空白]]を挿入したり削除したりしても、その
[[JSONテキスト]]が表すものは変化しません。
;; [458] [[文字列]]中の[[空白]]は当然意味を持っています。
また[[数値]]や[[リテラル]]の途中に[[空白]]を挿入することも許されません。
[459]
[CODE[U+0000]], [CODE[U+000B]], [CODE[U+000C]], [CODE[U+FEFF]]
は [[JSON]] では[[空白]]では''ありません''。
[245] 多くの[[プログラミング言語]]などと異なり、 [[JSON]] には[[注釈]]がありません。
** 符号化文字集合
[216] [[JSONテキスト]]は、[[Unicode符号点]]の[[列][文字列]]です
[SRC[>>132, >>4041, >>4042]]。
[520]
これは [[JSONテキスト]]の全体だけでなく、
[[JSON]] 構文要素の一種である[RUBYB[[[文字列]]][string]]も、
[[Unicode符号点]]の[[列][文字列]]とされています (>>236)。
[238]
ところが[[文字列]]中の
[[escape]] における[[16進数]]だけはなぜか
[[Unicode]] ではなく [[ISO/IEC 10646]] により解釈するとされています
[SRC[>>132, >>4041 9, >>4042 9]]。
[499]
そのためなのか、
[[ECMA-404]]
はなぜか
[CITE[The Unicode Standard]]
と
[[ISO/IEC 10646]]
の両方を [[Normative References]] で[[引用]]しています。
[SRC[>>4041 3, >>4041 2]]
これをどう解釈するべきかは説明されていません。
(このような問題は他の[[仕様書]]にもたまにあります。
[SEE[ [[ISO/IEC 10646]] ]])
[521]
一般には [[JSON]] は [[escape]] もふくめてすべて [[Unicode]] と解釈されており、
[[ISO/IEC 10646]] への参照は無視して構わないと考えられます。
[[規格の厳密な解釈][spec lawyer]]の観点以外では、
それで特に問題はありません。
[HISTORY[
[217] [[ECMA-404]] 旧版は [[Unicode 6.2.0]] と
[[ISO/IEC 10646:2012]]
を[[引用]]していて、
[[仕様書]]には特定版を参照しているのだと明言されています。
[SRC[>>4041]]
固定する意図は不明で、
実用上は任意の[[Unicodeの版]]と解釈して構わないでしょう。
[472] 新版は最新版の [CITE[The Unicode Standard]]
と [[ISO/IEC 10646]] を参照するよう改められました。
[SRC[>>4042]]
]HISTORY]
*** サロゲート
[229] [[Unicode文字]]ではなく[[Unicode符号位置]]の[[列][文字列]]ですから、
[[サロゲート符号点]]も含まれます。
[HISTORY[
[230] [[ES5]] の [[JSON]] は、 [[BNF]] により [[SourceCharacter]]、すなわち [[UTF-16]]
の[[16ビット符号単位]]について定義していました [SRC[>>36 15.12]]。この定義では、
[[サロゲート]]が正しく2つ連続する場合に[[サロゲート]]の[[符号位置]]が2つ分と解釈されるのではなく、
[[文字]]が1つと解釈されるので、厳密には >>216 の定義と違うことになりますが、
実用上は同じと言っても構わないでしょう。
[100] [[RFC 4627]] の [[JSON]] は[[文字]]の列として定義されていました。 [[RFC 7159]]
は、
[[Unicode文字]]の列である、
とより明確に述べています。従って[[サロゲート]]は認められていません。
ただし [[ABNF]] 構文および [[escape]] の定義で[[サロゲート]]は除外されていません。
それらの意味は、 [[escape]] された[[サロゲート]]2つ分として使われる場合を除き、明確に定義されていません。
[[RFC 7159]] は実装により扱いが異なり、エラーになることもあると述べています。
]HISTORY]
;; [242] この[[サロゲート]]の扱いが問題となるのは、[[文字列]]の中だけです。 [[JSON]] として構文的に正しいテキストで[[サロゲート]]を含み得るのは[[文字列]]だけです。
;; [476]
[CITE[[[Encoding Standard]]]]
によれば
[CODE[utf-8]] や [CODE[utf-16]]
の[[復号]]時に不正な[[サロゲート]]は [CODE[U+FFFD]]
に置き換えられますから、
受信した[[バイト列]]を[[復号]]して得られた[[JSON]]データに[[サロゲート符号点]]が含まれることはありません。
しかし [[Webページ]]中の [[JavaScript]] コードで作成された[[文字列]]データや、
[CITE[[[Encoding Standard]]]] に従わずに[[復号]]する[[プログラム]]を使って得られた[[文字列]]データなど、
不正な[[サロゲート符号点]]が含まれる[[Unicode符号点]][[列][文字列]]は発生し得ます。
[522]
[[文字列]]の [[escape]] では、
[ [CODE[U+10000]], [CODE[U+10FFFF]] ]
の範囲の[[Unicode符号点]]をそのままの形で記述することができません。
そのかわりに、
[[UTF-16]] の[[サロゲートペア]]に相当する[[サロゲート符号点]]2つの
[[escape]]
の組み合わせによって記述できます
[SRC[>>4041 9, >>4042 9]]。
;; [523] これに関する [[ECMA-404]] の規定は
([[符号点]]と[[文字]]の区別を厳密化した新版の他の箇所の修正を踏まえると)
1箇所[[符号点]]と改めるべきだった箇所が[[文字]]と書かれています [SRC[>>4042 9]]。
[524]
[[ECMA-404]] の新版では、旧版になかった次のような規定が加わりました。すなわち、
[[JSONテキスト]]の処理器はそのような2つの [[escape]] を単一の[[符号点]]として解釈しても良いし、
明示的な[[サロゲートペア]]であると解釈しても良く、
それは特定の処理器の[RUBYB[意味的な決定][semantic decision]]により決められることであります。
[SRC[>>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つ並んでいても、[[サロゲートペア]]として解釈されることはありません。
従って、例えば
「[CODE["[VAR[サロゲート1]][[\u]][VAR[HHHH[SUB[[VAR[サロゲート2]]]]]]"]]」
を[VAR[サロゲート1]][VAR[サロゲート2]]の2つの[[符号点]]の[[列][文字列]]とする解釈があり得ます。
[531]
[[文字列]]データを [[UTF-16]] で扱う実装では、
[[サロゲート符号点]]が2つ正規の形で並ぶと必ず[[サロゲートペア]]として解釈されてしまいます。
従って、
例えば
「[CODE["[VAR[サロゲート1]][[\u]][VAR[HHHH[SUB[[VAR[サロゲート2]]]]]]"]]」
を[VAR[サロゲート1]][VAR[サロゲート2]]の2つの[[16ビット符号単位]]の列とした段階で、
それは[[サロゲートペア]]が表す1つの[[符号点]]の[[列][文字列]]にしかなりません。
[532]
[[HTML]] の[[文字参照]]はこのような不整合を防ぐため、
単独の[[サロゲート符号点]]は [CODE[U+FFFD]] に置き換えることとしています。
[[JSON]] の実装もそのような解釈を採るのが1案ではありますし、
それによって [[ECMA-404]] に違反するとはいえません。
[533]
しかしどの実装方法も [[ECMA-404]] が認めた「唯一の方法」ではありません。
[[相互運用性]]は無いものと思うしかありません。
-*-*-
[570]
実装によっては単独の[[サロゲート]]が出現したときエラーを出したり、
おかしな動作をしたりします。
[SRC[>>569]]
[571]
[[ライブラリー]]等の利用者はこのような境界ケースまで一々注意しきれないことが多いと予想されますので、
[[ライブラリー]]等の制作者は安全な挙動を標準とするように配慮するべきです。
どうするのが好ましいかは、その[[プラットフォーム]]の[[文字列型]]の仕様は[[例外]]機構の挙動などによって変わってくることでしょうが、
ここでもやはり [[JavaScript]] の挙動を模範とするのが良いでしょう。
[REFS[
- [569]
[CITE@ja[JSONの小ネタと、JSONに対する拡張]], [TIME[2024-11-21T04:38:03.000Z]]
]REFS]
*** 非文字
[241] [[非文字]]の[[符号位置]]も禁止はされていません。
[110]
[[プログラミング言語]]や[[マーク付け言語]]などの[[文字列]]系の[[データ型]]は、
[[非文字]]の[[符号位置]]の利用を禁止していることがあります。
[[JSON]] の[[文字列]]との相互変換の際には注意が必要です。
*** その他の符号位置
[475]
[[未割当符号点]]も禁止されていません。
** 文字符号化方式
[218] [[JSON]] としてはこの [[Unicode符号位置]]の列をどのような[[文字符号化方式]]で表現するかまでは'''規定していません'''。
[27]
多くのプロトコルでは [[UTF-8]] の[[バイト列]]として転送されます。
[[JavaScript]] では [[UTF-16スカラー値]]の列である[[文字列]]として表現されます。
場合によっては[[シフトJIS]] や [[ISO-8859-1]] など旧来の[[文字符号化方式]]が使われます。
[HISTORY[
[28]
「[[JSON]] は [[UTF-8]] で符号化しなければならない」と解説する人がいますが、
間違っています。
[[ECMA-404]] にそのような制約は存在しません。
]HISTORY]
;; [300]
[[JSONテキスト]]は [[Unicode符号点]]の[[列][文字列]]として定義されていますから、
[[非Unicode]]の[[文字コード]]を採用するなら、
[[参照処理モデル]]的な解釈を採用することになります。
*** IETF における JSON の文字コード
[69] [[RFC]] の [[JSON]] には[[文字符号化]]の制約があります。
[[ECMA-404]]
の本来の [[JSON]] 仕様には含まれず、
[[IETF]] の規格など [[RFC]] を参照した仕様にのみ適用される制約です。
[546]
[[RFC 8259]] に従う [[JSONテキスト]]は、
[RUBYB[閉じた生態系][closed ecosystem]]の内部を除いた[[系]]同士の[[交換]]において、
[[RFC 3629]] [[UTF-8]]
で[[符号化]]しなければ[MUST[なりません]]。
[SRC[>>353]]
[548]
「閉じた生態系」かどうかの判定基準は示されていないので、
この規定がどのような状況で適用され、どのような状況で適用されないのかは、
明らかにし難い場合もあります。
[552]
[[IETF]] が規定する[[プロトコル]]でその [[RFC]] が [[RFC 8259]]
を参照するようなものは、 「[[IETF]] の公開プロトコル」
という閉じていない生態系に属するものですから、
この規定が適用され、 [[UTF-8]] を使わなければならないと解釈するのが妥当でしょう。
[553]
特定の[[ウェブサーバー]]が出力し、それと対応関係にある特定の[[クライアント]]側
[[JavaScript]] [[プログラム]]だけが処理するような [[JSON]]
データは、
たとえそれが [[IETF]] の定義する [CODE[application/json]]
[[MIME型]]でラベル付けされていようとも、
閉じた生態系に属するものと解して良さそうに思われます。
その場合 [[UTF-8]] を使おうが使うまいが、
特定少数の開発者間の意思決定だけで[[相互運用性]]は確保できます。
[HISTORY[
[87]
[[RFC 4627]] では、 [[Unicode]] で[[符号化]]しなければ[MUST[ならない]] [SRC[>>3 3.]]
とされていました。
[[UTF-8]]、[[UTF-16]]、[[UTF-32]] を使って構わないという記述はありましたが
[SRC[>>3 6.]]、
それ以外を使ってはいけないとは明確に規定されていませんでした。
[547]
[[RFC 7159]] では更に制約され、 [[UTF-8]]、[[UTF-16]]、[[UTF-32]]
で符号化しなければ[MUST[ならない]]とされていました。
[SRC[>>353]]
[71] [[既定]]の[[符号化]]は [[UTF-8]] です [SRC[>>3 3.]]。
[550]
[[RFC 4627]] ではこの「既定」
が何を表すのかは明記されていませんでした。特に意図がなければ [[UTF-8]]
を使うべきであるということとも、[[文字符号化方式]]が特定できないときに
[[UTF-8]] として解釈するべきということとも解釈できましたし、それ以外の解釈もあり得ました。
[551]
[[RFC 7159]] では、 [[UTF-16]] と [[UTF-32]] に対応していない実装があり、
[[UTF-8]] が最も[[相互運用性]]が高いという記述が追加されました。
[75] 実装はこれらの[[符号化方式]]のいずれ、あるいはすべてに対応しなければならないのか、
しなくてもよいのか、といったことは [[RFC 4627]] ではまったく規定されておらず、
[[RFC 7159]] でも明記はされていませんが、 [[UTF-8]] は実装しなければならず、
[[UTF-16]] と [[UTF-32]] はオプションであると解釈するのが妥当でしょう。
;; [251] そんなことで[[相互運用性]]はいいのでしょうか。
[549]
[[RFC 8259]] はそこから更に限定して原則 [[UTF-8]] としました。
大多数の実装が [[UTF-8]] を選んでいるので[[相互運用性]]が達成できるのはそれしかないのだと説明されています。
[SRC[>>353]]
;; [576] [[非互換変更]]のようにも思われますが、
閉じた環境の例外があるので、従来通り [[UTF-16]] や [[UTF-32]]
を使ってもただちに[[不適合]]とはいえませんし、
一応互換性は保たれているといえます。
]HISTORY]
[HISTORY[
[72] [[RFC 4627]] の規定していた [[JSONテキスト]]は、
最初の2文字が必ず [[ASCII文字]]となります。
そのため、最初の4つの[[オクテット]]のパターンにより、
,[CODE[00 00 00 [VAR[xx]]]],[[UTF-32BE]]
,[CODE[00 [VAR[xx]] 00 [VAR[xx]]]],[[UTF-16BE]]
,[CODE[[VAR[xx]] 00 00 00]],[[UTF-32LE]]
,[CODE[[VAR[xx]] 00 [VAR[xx]] 00]],[[UTF-16LE]]
,[CODE[[VAR[xx]] [VAR[xx]] [VAR[xx]] [VAR[xx]]]],[[UTF-8]]
... と[[区別できる][sniffing]]とされていました。 [SRC[>>3 3.]] [VAR[xx]] は [CODE[00]]
以外の[[オクテット]]を表すのでしょう。 [[JSONテキスト]]に直接 [CODE(char)[[[U+0000]]]]
が出現することは無いとされているので、 [CODE[00]] かどうかで確実に判定できます。
[73] 一般の [[JSON]] は2文字目が必ずしも [[ASCII文字]]であるとは限りません (1文字以上の[[文字列]]や1文字だけの[[数]]の場合。) が、
それでもやはり同様にこれら5つの[[文字符号化方式]]を区別できます。
[76] この [[sniffing]] は、実装が必ず使わなければならないなどという規定は特にありません。
しかし [CODE(MIME)@en[[[application/json]]]] には [CODE(MIME)@en[[[charset]]]]
[[引数]]がありませんし、実際にこれらの[[文字符号化]]が使われているのであれば、
これ、あるいはこれに類する [[sniffing]] を実装する以外に選択肢はありません。
[253] [[RFC 7159]] では [[sniffing]] の項は削除されています。
[254] なお [[ECMA-404]] は[[文字符号化]]に関して規定していないので、 [[sniffing]]
への言及もありません。
[255] このような [[sniffing]] が実際に行われているのかは不明です。例えば [[XHR]]
は使っていません。
[384] [CITE[HTTP::Message - search.cpan.org]] ([TIME[2017-09-10 18:28:51 +09:00]])
はこれを実装しているようです。
[285] また [[UTF-32]] は[[セキュリティー]]上好ましくないと現在では考えられています。
]HISTORY]
*** Web における JSON の文字コード
[70]
[[Web]] においては
[[WHATWG]]
の
[CITE[Infra Standard]]
等に基づき原則
[[UTF-8]]
が使われます
(>>388, >>450)。
[477] [[Webにおける文字コード]]も参照。
*** BOM
[587]
一般論としていえば、 [[JSON]] に [CN[BOM]] があってもなくても構いません。
[160] [[ECMA-404]] は [[BOM]] を使っても良いかどうか明記していません。
ただし [[ECMA-404]]
は[[文字符号化]]については触れずに[[Unicode符号位置]]の[[列][文字列]]について定義しているに過ぎないので、
別の[[層]]の[[直交]]する問題
[WEAK[(つまり [[JSON]] を利用するプロトコルその他に依存する)]]
と解するべきだと思われます。
[88]
[[JSON]] の構文上、
先頭に
[CN[ZWNBSP]]
[WEAK[([CN[BOM]] と同じ [CC[U+FEFF]])]]
が来ることは認められていません。
従って、
[CN[BOM]] を使えない[[プロトコル]]や[[文字コード]]で
[CN[BOM]]
を使ってしまった場合、
[[JSON]]
としては構文エラーになります。
[HISTORY[
[74] [[RFC 4627]] は [[BOM]] について言及していませんでした。 [[BOM]] がある場合は >>72 のパターンに当てはまらず、
[[UTF-16]] や [[UTF-32]] であっても [[UTF-8]] と判定されてしまいます。ただし [[RFC]]
のこの部分は単なる事実の記述であって、そう解釈[[しなければならない]]などと規定されているわけではなく、
また明確に [[BOM]] を使用しては[[ならない]]と規定されているわけでもありませんから、
どう理解するべきか難しいところです。[[RFC 4627]] の改訂にあたっても [[BOM]]
が認められているかどうかは議論になっていました。
[159] [[RFC 7159]] は [[JSON]] を生成するときに [[BOM]] を含めては[['''ならず''']]、
[[JSON]] を解釈するときに [[BOM]] を無視しても[['''構わない''']]としています。
[554]
[[RFC 8259]] は、「ネットワーク転送される」 [[JSONテキスト]]のみにと当該規定の対象を限定しました。
[SRC[>>353]]
その意図は不明です。もっとも、そもそもネットワーク転送されない
[[JSONテキスト]]に [[RFC 8259]] の効力が及ぶ状況も少なかろうとは思われますから、
実効的には同じともいえます。
;; [250] [[BOM]] が含まれていると [[JSON]] でないとしてエラーとみなす実装も認めています。
そんなことで[[相互運用性]]はいいのでしょうか。
;; [252]
[CODE(charname)[ZWNBSP]]
[WEAK[([[BOM]] と同じ [[U+FEFF]])]]
は[[文字列]]以外で現れることはありませんから、
[[BOM]] かどうかは明確に判断できます。
]HISTORY]
[HISTORY[
[161]
かつて
[[XHR]] は [[JSON]] の解釈の際に [[BOM]] があれば無視するよう規定していました。
[317] >>74 の通り [[RFC 4627]] で [[BOM]] の扱いが明記されていなかったことから、
[[XHR]] が [[JSON]] の[[変種]]を規定しているとみなす人もいました。
[26]
しかし、
その程度で[[変種]]と判定されるとなると、
[[UTF-8]] の [[JSON]] と [[UTF-16]] の [[JSON]] は異なることになってしまいます。
「異なる [[JSON]] の利用方法がある」ならまだしも、
「[[JSON]] の異なる定義がある」と解するのは無茶でしょう。
[478]
現在の [CITE[XMLHttpRequest Standard]] は
[[Webプラットフォーム]]の共通の定義を参照するのみで、
独自の規定を持っていません。
(想定される挙動は同じで、
[CODE(charname)@en[BOM]]
はあってもなくても構いません。)
]HISTORY]
** 文字 [CODE(charname)@en[NULL]]
[341] [[JSON]] の構文上は [CC[U+0000]] [CN[NULL]]
[[文字]]の直接の記述は認められていません。
[572]
それが出現したときどう処理するべきかを [[JSON]]
本体仕様は規定していないので (ただし >>481)、
実装依存ということになります。
[342] [[HTML]] や [[CSS]] のような [[Web]] の各種言語に [CODE(char)@en[[[U+0000]]]]
が含まれていると、(文脈に依存して) [CODE(char)[[[U+FFFD]]]] に置き換えられたり、
除去されたりします。
[SEE[ [[Webにおける文字コード]] ]]
[343] つまり、 [[JSON]] の[[バイト列]]を受信し、[[文字列]]に変換し、
更に [[JSON]] として解釈した場合と、[[バイト列]]を [[HTML]]
として解釈し、その一部分を取り出し、その[[文字列]]を [[JSON]]
として解釈した場合で、含まれている [CODE(char)[[[U+0000]]]]
の解釈が変わってしまうことがあります。
;; [344] [[JSON]] ファイルへの [[navigate]]
で[[テキストファイルのDOM構築]]が行われた結果を [[JSON]] として解釈する場合も、
[[HTML]] に埋め込まれた場合同様となります。
[105]
[[JSON]] を [[HTML]] や[[テキストファイル]]に埋め込んで出力し、
そこから取り出して利用することは [[Webアプリケーション]]では定石ですから、
注意が必要です。
[112]
[[C言語]]のような [N[0x00]] を[[文字列]]の[[終端][NULL終端]]と見なす[[プラットフォーム]]では、
[[JSON]] との相互変換の際に取り扱いに注意が必要です。
** 構文解析器
[256] [[ECMA-404]] は構文を定めるのみで、構文解析の方法は定義していません。
[[JSON]] の利用側 (例えば [[ECMAScript]]) で定義するのが適当と考えているのでしょう。
-*-*-
[481]
[[JSONテキスト]]の[RUBYB[[[適合]]処理器][conforming processor]]は、
適合[[JSONテキスト]]でない入力を受理する[RUBYB[べきではありません][should not]]。
[SRC[>>4042 2]]
;; [480]
[[ECMA-404]]
[TIME[西暦2013年][2013]]版にはありませんでしたが、
[TIME[西暦2017年][2017]]版で追加されました。
[SRC[>>4042 2]]
[484]
適合しない入力を受理しないべきというのは、
過去様々に行われてきた (そして現在も一部で行われる) [[JSON]]
の独自拡張 (>>301) に、
[[JSON]] の実装が対応するべきではないということです。
;; [485] もちろん、 「[[JSON]] と似た [[JSON]] でないもの」
に対応することについて [[JSON]] の仕様書は何ら制限できる立場にないのですが、
それは [[JSON]] ではない何かに過ぎず、 [[JSON]]
の実装と称するものが行うべきではないということです。
;; [486] [[JSON]] と 「[[JSON]] に似たもの」の両対応で自動判別してます、
と称して形式的にこの規定を無視することはできますが、
不誠実の誹りは免れ得ないでしょう。
不具合と脆弱性の温床で、[[相互運用性]]を危険に晒すだけです。
-*-*-
[482]
[[JSONテキスト]]の[RUBYB[[[適合]]処理器][conforming processor]]は、
その処理する適合[[JSONテキスト]]の集合を制限する[RUBYB[意味的][semantic]]な制約を課しても[RUBYB[構いません][may]]。
[SRC[>>4042 2]]
;; [483]
[[ECMA-404]]
[TIME[西暦2013年][2013]]版にはありませんでしたが、
[TIME[西暦2017年][2017]]版で追加されました。
[SRC[>>4042 2]]
[487]
ここで認められているのは意味的な制限だけであって、構文的な制限を認める規定はありません。
ということは、例えば[[文字列]]中の[[escape]]は認めないような実装は、
[[適合]]処理器ではないということです。
想定されているのは、[VAR[[[応用]]A]]に特化しているので[VAR[[[応用]]A]]の[[オブジェクト]]形式を
[[JSON]] で表現しているものにしか対応できない、という類でしょう。
;; [488] 現在流通している [[JSON]] の実装のほとんどは汎用ライブラリーでしょうから、
そのような制限のある単体の [[JSON]] の実装がどれだけあるか、
今後どれだけ作られるかは疑問ではあります。
[[応用]]と不可分で外形的にそのように見える実装は多々あるかもしれません。
[NOTE[
[489]
この規定が追加された版の [[ECMA-404]]
では
[[IETF]] の [[RFC 8259]]
の存在が公認されています (>>461)。そして
[[RFC 8259]]
は意味的な制約を定義していると
[[ECMA-404]]
は述べています。
[SRC[>>4042 3]]
この規定は [[RFC 8259]]
の独自の規定の存在を明示的に承認する意図で追加されたようです。
つまり、
- [577] [[ECMA-404]] = [[JSON]]、
- [578] [[RFC 8259]] = [[JSON]] + 独自の意味的な制約、
という整理になります。
]NOTE]
[580]
なお、[[受理]]するべき[[JSONテキスト]]の長さや構造の[[入れ子]]の深さの制約は、
意味的制約というよりは構文・構造的な制約と考えられますが、
こうしたものが認められるのか明らかではない、どちらかというと認められないようにも思われます。
[581]
しかし現実の実装にはそうした制約が必須です。
[[Web]] では[[ハードウェア制限条項]]によって包括的に認められていると解されます。
[[RFC]] では独自の規定があります (>>80, >>81, >>83)。
*** ECMAScript における JSON 構文解析
[102] [[ES5]] の [CODE(JS)[[[JSON.parse]]]] は、 >>79 の拡張は認めておらず、
[[ES5]] の規定に厳密に従って構文解析しなければなりません [SRC[>>36 15.12]]。
*** Web における JSON 構文解析
[582]
[[Web]] では基本的に [CITE[ECMAScript]] の構文解析法が準用されています。
*** IETF の RFC における JSON 構文解析
[77] [[RFC]] の定義する[DFN[JSON [RUBYB[構文解析器]@en[parser]]]]は、 [[JSONテキスト]]を他の表現に変形するものです
[SRC[>>3 4., [[RFC 7159]]]]。
[78] [[JSON構文解析器]]は、 [[JSON]] の文法に適合するすべての[[テキスト]]を[[受理]]しなければ[['''なりません''']]
[SRC[>>3 4., [[RFC 7159]]]]。
[79] [[JSON構文解析器]]は、 [[JSON]] ではない形式や拡張を[[受理]]しても[MAY[構いません]]
[SRC[>>3 4., [[RFC 7159]]]]。
;; [579]
これは [[ECMA-404]] の規定 (>>481) に合理的理由なく違反する脱法的 (>>485)
規定です。
[80] [[受理]]する[[テキスト]]の[[サイズ]]を制限して構いません [SRC[>>3 4., [[RFC 7159]]]]。
[81] [[入れ子]]の深さを制限して構いません [SRC[>>3 4., [[RFC 7159]]]]。
[82] [[数値]]の範囲を制限して構いません [SRC[>>3 4., [[RFC 7159]]]]。
[83] [[文字列]]の[[長さ]]や[[文字]]の[[内容]]を制限して構いません [SRC[>>3 4., [[RFC 7159]]]]。
;; [84] これらの制限に抵触する場合にどのように処理しなければならないかは規定されていません。
また、 >>83 の文字の内容の制限というのが具体的に何を指しているかは不明確です。
特定の種類の文字から構成される文字列以外を処理できなくても構わないといったことでしょうか。
** 生成器
[257] [[ECMA-404]] は [[JSON]] の構文を定義するのみで、その生成の方法は定義していません。
[[プログラミング言語]]等の概念と [[JSON]] との対応関係は [[JSON]]
の定義するところではなくそれぞれで定めるべきと考えているため、
構文は定義できても、その構文に従う文字列をどのように生成するかは定義できないのでしょう。
[583]
生成の方法が規定されていないということは、
[[構文]]に[[一致]]する限り、
実装の裁量で自由な方法で生成できるということです。
例えば [[escape]] を使うか使わないかを選べますし、
字句間に[[空白]]を挿入するかしないかを選べます。
汎用ライブラリーはこうした挙動を呼び出し側に指定させることもできます。
[584]
[[JSON]] の[[応用]]は、生成の方法を独自に定めることもできます。
[[JSON]] を利用する場面によっては特定の生成方法しか選べないこともあります。
例えば [[JSON Lines]] では[[行指向]]の処理のため、
[[改行]]を挿入しないことが求められます。
[HISTORY[
[85] [[RFC]] の定義する [DFN[JSON [RUBYB[生成器]@en[generator]]]]は、 [[JSONテキスト]]を生産するものです
[SRC[>>3 5., [[RFC 7159]]]]。
[86] [[JSON生成器]]が生産する[[テキスト]]は、[[JSON]] の[[文法]]に厳密に[[適合]]しなければ[['''なりません''']]
[SRC[>>3 5., [[RFC 7159]]]]。
;; [318] [[RFC]] は自身の定義に違反するものを受理することを認めていますが (>>79)、
違反するものを生成することは認めていないのです。
つまり [[IETF]] の伝統である[[Postelの法則]]です。
]HISTORY]
[103] [[ES5]] の [CODE(JS)@[[[JSON.stringify]]]] は、 [[RFC]] ではなく [[ES5]]
の規定に従って [[JSON]] を生成しなければなりません [SRC[>>36 15.12]]。
* 処理
;; [479] 構文解析の項も参照。
[391] [[文字列]]から [[JSON]] を得る方法は、 [CITE[ECMAScript]]
で規定されています。 [[JavaScript]] の[[プログラム]]からは
[CODE[JSON.parse]] により呼び出せます。
-*-*-
[392] [[バイト列]]から [[JSON]] を得る方法は、 [CITE[Infra Standard]]
で [CITE[ECMAScript]] を参照する形で規定されています。
[388] [DFN[[RUBYB[バイト[RUBY[群][ぐん]]からJSONを[RUBY[構文解析][こうぶんかいせき]]]@en[parse JSON from bytes]]]]するには、
[VAR[バイト群]]を次のようにします。 [SRC[>>387]]
[FIG(steps)[
= [389] [VAR[テキスト]]を、[VAR[バイト群]]に [[UTF-8復号]]を適用した結果に設定します。
= [390] [[?][? (ES)]] [[Call]] ([CODE[%JSONParse%]], [CODE[undefined]], [VAR[テキスト]]のみを含む[[リスト]])
の結果を返します。
]FIG]
;; [393] [[UTF-8復号]]により [CODE(charname)@en[BOM]] は除去されます。
;; [400] [[UTF-8復号]]結果に [CODE[JSON.parse]] を適用することを意味します。
[449] 得られる結果は [[JavaScript値]]です。
[398] 次の場面で使われます。
[FIG(list short)[ [399] [[バイト群からJSONを構文解析]]するもの
- [[XHR]] [[JSON応答]]
- [CODE[fetch]] [[package data]] [[JSON]]
]FIG]
[450]
[DFN[[RUBYB[JSONをInfra[RUBY[値][ち]]に[RUBY[構文解析][こうぶんかいせき]]][parse JSON into Infra values]]]]するには、
[[文字列]][VAR[JSONテキスト]]を、
次のようにします。
[SRC[>>387]]
[FIG(steps)[
= [451] [VAR[JavaScript値]]を、
[[?][? (ES)]] [[Call]] ([CODE[%JSONParse%]], [CODE[undefined]], [VAR[JSONテキスト]]のみを含む[[リスト]])
の結果に設定します。
= [452]
[VAR[JavaScript値]]を
[[converting a JSON-derived JavaScript value to an Infra value]]
した結果に設定します。
]FIG]
-*-*-
[423]
[DFN[[RUBYB[JSONをバイト群に直列化][serialize JSON to bytes]]]]するには、
[[JavaScript]] 値[VAR[値]]を次のようにします [SRC[>>387]]。
[FIG(steps)[
= [424]
[VAR[文字列]]を、
[[?][? (JavaScript)]] [CODE[Call]] ([CODE[%JSONStringify%]], [CODE[undefined]],
[[«][«・»]] [VAR[値]] [[»][«・»]])
の結果に設定します。
= [425]
[VAR[文字列]]に [[UTF-8符号化]]を適用した結果を返します。
]FIG]
* JSON の変種
[301]
[[JSON]] は単純で今後の拡張も予定されていないと明言されています。
[SRC[>>4041, >>4042]]
[16]
[[JSON]] と似ているようでどこかが違う、
いろいろな [[JSONの変種]]が「JSON」 と呼ばれていることがあります。
[[相互運用性]]や[[セキュリティー]]の障害となっており、
注意が必要です。
[SEE[ [[JSONの変種]] ]]
[21]
[[JSON]] の不便な点を解消した、拡張したと称するものや、
特定用途向けに改造したもの、
マーケティング目的で [[JSON]] の名前を出しているものなど、
[[JSON]] の影響を受けているのに [[JSON]]
と大なり小なり違いがある[[データ形式]]も、
いろいろあります。
[[JSON]]
や
[[JSON]] を実装した[[ライブラリー]]等と名前が似ていて紛らわしいものもあり、
注意が必要です。
[SEE[ [[JSONの変種]] ]]
* JSON ストリーム
[294] 複数の [[JSON]] 値の連続を表す[DFN[JSONストリーム]]の[[データ形式]]も幾つか存在しています。
[SEE[ [[JSONストリーミング]] ]]
* JavaScript との互換性
[22] [[JavaScript]] から派生した [[JSON]] ですが、
微妙な違いがあり、取り扱いには意外と注意が必要だったりします。
[SEE[ [[JSONの変種]] ]]
* YAML との互換性
[18]
一部 [[YAML]] の支持者が [[YAML]] は [[JSON]] と互換性があるなどと喧伝したため、
[[JSON]] ではない [[YAML]] が [[JSON]] と呼ばれたり、
[[YAML]] を読み書きする実装が [[JSON]] に対応していると (実態に反して)
主張したりしていました。
[SEE[ [[JSONの変種]] ]]
* データモデル
[275] [[JSON]] には、 [[XML]] に対する [[XML情報集合]]のような厳密な[[データモデル]]は存在しません。
[[JSON]] が、それを処理するシステムでどのような[[データ構造]]で表現されたり、
どのような [[API]] でアクセスされたりするかは、完全にシステム依存となっています。
[276] [[JSON]] が限られた種類の (多くの[[プログラミング言語]]に共通して存在する)
値だけを表現でき、 (多くの[[プログラミング言語]]の実装で) ネイティブな[[データ構造]]に直接自明に変換可能なことが、
[[JSON]] の利用のしやすさにつながっており、 [[XML]] や [[YAML]]
にかわって開発者に広く支持され、普及した一因でしょう。
;; [277] 例えば [[XML]] の場合、ほとんどの実装は[[要素]]や[[テキスト]]などに相当する[[オブジェクト]]とそれを操作する
[[API]] を提供していて、[[プログラミング言語]]のネイティブのデータ構造や[[アプリケーション]]独自の[[データ構造]]との相互変換は、
[[アプリケーション]]ごとに設計し実装する必要があります。また [[YAML]]
にも[[型]]など[[プログラミング言語]]によっては自明に対応付けられない機構が備わっています。
[278] 多くの実装において専用の機構が不要となっているために、
([[JSON]] を入出力形式として採用した任意の[[アプリケーション]]のデータ構造上ではなく)
純粋な [[JSON]] のデータモデル上での操作を規定しても、
[[相互運用]]可能な形で広く普及するかどうかはわかりません。
[EG[
[279] 例えば [[JSON Pointer]] のような [[JSON]] データモデル上の式言語は、
[[プログラミング言語]]ネイティブなデータ構造に変換した後だと直接適用できない、
あるいはしづらい操作が含まれているかもしれません。
]EG]
** バイナリー
[213] [[JSON]] には[[バイナリーデータ]]を表現する方法がありません。[[文字]]の列は[[文字列]]として表現できますが、
[[バイト]]の列を [[JSON]] に直接含めることはできません。
[214] [[文字]]と[[バイト]]の区別が無いか曖昧な[[言語]]や環境では[[文字列]]が[[バイト列]]として使われることもありますが、
厳密にはそのような用法は [[JSON]] ではありません。
[215] [[バイト列]]その他の[[バイナリーデータ]]を扱いたい時は、 [[MessagePack]] など[[バイナリーデータ]]を扱えるデータ形式を使うか、
[[Base64]] など[[バイト列]]を[[文字列]]に符号化する方法を使って [[JSON]] の[[文字列]]に埋め込むなどする必要があります。
** 日時
[363] [[JSON]] には[[日時型]]はありません。
[364] [[文字列]]として [[ISO 8601の日時形式]]のいずれかを採用することや、
[[数値]]や[[文字列]]として [[Unix time]] を採用することが多いようですが、
どれが主流ということもなく、他の[[日時形式]]が使われることもあります。
* JSON 内データの識別・演算
[311] [[JSON式言語]]参照。
* MIME 型
[89] [[JSON]] の [[MIME型]]は [DFN[[CODE(MIME)@en[[[application/json]]]]]] です [SRC[>>3 6.]]。
[90] この他 [DFN[[CODE(MIME)@en[[[*/*+json]]]]]] により [[JSON]] を使った特定の[[応用]]を表すことがあります。
;; [320] 実際にはあまり一般的ではありません。
[447] [[JSON-LD]] の[[応用]]は更に細分化された
[CODE(MIME)@en[*/*+ld+json]]
を使っていることがあります。
[124] この他に [CODE(MIME)@en[[[text/json]]]] [SRC[>>331]], [CODE(MIME)@en[[[text/x-json]]]],
[CODE(MIME)@en[[[text/jaavscript]]]], [CODE(MIME)@en[[[text/x-javascript]]]],
[CODE(MIME)@en[[[application/x-javascript]]]],
[CODE(MIME)@en[[[text/plain]]]] が使われることもあります。
[333] [DFN[[RUBYB[[[JSON MIME型]]]@en[JSON MIME type]]]]は、次のものです [SRC[>>331]]。
[FIG(list short)[
- [CODE(MIME)@en[[[application/json]]]]
- [CODE(MIME)@en[[[text/json]]]]
- [CODE(MIME)@en[[[+json]]]] で終わる [[MIME型]]
]FIG]
[261] [[JSONP]] は [[JavaScript]] なので、 [CODE(MIME)@en[[[text/javascript]]]] を使うのが正しいですが、
[[JSON]] の [[MIME型]]になっていることもあります。
[319] [[LDJSON]] / [[JSON Lines]] の類は [[JSON]] そのものではないので、
それぞれに適切な [[MIME型]]を使うべきですが、 [CODE(MIME)@en[[[application/json]]]]
が使われることもあります。
[CODE(MIME)@en[application/orchestrate-export-stream+json]]
のように[[空白]]区切りの [[JSON]] で [CODE(MIME)@en[+json]]
が使われることもあります。
[562]
[[Web API]] の [[versioning]] に濫用されることがあります。
[SEE[ [[REST]] ]]
** CTE
[91] [[CTE]] としては、 [[UTF-8]] を使う時は [CODE(MIME)@en[[[8bit]]]]、
[[UTF-16]] や [[UTF-32]] を使う時は [CODE(MIME)@en[[[binary]]]] が適切です。 [SRC[>>3 6.]]
** 引数
[92] 公式には [CODE(MIME)@en[[[application/json]]]] には[[引数]]が定義されていません。
[147] 現実には次の[[引数]]が存在します。
[FIG(list short)[
- [CODE(MIME)@en[[[charset]]]]
- [CODE(MIME)@en[[[ieee754compatible]]]]
- [CODE(MIME)@en[[[odata]]]]
- [CODE(MIME)@en[[[odata.metadata]]]]
- [CODE(MIME)@en[[[odata.streaming]]]]
]FIG]
*** [CODE(MIME)@en[charset]] 引数
[93] たまに [CODE(MIME)@en[[[charset]]]] [[引数]]が付けられていることがあります。
[[RFC]] などの仕様書や [[Web API]] のドキュメントの類などでも、
しばしば [CODE(MIME)@en[[[charset]]]] [[引数]]が指定されています。
[125] [CODE(MIME)@en[[[charset]]]] が指定されていないと [[UTF-8]] であっても正しく[[復号]]できない実装があります。
[TIME[2013-03-06T07:46:28.900Z]]
[129] 他方、[[引数]]なしの「[CODE(MIME)@en[[[application/json]]]]」でないと [[JSON]]
が指定されたとみなさない実装もあります。
[FIG(quote)[
[FIGCAPTION[
[288] [CITE@en[REST API for MongoLab | MongoLab Documentation & Support]]
([TIME[2015-02-18 07:12:40 +09:00]] 版)
]FIGCAPTION]
> The API does support UTF-8 characters. As per the HTTP spec , 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.
]FIG]
[289] >>288 のように [CODE(MIME)@en[[[charset]]]] が [CODE(MIME)@en[[[application/json]]]]
にも適用されると [[HTTP]] を根拠に主張する実装もあるようです。
;; この解釈は [[RFC 2616]] を誤読しています。
** [CODE(MIME)@en[+json]] で終わる MIME 型
[FIG(list)[ [367] [CODE(MIME)@en[+json]] で終わる [[MIME型]]
- [98] [CODE(MIME)@en[[[application/jsonml+json]]]]
- [122] [CODE(MIME)@en[[[application/ld+json]]]]
- [99] [CODE(MIME)@en[[[application/microdata+json]]]]
- [CODE(MIME)@en[application/vnd.hyper-item+json]]
- [CODE[application/vnd.elasticsearch+json]]
]FIG]
* 拡張子
[94] [[JSON]] の[[拡張子]]には [CODE(file)@en[[[.json]]]] [SRC[>>3 6.]] がしばしば使われます。
* Macintosh ファイル型
[95] 古い [[Mac OS]] で[[ファイル]]の種類を表す[[符号]]としては [CODE[[[TEXT]]]]
が使われます [SRC[>>3 6.]]。
* 素片識別子
[96] [[RFC]] では[[素片識別子]]には言及されていません。
[97] [[JSON]] では[[素片識別子]]は使われていません。
[162] [[JSON Pointer]] というものがあり、[[JSON]] の[[素片識別子]]として使われることが想定されています。
[368] [CODE(MIME)@en[application/vnd.hyper-item+json]] は独自に[[素片識別子]]を規定しています。
* テスト
[435] [CITE[JSON_checker]], [TIME[2012-12-01 02:00:48 +09:00]]
[436]
公式テストデータ。受理するかしないかにわかれている。
取り出したデータについてまでは検査しない。
ライセンスが明記されていない。
[433] [CITE@en[nst/JSONTestSuite: A comprehensive test suite for RFC 8259 compliant JSON parsers]], [TIME[2020-02-13 14:17:34 +09:00]]
[434]
構文解析器の適合性の検査用データ。 [[RFC 8259]]
に基づくため、 [[JSON]] の定義 ([[ECMA-404]])
に対して正しい解釈かどうかは疑義が残る。
結果は受理、不受理、受理してもしなくてもよいに分かれている (この辺がなんとも怪しい)。
取り出したデータについてまでは検査しない。
[[MITライセンス]]。
[437] [CITE@en[test262/test/built-ins/JSON at master · tc39/test262]], [TIME[2020-02-13 14:35:02 +09:00]]
[438]
[CODE[JSON]] [[JavaScript]] API のテスト。
[[JSON]] の構文解析や直列化のそのもののテストは豊富でない上に [[JavaScript]]
コードに埋め込まれているので再利用は難しい。
* 応用
[SEE[ [[JSON応用]] ]]
** Web における JSON
[SEE[ [[JSON応用]] ]]
* 実装
[192] 現在ではありとあらゆる言語で [[JSON]] が実装されています。
[193] ただし [[JSON]] の仕様が (本項で長々と説明している通り) 半ば意図的に細部を曖昧にしていることもあり、
細部の実装はそれぞれに異なっており、境界ケースや独自拡張機能を使っていると他の実装で意図通り扱えないことがよくあります。
[269] そもそも細部が意図的に曖昧にされている理由でもありますが、 [[JSON]]
は色々な[[プログラミング言語]]のネイティブの[[データ型]]と直接対応付けることが想定され、
実際そのように実装されているため、 [[JSON]] が表すものを特定の意味に厳密に固定することが困難です。
[EG[
[270] 例えば[[数値]]は、こんにちの多くの計算機は [[IEEE 754]]
を採用していますが、そうでない計算機もあります。[[プログラミング言語]]によっては、
値によって[[整数型]]などとの自動型変換が行われるかもしれません。
また、[[文字列]]の内部表現は[[プログラミング言語]]によって異なります。
[[UTF-8]] であることもあれば、 [[UTF-16]] のこともあり、
任意の[[文字コード]]が使える言語もあります。[[文字列]]型がなく、
[[バイト列]]型しかない言語もあります。[[オブジェクト]] ([[写像]])
の名前と値の組の順序が保存される言語もあれば、されない言語もあります。
]EG]
[271] 従って、何をもって [[JSON]] が正しく実装されているかいないか判断すること自体が厳密には困難です。
同じ[[プログラミング言語]]における [[JSON]] の実装であっても、
異なる対応付けの方法が存在し得ます。 [[JSON]] の構文の仕様に加えて、
[[JSON]] と特定の環境等との対応付けの仕様が決められて、初めて適合性を議論できます。
[EG[
[272] 例えば [[ECMAScript]] は、 [CODE(JS)@en[[[JSON]]]] オブジェクトの定義において
[[JSON]] 文字列と [[JavaScript]] データとの相互変換の方法を厳密に決めています。
]EG]
[EG[
[169] [[Perl]] で [[JSON]] を扱う[[モジュール]]は多数あります。
[[Perl]] には [[boolean context]] はありますが、[[データ型]]としての [[boolean]]
は存在していません。 [[JSON]] の [[boolean]] を [[Perl]] の [[SV]] の [[1]]/[[0]]
に対応付けたり、 [[1]]/[[0]] の [[scalar reference]] に対応付けたり、
[[モジュール]]独自の[[オブジェクト]]として表現したりと、
[[モジュール]]ごとに様々な表現方法が採られています。
[281] [[Perl]] の[[データ]]と [[JSON]] の[[データ]]の関係が規定されていない以上、
どの実装が正しいとも誤りだとも言えません。どの実装がより便利かという議論はもちろん可能です。
[282] 同じ [[Perl]] という言語を使っていても、ある[[モジュール]]で [[JSON]]
に変換したデータを別の[[モジュール]]で [[Perl]] に変換した結果、
元のデータに戻るとは限りません。この意味で、ある[[モジュール]]が実装する“JSON”
と別の[[モジュール]]が実装する“JSON”は別物かもしれません。
]EG]
[FIG(short list)[ [10] [[JSON]] の実装例
- [CODE(JS)[JSON][JSON (JavaScript)]]
- [[JSONのPerlモジュール]]各種
]FIG]
* 関連
** XML との関係
[172] [[JSON]] は [[XML]] とは構文的にもデータモデル的にも全く互換性も歴史的関係もありませんが、
しばしば対比して語られます。 [[XML]] は90年代末から00年代中頃にかけて、
[[文書]]と[[データ]]の両方の記述形式の大本命としてもてはやされていました。ところが [[JSON]]
の登場により、[[データ]]の情報交換形式として多くの場面で [[XML]] より [[JSON]]
の方がより勘弁で扱い易いと認識されるようになりました。 [[JSON]] は元々 [[JavaScript]]
の[[リテラル]]から派生したものですから、多くの近代的な[[プログラミング言語]]における[[オブジェクト]]とも自明な対応関係が存在しており、
多くの[[プログラマー]]達には [[XML]] よりも [[JSON]] の方が理解しやすいという性質もありました。
[173] [[Webアプリケーション]]のサーバーが提供する [[Web API]] のデータ形式としては、かつては
([CODE(DOMi)@en[[[XMLHttpRequest]]]] という[[インターフェイス]]名に象徴されるように)
[[XML]] を用いるのが最善策であると考えられていた時期もありましたが、現在では専ら [[JSON]]
が用いられています。10年代の最初期には ([[Atom]] や [[RSS]] を含め) [[XML]] ベースの形式と
[[JSON]] の両方を提供する [[Web API]] も少なくありませんでしたが、10年代中頃には後方互換性のために必要な場合を除き、
[[XML]] ベースの [[Web API]] は見られなくなっています。
[174] アプリケーションの設定ファイルの類の記述形式としても、 [[XML]]
(や [[YAML]] その他の独自形式) から [[JSON]] へのシフトが同時期に起こっています。
例えば [[Widgets 1.0]] は [[XML]] 形式の設定ファイルを使っていますが、 [[Chrome拡張]]の設定ファイルは
[[JSON]] です。
[175] 世間一般での [[XML]] の衰退と [[JSON]] の普及を後追いするように、標準化コミュニティーでもかつての [[XML]]
ベースの技術にかわり、 [[JSON]] ベースで同様の技術を定義しようとする動きがあります。例えば
[[JSON Pointer]] ([[XPointer]])、[[JSON Schema]] ([[XML Schema]])、[[JSON Web Signature]] ([[XML Signature]])、
[[JSON-LD]] ([[RDF/XML]])、[[JSON Home Document]] ([[WSDL]]、[[AtomPub]]) などが提案されています。
-*-*-
[376] [[WCF]] は [[Mapping Between JSON and XML]] を使っています。
[373] [[XSLT 3.0]] は [[XML Representation of JSON]] を定義しています。
-*-*-
[377]
[[XML]] を [[JSON]] で記述する方法も幾つか提案されています。 [[XML/JSON]] を参照。
* 歴史
[321]
[[JSON]] は[TIME[西暦2001年][2001]]に [CODE[JSON.org]] で発表されたとされます。
[SRC[>>4041, >>4042]]
-[118]
[CITE[Introducing [[JSON]]]], [TIME[2022-07-30T03:42:15.000Z]], [TIME[2003-02-28T03:41:59.339Z]]
--[119] [CITE[[[JSON]]: The Fat-Free Alternative to XML]], [TIME[2022-07-30T03:43:36.000Z]], [TIME[2002-12-23T01:47:30.856Z]]
[322]
[TIME[西暦2006年][2006]]に
[[IETF]]
で
[DFN[[CITE[[[RFC 4627]]]]]]
として[[標準化]]されました。
[SRC[>>3]]
[REFS[
- [3] [CITE@en[RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON)]]
]REFS]
[104]
[TIME[西暦2009年][2009]]の
[CITE[[[ES5]]]] は、
[CITE[[[RFC 4627]]]] を引用しつつも独自に構文や解釈を規定しています。
[323]
[[Webブラウザー]]は
[CITE[[[ES5]]]] を実装しており、現在ではこちらが [[JSON]]
の定義として参照されるべきものでしょう。
[REFS[
- [34] [CITE[Annotated ES5]]
-- [35] [CSECTION@en[5.1.5 The JSON Grammar]]
-- [36] '''[CSECTION@en[15.12 The JSON Object]] '''
]REFS]
[163] その後
[CITE[[[ECMA-404]]]] が出版されました。
[CITE[[[ES6]]]] は [[ECMA-404]] を参照するように改められています。
ただし [CODE(JS)@en[[[JSON]]]] オブジェクトや構文解析、直列化の方法は [[ES]] 側に残されています。
** ietf-json と ECMA-404
[194] 2013年の初め頃、 [[IETF]] において [[RFC 4627]] を改訂して[[標準化過程]] [[RFC]]
とすることを目指す動きが起こり、 [DFN[[[IETF]] JSON [RUBYB[作業部会]@en[working group]]]]
([DFN[[[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]] の仕様書を作成し、数週間で [DFN[[[ECMA-404]]]]
として出版されました。 [[ES6]] からは [[JSON]] の定義は削除され、 [[ECMA-404]] を参照する形に改められました。
ただし [CODE(JS)@en[[[JSON]]]] オブジェクトの定義や [[ECMAScript]] との相互変換の定義は [[ES6]]
側に残されています。
;; [469] [TIME[西暦2013年10月][2013-10]]に郵便投票で承認されました。
[SRC[>>4041]]
[197] この ([[IETF]] では考えられないくらいに) 素早い新仕様の出版に、 [[Tim Bray]] ら [[ietf-json]]
側の関係者は [[JSON]] の標準化を行っているのは [[ietf-json]] であって [[TC 39]] では無い、
[[TC 39]] とは協力関係にあったはずなのに連絡もなかったなどと非難しますが、
[[TC 39]] 側はほとんど相手にしていません。互いの仕様の不備を主張し合うなど、両者の溝は埋まりません。
そこへ一見無関係な [[W3C]] の [[TAG]] も乱入してきて、
[[RFC]] の改訂版は [[ECMA-404]] の定義を参照するべきとするコメントを [[IETF]]
側に送付するなど、ちょっとした騒ぎになりました。
[198] 結局 [[RFC]] の改訂版は [[ECMA-404]] を参照していますが、違いを説明するために引用しているに過ぎず、
独自に [[JSON]] を定義しています。ただし [[JSON]] 全体は[[オブジェクト]]や[[配列]]だけでなく、
任意の値となるよう拡張されました ([[ECMA-404]] と同等になりました。 >>47、>>101 を参照。)
その他にも旧 [[RFC]] や [[ECMA-404]] にない規定が追加されています。更に [[JSON]]
の拡張や[[部分集合]]を定義することが引き続き [[ietf-json]] で検討されています。
こうして [[IETF]] によって [[JSON]] は [[fork]] されました。
[REFS[
- [179] [CITE[''''''[''''''Json'''''']'''''' Coordinating publication of 4627bis with ECMA]]
( ([TIME[2013-05-17 10:20:05 +09:00]] 版))
- [180] [CITE@en[charter-ietf-json-01]]
( ([TIME[2013-10-21 05:27:10 +09:00]] 版))
- [181] [CITE@en[JavaScript Object Notation (json) - Charter]]
( ([TIME[2013-10-21 05:28:37 +09:00]] 版))
- [182] [CITE[json Discussion Archive - Thread Index]]
( ([TIME[2013-10-23 18:32:14 +09:00]] 版))
- [183] [CITE[''''''[''''''Json'''''']'''''' Possible next work for the WG]]
( ([TIME[2013-10-16 19:21:19 +09:00]] 版))
- [184] [CITE[''''''[''''''Json'''''']'''''' Authorship]]
( ([TIME[2013-09-27 18:20:05 +09:00]] 版))
- [185] [CITE[''''''[''''''Json'''''']'''''' JSON & ECMA]]
( ([TIME[2013-03-19 21:22:04 +09:00]] 版))
- [186] [CITE[''''''[''''''Json'''''']'''''' Two Documents]]
( ([TIME[2013-06-18 14:21:41 +09:00]] 版))
- [187] [CITE[Re: ''''''[''''''Json'''''']'''''' Two Documents]]
( ([TIME[2013-06-19 14:52:20 +09:00]] 版))
- [188] [CITE[''''''[''''''Json'''''']'''''' 2-step proposal 4627bis + I-JSON]]
( ([TIME[2013-07-08 16:50:03 +09:00]] 版))
- [189] [CITE[''''''[''''''Json'''''']'''''' Consensus call: document title]]
( ([TIME[2013-06-24 16:20:15 +09:00]] 版))
- [190] [CITE[''''''[''''''Json'''''']'''''' What are we trying to do?]]
( ([TIME[2013-07-03 20:21:08 +09:00]] 版))
- [191] [CITE[Appropriate list for JSON standardization disussion]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [126] ( ([TIME[2013-03-11 16:24:22 +09:00]] 版))
- [127] [CITE[''''''[''''''apps-discuss'''''']'''''' JSON mailing list and BoF]]
( ([TIME[2013-02-19 20:50:03 +09:00]] 版))
- [131] [CITE@en[Next Steps on JSON + Proposed TAG Resolution]]
( ([[Appelquist Daniel (UK)]] 著, [TIME[2013-10-18 04:39:12 +09:00]] 版))
- [133] [CITE@en[draft-ietf-json-rfc4627bis-04 - The JSON Data Interchange Format]]
( ([TIME[2013-10-14 08:15:24 +09:00]] 版))
- [134] [CITE@en[draft-ietf-json-rfc4627bis-06 - The JSON Data Interchange Format]]
( ([TIME[2013-10-16 22:34:48 +09:00]] 版))
- [135] [CITE@en[Re: XHR vs JSON, was: Next Steps on JSON + Proposed TAG Resolution]]
( ([[Bjoern Hoehrmann]] 著, [TIME[2013-10-18 21:47:00 +09:00]] 版))
- [136] [CITE[Re: ''''''[''''''Json'''''']'''''' I-JSON vs. JSON-S]]
( ([TIME[2013-07-08 16:50:05 +09:00]] 版))
- [138] [CITE[Re: ''''''[''''''Json'''''']'''''' Comments on proposed charter for JSON]]
( ([TIME[2013-03-01 20:54:39 +09:00]] 版))
- [139] [CITE@en[Re: Next Steps on JSON + Proposed TAG Resolution]]
( ([[Tim Bray]] 著, [TIME[2013-10-19 00:01:07 +09:00]] 版))
- [140] [CITE@en[Technical Architecture Group Teleconference -- 02 Oct 2013]]
( ([TIME[2013-10-03 12:30:11 +09:00]] 版))
- [141] [CITE[tc39-notes/es6/2013-03/mar-12.md at master · rwaldron/tc39-notes]]
( ([TIME[2013-10-21 05:06:57 +09:00]] 版))
- [142] [CITE[tc39-notes/es6/2013-07/july-24.md at master · rwaldron/tc39-notes]]
( ([TIME[2013-10-21 05:13:50 +09:00]] 版))
- [143] [CITE@en[Re: ''''''[''''''Json'''''']'''''' FYI ECMA, W3C, IETF coordination on JSON]]
( ([[Allen Wirfs-Brock]] 著, [TIME[2013-10-09 04:37:43 +09:00]] 版))
- [144] [CITE@en[Re: ''''''[''''''Json'''''']'''''' FYI ECMA, W3C, IETF coordination on JSON]]
( ([[John Cowan]] 著, [TIME[2013-10-09 01:42:19 +09:00]] 版))
- [145] [CITE[Re: ''''''[''''''Json'''''']'''''' Streaming JSON parsers]]
( ([TIME[2013-07-03 06:50:40 +09:00]] 版))
- [146] [CITE[Re: ''''''[''''''Json'''''']'''''' Streaming JSON parsers]]
( ([TIME[2013-07-03 06:50:40 +09:00]] 版))
- [148] [CITE[JSON Duplicate Keys]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [149] [CITE[JSON specification WAS: Re: JSON Duplicate Keys]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [150] [CITE[May 21, 22, 23 TC39 Meeting Notes]]
( ([TIME[2013-06-21 04:11:18 +09:00]] 版))
- [151] [CITE@en[JSON feedback we could submit]]
( ([[Anne van Kesteren]] 著, [TIME[2013-11-11 12:08:26 +09:00]] 版))
- [152] [CITE@en[JSON: remove gap between Ecma-404 and IETF draft]]
( ([[Anne van Kesteren]] 著, [TIME[2013-11-12 16:01:30 +09:00]] 版))
- [153] [CITE@en[Concerns from the W3C Technical Architecture Group regarding JSON]]
( ([[Philippe Le Hegaret]] 著, [TIME[2013-11-27 07:31:33 +09:00]] 版))
- [155] [CITE@en[Re: ''''''[''''''Json'''''']'''''' Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)]]
( ([[Tim Bray]] 著, [TIME[2013-11-28 09:13:40 +09:00]] 版))
- [156] [CITE[''''''[''''''Json'''''']'''''' Response to Statement from Ecma International TC39]]
( ([TIME[2013-12-06 16:51:36 +09:00]] 版))
- [157] [CITE@en[TAG Teleconference -- 05 Dec 2013]]
( ([TIME[2013-12-09 15:52:58 +09:00]] 版))
]REFS]
[202] [[Tim Bray]] と [[ietf-json]] による [[RFC]] の改訂版は、2014年3月に [DFN[[[RFC 7158]]]]
として出版されました。ところがこのとき [[RFC Editor]] が誤って日付を「201'''3'''年3月」
としてしまったため、すぐに修正して [DFN[[[RFC 7159]]]] として再出版されました。
[203] これだけでも前代未聞の珍事ですが、どうやら [[RFC Editor]] も相当慌てていたらしく、
当初の [[RFC 7159]] は Errata のリンクや [[IANA Considerations]] の章の記述が「[[RFC 715'''8''']]」
のままになっていました。それらを修正したものがすぐに '''[[RFC 7159]] のまま'''再出版されました。
;; [205] この旧版 [[RFC 7159]] は2014年3月20日の時点で [[Google]] のキャッシュに [[HTML]]
版と [[PDF]] 版が残っています。 [[RFC Editor]] のサイトでも >>204 には [[PDF]]
版がまだ残っています。イレギュラーな操作で改版してここだけ差し替えを忘れているのでしょうか。
[206] さすがに3つ目の [[RFC]] を発行することは憚られたのでしょうが、一度出版した [[RFC]]
を置き換えないというポリシーを守るために日付だけ書き換えた [[RFC]] を再発行し、
日付が間違った [[RFC]] を (廃止状態とはいえ) 放置したり、
その直後にポリシーを歪めてより多くの箇所を変更した [[RFC]] を同じ番号で改版したりと、
[[RFC]] の発行手続きの運用上の大きな問題を曝け出す形になりましたが、なぜか [[IETF]]
界隈ではそれほど重大な問題として取り上げられていないようです。
;; [207] このような再出版に関する [[RFC Editor]] と著者の間のやり取りも個別に行われていたと見られ、
[[ietf-json]] などの[[メーリングリスト]]には記録は特に残っていません。
[209] >>201 は [[RFC 7158]] と新版 [[RFC 7159]] の差分です。
[210] このような流れを皮肉ってか、 [[RFC 7159]] への [[Errata]] として、
“全文を削除して「[[RFC 7158]] 参照」に置き換える”という修正案まで提案されています (>>263)。
;; [262] >>210 は >>208 に掲載されていたのですが、
残念なことにいつの間にか (却下ではなく) 削除されてしまいました。
なお [[RFC 7158]] に対して報告されていた Errata 2件 (>>264、>>265)
も (却下ではなく) 削除されています。現時点で残っているのは
[[RFC 7159]] に対する >>266 だけです。 [TIME[2014-04-02T07:23:09.00Z]]
[212] >>211 は [[RFC 4627]] と新版 [[RFC 7159]] の差分です。
[REFS[
- [199] [CITE@en[RFC 7158 - The JavaScript Object Notation (JSON) Data Interchange Format]] ([TIME[2014-03-04 16:52:46 +09:00]] 版)
- [200] [CITE@en[RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format]] ([TIME[2014-03-07 18:11:43 +09:00]] 版)
- [201] [CITE[wdiff rfc7158.txt rfc7159.txt]] ([TIME[2014-03-23 09:55:50 +09:00]] 版)
- [204] ([TIME[2014-03-03 10:54:26 +09:00]] 版)
-- [171] [[魚拓]] ( ([TIME[2014-03-20 16:10:57 +09:00]] 版))
- [211] [CITE[wdiff rfc4627.txt rfc7159.txt]] ([TIME[2014-03-23 10:19:06 +09:00]] 版)
- [264] [CITE['''['''Json''']''' [Technical Errata Reported] RFC7158 (3907)]] ([TIME[2014-03-04 15:22:08 +09:00]] 版)
- [265] [CITE['''['''Json''']''' [Technical Errata Reported] RFC7158 (3908)]] ([TIME[2014-03-03 10:55:34 +09:00]] 版)
- [208] [CITE[RFC Errata Report]] ([TIME[2014-03-23 10:16:41 +09:00]] 版)
- [266] [CITE['''['''Json''']''' [Technical Errata Reported] RFC7159 (3915)]] ([TIME[2014-03-13 15:52:13 +09:00]] 版)
- [263] [CITE['''['''Json''']''' [Editorial Errata Reported] RFC7159 (3922)]] ([TIME[2014-03-20 02:50:35 +09:00]] 版)
- [168] [CITE@en[ongoing by Tim Bray · JSON Redux AKA RFC7159]]
( ([TIME[2014-03-18 02:26:29 +09:00]] 版))
- [170] [CITE[RFC 7159 — the JSON Data Interchange Format]]
( ([TIME[2014-03-04 17:33:33 +09:00]] 版))
]REFS]
[246] なお [[RFC 7159]] には誤って [[RFC 607]] と [[RFC 3607]] を参照しているというおもしろ不具合があります。
[REFS[
- [314] [CITE@en[[[RFC 7159]] - The JavaScript Object Notation (JSON) Data Interchange Format]] ([TIME[2015-07-12 00:13:37 +09:00]] 版)
]REFS]
** メモ
[1]
[CITE[Introducing JSON]]
> [CODE[JSON]] (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.
;; [29] リンク切れ [TIME[2011-08-24T11:10:03.000Z]]
[2]
''Semantic Interpretation for Speech Recognition (SISR) Version 1.0''
([[名無しさん]] [WEAK[2006-01-19 03:31:05 +00:00]])
[4]
>>3 明記されていないけど [[BOM]] は使えないということでおk?
([[名無しさん]])
[5]
不適合文書の扱いも明記されていないけど、構文解析器は不適合も処理して'''構わない'''ことになっているから、
適当に理解するなりはじくなりでおk?
([[名無しさん]])
[6]
[[サロゲート・ペア]]の片割れだけが escape されている場合は >>5?
([[名無しさん]])
[7]
[CITE@ja-JP[Matzにっき(2007-04-16)]] ([[Yukihiro -matz- Matsumoto]] 著, [CODE[2007-04-23 23:58:26 +09:00]] 版)
([[名無しさん]] [WEAK[2007-05-05 03:25:51 +00:00]])
[8]
[CITE@en[JSONLint - The JSON Validator.]] ([TIME[2008-06-22 12:32:25 +09:00]] 版)
[17] [CITE[IRC logs: freenode / #whatwg / 20090906]]
([TIME[2009-10-17 22:08:59 +09:00]] 版)
;; [33] [[JSON]] の[[構文解析]]における互換性について。 [[RFC]] は非標準の拡張を理解することを認めている。
[[ES5]] はより厳密に定義している。古い案では[[注釈]]を認めていたが、
非標準の[[指令]]の埋込みに使われるようになったため、結局認めないことになった。
[19] [CITE[as3corelib の JSON.decode() をいい加減な JSON に対応させる - てっく煮ブログ]]
([TIME[2010-01-01 12:15:16 +09:00]] 版)
[20] [CITE[IRC logs: freenode / #whatwg / 20100104]]
([TIME[2010-01-06 08:11:05 +09:00]] 版)
;; [32] [[JSON]] の[[文字符号化]]について。
[62] [[JSON]] の [[RFC]] はデータ型と構文上の要素と字句の関係を半ば暗黙のものとして扱っていて、
何がどう解釈されるかといったことを明確に規定していません。
;; [63] こういうのが、 [[Hixie]] が [[BNF]] を使わない理由の1つだよなー。
[106] [CITE[PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記]]
([TIME[2011-09-15 11:02:11 +09:00]] 版)
[107] [CITE@en-US[An update is available for the native JSON feature in Internet Explorer 8]]
([TIME[2011-10-05 11:52:02 +09:00]] 版)
[108] [CITE@en[Native JSON in IE8 - IEBlog - Site Home - MSDN Blogs]]
([TIME[2011-10-05 11:52:24 +09:00]] 版)
[109] [CITE[IRC logs: freenode / #whatwg / 20111005]]
( ([TIME[2011-10-06 22:50:15 +09:00]] 版))
[111] [CITE@en[draft-pbryan-http-json-resource-01 - A Convention for HTTP Access to JSON Resources]]
( ([TIME[2012-02-05 13:38:13 +09:00]] 版))
[113] [CITE@ja[JSONIC - simple json encoder/decoder for java]]
( ([TIME[2012-02-12 13:26:51 +09:00]] 版))
[114] [CITE[dominictarr/JSON.sh · GitHub]]
( ([TIME[2012-03-12 23:04:45 +09:00]] 版))
[123] [CITE[JSON::XSで作られる浮動小数点数でハマった話 - 北海道苫小牧市出身のPGが書くブログ]]
( ([TIME[2012-10-24 11:49:48 +09:00]] 版))
[128] [CITE[''''''[''''''whatwg'''''']'''''' asynchronous JSON.parse and sending large structured data between threads without compromising responsiveness]]
( ([TIME[2013-08-06 23:47:37 +09:00]] 版))
[130] [CITE@en[RFC 6839 - Additional Media Type Structured Syntax Suffixes]]
( ([TIME[2013-06-28 00:23:48 +09:00]] 版))
[137] [CITE@EN[XSL Transformations (XSLT) Version 3.0]]
( ([TIME[2012-07-10 14:04:59 +09:00]] 版))
[154] [CITE[twitterのXSSとJSON in ECMAScriptと外部JSONを安全に取り扱うためのアプローチ - 金利0無利息キャッシング – キャッシングできます - subtech]]
( ([TIME[2013-12-03 04:59:58 +09:00]] 版))
[164] [CITE@en[PostgreSQL: Documentation: 9.3: JSON Functions and Operators]]
( ([TIME[2013-12-17 07:19:21 +09:00]] 版))
[166] [CITE[Twitter の JSON に罪はない - ぐま あーかいぶ]]
( ([TIME[2014-01-06 18:51:36 +09:00]] 版))
[167] [CITE[IRC logs: freenode / #whatwg / 20140319]]
( ([TIME[2014-03-20 20:29:26 +09:00]] 版))
[259] [CITE@en-US[JSON JavaScript Object Notation - Yahoo Groups]]
( ([TIME[2014-03-24 09:51:04 +09:00]] 版))
[260] [CITE@en-US[JSON JavaScript Object Notation - Yahoo Groups]]
( ([TIME[2014-03-24 09:51:44 +09:00]] 版))
[274] [CITE@en[RedHanded » YAML is JSON]]
( ([TIME[2011-08-08 03:18:33 +09:00]] 版))
[280] [CITE[''''''[''''''Json'''''']'''''' Call for Volunteers for Liaison Manager to ECMA TC39]]
( ([TIME[2014-06-18 15:21:00 +09:00]] 版))
[283] [CITE[JsonWireProtocol - selenium - A description of the protocol used by WebDriver to communicate with remote instances - Browser automation framework - Google Project Hosting]]
( ([TIME[2014-10-30 06:28:02 +09:00]] 版))
[FIG(quote)[
[FIGCAPTION[
[293] [CITE@en[Draft 1: OAuth Extension for Response Data Format - Draft 1]]
([TIME[2008-09-10 03:31:09 +09:00]] 版)
]FIGCAPTION]
> 'Content-Type' HTTP response header value MUST be :
> Content-Type: text/json
]FIG]
** RFC 8259 へ
[291] [CITE[''''''[''''''Json'''''']'''''' FYI: January 28 2015 Meeting Notes]]
([TIME[2015-02-12 03:50:54 +09:00]] 版)
[FIG(quote)[
[FIGCAPTION[
[296] [CITE@en-US[Noggit, the JSON Streaming Parser - Solr 'n Stuff]]
([TIME[2015-03-29 20:05:45 +09:00]] 版)
]FIGCAPTION]
> 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
]FIG]
[FIG(quote)[
[FIGCAPTION[
[297] [CITE[flow.io API Reference]]
([TIME[2011-11-28 06:10:46 +09:00]] 版)
]FIGCAPTION]
> 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".
]FIG]
[299] [CITE[''''''[''''''Json'''''']'''''' Closing of the group]]
([TIME[2015-03-24 23:51:07 +09:00]] 版)
[FIG(quote)[
[FIGCAPTION[
[302] [CITE@en-US[Archive]]
([TIME[2015-07-11 09:10:29 +09:00]] 版)
]FIGCAPTION]
>
> 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.
]FIG]
[303] [CITE@en-US[Mail Archive]]
([TIME[2015-07-11 09:10:48 +09:00]] 版)
[304] [CITE[''''''[''''''Json'''''']'''''' WG Action: Formed Javascript Object Notation Update (jsonbis)]]
([TIME[2015-07-06 05:21:17 +09:00]] 版)
[313] [CITE@en[JSON can also be 1 or false or "hi!" · whatwg/fetch@1a1b977]]
([TIME[2015-08-12 11:20:38 +09:00]] 版)
[329] [CITE@en[1201632 – iframe does not fire onload when 404 is not text/html or text/plain]]
([TIME[2015-09-30 23:09:57 +09:00]] 版)
[330] [CITE@en[Increase the number of MIME types rendered as text · Issue #124 · whatwg/html]]
([TIME[2015-09-30 23:10:07 +09:00]] 版)
[332] [CITE@en[Fix #124: make more types follow text/plain navigate logic · whatwg/html@f94f3c4]] ([TIME[2015-10-01 00:44:06 +09:00]] 版)
[FIG(quote)[
[FIGCAPTION[
[334] [CITE[''''''[''''''Json'''''']'''''' Kicking Off JSONbis]]
([TIME[2015-10-07 15:20:32 +09:00]] 版)
]FIGCAPTION]
> 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
]FIG]
[336] [CITE@en[draft-ietf-jsonbis-rfc7159bis-00 - The JavaScript Object Notation (JSON) Data Interchange Format]]
([TIME[2015-10-20 17:14:40 +09:00]] 版)
[FIG(quote)[
[FIGCAPTION[
[337] [CITE[Re: ''''''[''''''Json'''''']'''''' Kicking Off JSONbis]]
([TIME[2015-10-19 16:52:42 +09:00]] 版)
]FIGCAPTION]
> 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.
>
]FIG]
[338] [CITE@en[Predictable Serialization for JSON Tools]]
([TIME[2015-11-06 01:12:45 +09:00]] 版)
[339] [CITE[''''''[''''''Json'''''']'''''' Normative reference reasoning and logistics]]
([TIME[2015-11-17 18:21:05 +09:00]] 版)
[FIG(quote)[
[FIGCAPTION[
[340] [CITE[JSON Verbose Format (OData Version 3.0) · OData - the Best Way to REST]]
([TIME[2015-10-28 12:33:47 +09:00]] 版)
]FIGCAPTION]
> 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.
]FIG]
[345] [CITE@en[Technical Architecture Group Teleconference -- 17 Oct 2013]]
([TIME[2013-10-21 22:09:06 +09:00]] 版)
[346] [CITE@en[add "charset=utf-8" to content-type "application/json" · Issue #383 · request/request]]
([TIME[2016-01-15 21:51:36 +09:00]] 版)
[347] [CITE@en[encoding/json: serialization of angle brackets is incompatible with ES6 · Issue #14749 · golang/go]]
([TIME[2016-03-15 16:35:34 +09:00]] 版)
[11] [CITE['''['''Json''']''' jsonbis - Not having a session at IETF 96]]
( ([TIME[2016-06-03 23:50:11 +09:00]]))
[12] [CITE['''['''Json''']''' Working Group Last Call of draft-ietf-jsonbis-rfc7159bis-02]]
([TIME[2016-07-18 23:50:35 +09:00]])
[13] [CITE['''['''Json''']''' JSON irritants]]
([TIME[2016-08-03 15:20:05 +09:00]])
[FIG(quote)[
[FIGCAPTION[
[14] [CITE@ja-jp[マイクロサービスのための綺麗なAPI設計 by Go Takagi | Wantedly Engineer Blog]]
([TIME[2016-08-18 12:24:02 +09:00]])
]FIGCAPTION]
> curlの場合
> curl -i -H "Accept: application/json; version=0.5" -X GET http://localhost:8080/api/users
> 今回はversion<1.0.0だとerrorを返すようにしました。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[15] [CITE@en[RFC 7946 - The GeoJSON Format]]
([TIME[2016-08-19 22:23:34 +09:00]])
]FIGCAPTION]
>
> 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.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[348] [CITE@en[encoding/json: use standard ES6 formatting for numbers during marshal]]
([[rsc]]著, [TIME[2016-10-06 00:26:04 +09:00]])
]FIGCAPTION]
> 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.
]FIG]
[349] [CITE@en[seriot.ch - Parsing JSON is a Minefield 💣]]
([[Nicolas Seriot]]著, [TIME[2016-12-07 20:40:12 +09:00]])
[350] [CITE@en[nst/JSONTestSuite: A comprehensive test suite for RFC 7159 compliant JSON parsers]]
([TIME[2016-12-07 20:40:46 +09:00]])
[FIG(quote)[
[FIGCAPTION[
[351] [CITE['''['''Json''']''' Status of 7159bis]]
([TIME[2017-01-08 17:50:02 +09:00]])
]FIGCAPTION]
> 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
]FIG]
[352] [[RFC 7159]] の改訂版である [DFN[7159bis]] が [[WG]] に何の断りもなく
(未解決の問題もあるのに) [[RFC]] に進もうとしている、と気づいて問い合わせていますが、
いつの間にか話がすり替えられて [[ECMA]] との協調問題になっています。
[[IETF]] 側としてはさっさと [[RFC]] を出版して [[WG]] を閉鎖したいようです。
そして [[RFC]] を出版すれば [[ECMA-404]] も改訂されると思っています (根拠は不明)。
[312] [CITE@ja[JSON データ (SQL Server)]]
([TIME[2017-02-19 19:53:03 +09:00]])
[354] [CITE@EN[XPath and XQuery Functions and Operators 3.1]]
([TIME[2017-03-21 16:02:06 +09:00]])
[FIG(quote)[
[FIGCAPTION[
[355] [CITE@EN[XPath and XQuery Functions and Operators 3.1]]
([TIME[2017-03-21 16:02:06 +09:00]])
]FIGCAPTION]
> 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.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[356] [CITE@EN[XPath and XQuery Functions and Operators 3.1]]
([TIME[2017-03-21 16:02:06 +09:00]])
]FIGCAPTION]
> 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.
]FIG]
[357] [CITE@en[XSLT and XQuery Serialization 3.1]]
([TIME[2017-03-20 12:35:18 +09:00]])
[358] [CITE['''['''Json''']''' Last Call: (The JavaScript Object Notation (JSON) Data Interchange Format) to Internet Standard]]
([TIME[2017-03-04 02:20:43 +09:00]])
[359] [CITE[Re: '''['''Json''']''' secdir review of draft-ietf-jsonbis-rfc7159bis-03]]
([TIME[2017-03-13 00:50:43 +09:00]])
[360] [CITE['''['''Json''']''' Call for Consensus: Proposed Text for "8.1 Character Encoding"]]
([TIME[2017-03-17 05:51:32 +09:00]])
[361] [CITE[Re: '''['''Json''']''' Call for Consensus: Proposed Text for "8.1 Character Encoding"]]
([TIME[2017-03-19 18:50:08 +09:00]])
[362] [CITE[Re: '''['''Json''']''' Call for Consensus: Proposed Text for "8.1 Character Encoding"]]
([TIME[2017-03-28 13:50:24 +09:00]])
[FIG(quote)[
[FIGCAPTION[
[365] [CITE@en[draft-wright-json-schema-hyperschema-01 - JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON]]
([TIME[2017-04-17 23:01:59 +09:00]])
]FIGCAPTION]
>
> Content-Type: application/json; profile="http://example.com/alpha"
]FIG]
[366] [CITE@en[Issue 17906: JSON should accept lone surrogates - Python tracker]]
([TIME[2017-05-03 18:29:19 +09:00]])
[FIG(quote)[
[FIGCAPTION[
[369] [CITE@en[Stand-Alone JSON Serialization]]
([TIME[2017-06-01 22:23:28 +09:00]])
]FIGCAPTION]
> 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.
]FIG]
[370] [CITE@en[Mapping Between JSON and XML]]
([TIME[2017-06-01 22:25:44 +09:00]])
[FIG(quote)[
[FIGCAPTION[
[371] [CITE[CircleCI API v1.1 Reference - CircleCI]]
([TIME[2017-06-10 05:03:08 +09:00]])
]FIGCAPTION]
> 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.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[372] [CITE@EN[XSL Transformations (XSLT) Version 3.0]]
([TIME[2017-06-06 21:59:56 +09:00]])
]FIGCAPTION]
> 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''']'''.
]FIG]
[FIG(quote)[
[FIGCAPTION[
[374] [CITE@EN[XSL Transformations (XSLT) Version 3.0]]
([TIME[2017-06-06 21:59:56 +09:00]])
]FIGCAPTION]
> 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.
]FIG]
[375]
「Many」というのは事実なのでしょうか。まあ most とはいっていないですし、
著者が many だと思えば many なのでしょうが...
[378] [CITE@en[Add frozen array types to the list of JSON types]]
([[tobie]]著, [TIME[2017-06-23 06:43:37 +09:00]])
[379] [CITE@en[Add frozen array types to the list of JSON types by tobie · Pull Request #373 · heycam/webidl]]
([TIME[2017-06-23 20:08:41 +09:00]])
[380] [CITE@en[JSON clone: correct cycle detection]]
([[jugglinmike]]著, [TIME[2017-06-07 01:04:34 +09:00]])
[381] [CITE@en[ACTION-732: Investigate relationship between ECMA's JSON spec and IETF RFC 7159 - Efficient Extensible Interchange Working Group Tracker]]
([TIME[2017-07-10 14:10:25 +09:00]])
[382] [CITE[Re: '''['''Json''']''' Call for Consensus: Proposed Text for "8.1 Character Encoding"]]
([TIME[2017-07-19 19:21:32 +09:00]])
[383] [CITE@en[JSON parsing is not a `tryable` function]]
([[shs96c]]著, [TIME[2017-08-30 21:02:11 +09:00]])
[385] [CITE@en[Define parse JSON from bytes]]
([[annevk]]著, [TIME[2017-09-29 22:54:34 +09:00]])
[386] [CITE@en[Define parse JSON from bytes by annevk · Pull Request #156 · whatwg/infra]]
([TIME[2017-09-30 18:34:50 +09:00]])
[394] [CITE@en[Use Infra for JSON parsing]]
([[annevk]]著, [TIME[2017-09-29 21:18:40 +09:00]])
[395] [CITE@en[Use Infra for JSON parsing by annevk · Pull Request #610 · whatwg/fetch]]
([TIME[2017-10-06 15:01:39 +09:00]])
[396] [CITE@en[Use Infra for JSON parsing by annevk · Pull Request #153 · whatwg/xhr]]
([TIME[2017-10-06 15:03:47 +09:00]])
[397] [CITE@en[Parse JSON from bytes · Issue #619 · w3c/manifest]]
([TIME[2017-10-06 15:04:17 +09:00]])
[401] [CITE@en[Meta: export FormData's concepts]]
([[annevk]]著, [TIME[2017-10-11 18:23:54 +09:00]])
[FIG(quote)[
[FIGCAPTION[
[402] [CITE[Safari 10 の WebDriver ネイティブサポート - Qiita]]
([TIME[2017-12-01 20:47:39 +09:00]])
]FIGCAPTION]
> SafariDriverサーバーの スクリーンショットを取得するWebDriver API で返ってくるBASE64データが、ChromeDriverサーバーやGeckoDriverサーバーなどと違って、スラッシュ記号がエスケープされた状態になっています。これはJSON仕様としては正しい(エスケープしてもしなくてもいい)実装で、公式クライアントライブラリーもこれに対応して正しくスクリーンショットのデータを取得できる状態になっています。
]FIG]
[FIG(quote)[
[FIGCAPTION[
[403] [CITE[Standard ECMA-404]]
([TIME[2017-12-06 18:21:33 +09:00]])
]FIGCAPTION]
> 2nd edition (December 2017)
]FIG]
[404] [CITE['''['''Json''']''' Corrected Announcement: STD 90, RFC 8259 on The JavaScript Object Notation (JSON) Data Interchange Format]]
([TIME[2017-12-14 07:21:47 +09:00]])
[405] [CITE['''['''Json''']''' '''['''Editorial Errata Reported''']''' RFC8259 (5210)]]
([TIME[2017-12-19 02:52:28 +09:00]])
[REFS[
-
[325]
[CITE@en[[[RFC 8259]]: The JavaScript Object Notation (JSON) Data Interchange Format]], [TIME[2022-09-03T12:55:13.000Z]]
-
[326]
[CITE[RFC Errata Report » [[RFC Editor]]]], [TIME[2022-09-03T12:55:26.000Z]]
-
[353]
[CITE[[[Diff]]: rfc7159.txt - rfc8259.txt]], [TIME[2022-09-03T13:00:16.000Z]]
]REFS]
[408] >>405
[[STD]] に進めることが目的の改訂だったはずなのに、
その肝心の [[STD]] 番号を書き忘れるとか、
相変わらず [[JSON]] の [[RFC]] は不遇だなwww
[409] こんな初歩的なミスばかりしている [[RFC Editor]] は一体何の仕事してる人達なんですか?
[406] [CITE['''['''Json''']''' WG Action: Conclusion of Javascript Object Notation Update (JSONBIS)]]
([TIME[2017-12-29 03:50:11 +09:00]])
[407] [CITE['''['''Json''']''' '''['''Technical Errata Reported''']''' RFC8259 (5218)]]
([TIME[2018-01-01 23:50:01 +09:00]])
[410] [CITE@en[Move JavaScript and JSON MIME types from HTML]]
([[domenic]]著, [TIME[2018-02-06 06:27:33 +09:00]])
[411] [CITE@en[Move JavaScript and JSON MIME types from HTML by domenic · Pull Request #58 · whatwg/mimesniff]]
([TIME[2018-02-17 18:31:21 +09:00]])
[412] [CITE@en[Editorial: update usage of the MIME Sniffing Standard]]
([[domenic]]著, [TIME[2018-02-17 03:42:58 +09:00]])
[413] [CITE@en[Editorial: update usage of the MIME Sniffing Standard by domenic · Pull Request #3455 · whatwg/html]]
([TIME[2018-02-17 18:46:30 +09:00]])
[414] [CITE@en[JSON-serialized client data is wrong · Issue #712 · w3c/webauthn]]
([TIME[2018-03-05 17:37:19 +09:00]])
[415] [CITE@en[Fix #712: Refer to the JSON object as %JSON% by emlun · Pull Request #813 · w3c/webauthn]]
([TIME[2018-03-05 17:37:41 +09:00]])
[416] [CITE[RFC Errata Report » RFC Editor]]
([TIME[2018-04-10 14:05:44 +09:00]])
[417] [CITE['''['''Json''']''' '''['''Technical Errata Reported''']''' RFC8259 (5355)]]
([TIME[2018-05-10 15:50:03 +09:00]])
[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]).
と書かれていました。 [SRC[>>353]]
[[RFC 7159]] も [[RFC 8259]] もまったくの新文書ではなく旧版からの改訂ですし、
それぞれの出版前に何度も [[I-D]] を公開して改訂を続けています。
その過程で[[著者]]らはもちろん、 [[WG]]、 [[IESG]]、 [[RFC Editor]]
と膨大な数の人々が何度も繰り返しチェックしています。
それだけの体制で、この程度の長さの文書で2件も誤りがあるのは多すぎます。
それを「少数」だと反省の色を見せない [[RFC 7159]] もちょっとどうかと思うのですが、
それを踏襲した [[RFC 8259]] が 2 + 4 件あってもまだ「少数」
だと言い張っているのは図々しい。
そんな編集態度だから、 [[RFC 8259]] にも「少数」の誤りが報告されたのは必然という他ありません。
[545]
次の [[RFC]] では 2 + 4 + 6 件で「少数」と言い張るのをみたいですねw
でも現時点で報告済5件、却下1件なので、これ以上増えるのは難しいかなあ
-*-*-
[534]
旧版 [[RFC 7159]] は、
[[Informative References]]
として
[[ES5.1]] と [[ECMA-404]] 旧版を参照しつつ、
[[JSON]] はそれらでも説明されている、と述べていました。
更に古い [[RFC 4627]] も含め、すべての [[JSON]]
仕様の構文は一致している、と述べていました。
[SRC[>>353]]
これは嘘で、4仕様のうち [[RFC 4627]] は明らかに違う構文でした。
[535]
新版 [[RFC 8259]] はその記述を改め、
[[ECMA-404]] 新版を
[[Normative References]]
に含めました。その意味を次のように説明していました。
[SRC[>>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. [SNIP[]]
[536] これによると、通常は [[normative reference]]
とは実装者が参照元を理解するために参照する必要があるような文書を意味するところ、
本件においては [[RFC 8259]] と [[ECMA-404]] の用語「JSON text」
の定義に不整合がないことを協調するためのものであるというのです。
[537]
これはなかなか独創的な [[normative reference]] の使い方です。
[539] 更に [[RFC 8259]] は
- [540] 両者の [[JSON]] 文法は同じで、説明の方法が違うのみであること
- [541] 両者に違いが見つかった場合には、双方協力して解決を目指すこと
を明記しています。 [SRC[>>353]]
これは [[ECMA-404]] 新版側にあるのと同内容です (>>491)。
[542]
ただし、
[[相互運用性]]の最大化のため [[RFC 8259]] が避けることを[RUBYB[推奨][recommend]]する[RUBYB[いくつかの慣習][several practices]]を
[[ECMA-404]]
は[RUBYB[認めている][allows]]
[SRC[>>353]]
とし、 [[RFC 8259]] 独自の「推奨」の存在を正当化しています。
[543]
ところで [[ECMA-404]] と [[RFC 8259]] の構文が同じもので、
[[RFC 8259]] が一定の「推奨」をしているだけなら、
それは [[RFC 8259]] も「認めて」いる (が推奨はしていない) のでなければなりません。
[[RFC 8259]] が「認め」ないとは書いていませんから、
嘘ではないのですが、ミスリーディングです。
** ECMA-404 の改訂
[460]
[TIME[平成29(2017)年12月][2017-12]]に
[CITE[[[ECMA-404]]]]
の改訂版である第2版が出版されました。
[SRC[>>4042]]
[461]
[[IETF]] の [[RFC 8259]] に合わせて出版されたもので、
第1版になかった次のような歴史の説明が追加されました。
>
JSON was first presented to the world at the [CODE[JSON.org]] website in 2001. A definition of the JSON syntax was
subsequently published as IETF RFC 4627 in July 2006. ECMA-262, Fifth Edition (2009) included a normative
specification of the JSON grammar. This specification, ECMA-404, replaces those earlier definitions of the
JSON syntax. Concurrently, the IETF published RFC 7158/7159 and in 2017 RFC 8259 as updates to RFC
4627. The JSON syntax specified by this specification and by RFC 8259 are intended to be identical.
[462]
[[IETF]] の [[RFC]] による定義が存在することを認めています。
(第1版は [CODE[JSON.org]] の部分しか書いていませんでした。 [SRC[>>4041]])
[463]
その上で、
[CITE[[[RFC 4627]]]] と [CITE[[[ES5]]]]
が
[CITE[[[ECMA-404]]]]
によって置き換えられたという
[[ECMA]]
側の認識を表明しています。
[464]
また、 [CITE[[[ECMA-404]]]] と [CITE[[[RFC 8259]]]]
が規定する [[JSON]] 構文は同等 (identical) を意図 (intended)
しているとの見解を表明しています。
[491]
新版は旧版と違って [[Normative References]] に
[[RFC 8259]]
を挙げています。そして、
- [492] 両者の [[JSON]] 文法は同じで、[[形式]]化の方法が違うのみであること
- [493] 両者に違いが見つかった場合には、双方協力して解決を目指すこと
を述べています。
[SRC[>>4042 3]]
([[RFC 8259]] 側にも同じことが書かれています。 >>539)
[494]
[CITE[[[RFC 8259]]]]
が「同等」の構文以外に独特の内容を多く含んでいることについては、
- [495] [[RFC 8259]] は様々な意味的制限も定義している (>>489)
- [496] しかしそれらは [[ECMA-404]] にとっては[RUBYB[[[規定]]の一部ではない][not normative]]
としています。
[SRC[>>4042]]
[465]
[[ECMA]] は [[IETF]] を完全に無視しても良かったはずですが、
歩み寄りの姿勢を見せています。
そして双方協力関係を保ち両仕様書の内容を同期させる、
との合意事項を明文化して示しています。
[497]
ただし [[ECMA]] は [[IETF]] の独自規定は存在に言及するにとどめ、
それを採用するまでには至っていません。 [[IETF]] の独自規定は採用してしまうと本来の
[[JSON]] と非互換になってしまいますから、当然の判断でしょう。
[498]
そうなると「Normative References」の1つに挙げられているのはおかしなことです。
文法は技術的に同等の内容で、
それ以外は不採用なら、
[[ECMA-404]] の規定に
[[RFC 8259]]
は何ら影響を与えないのですから、わざわざ参照する必要はないのです。
それでもわざわざこの改訂で ([[non-normative]] な reference でもなく) 追加したのは、
[[政治的]]判断と推測するほかありません。
[538]
そしてまさしく [[IETF]] 側は[[政治的]]判断だと明言しています (>>537)。
**
[FIG(quote)[
[FIGCAPTION[
[419] [CITE@EN-US[OData JSON Format Version 4.01]]
([TIME[2018-01-31 02:00:00 +09:00]])
]FIGCAPTION]
> 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.
]FIG]
[420] [CITE@en[A dictionary inheriting from a non-JSON type can't be a JSON type. (#571]]
([[bzbarsky]]著, [TIME[2018-07-18 00:26:11 +09:00]])
[421] [CITE@en[Is a dictionary which has an inherited dictionary with a non-JSON-type member a JSON type? · Issue #555 · heycam/webidl]]
([TIME[2018-07-18 15:27:53 +09:00]])
[422] [CITE@en[A dictionary inheriting from a non-JSON type can't be a JSON type. by bzbarsky · Pull Request #571 · heycam/webidl]]
([TIME[2018-07-18 15:28:16 +09:00]])
[426] [CITE@en[Add "serialize JSON to bytes" algorithm]]
([[equalsJeffH]]著, [TIME[2018-08-03 06:05:16 +09:00]])
[427] [CITE@en[Infra lacks a "JSON stringify and UTF-8 encode to bytes" operation · Issue #193 · whatwg/infra]]
([TIME[2018-08-09 17:25:32 +09:00]])
[428] [CITE@en[add 'JSON stringify and UTF-8 encode to bytes' algorithm by equalsJeffH · Pull Request #207 · whatwg/infra]]
([TIME[2018-08-09 17:26:09 +09:00]])
[429] [CITE@en[Editorial: Add %JSONStringify% intrinsic object by equalsJeffH · Pull Request #1272 · tc39/ecma262]]
([TIME[2018-08-09 17:27:18 +09:00]])
[430] [CITE@en[Use final name for "serialize JSON to bytes" by domenic · Pull Request #1024 · w3c/webauthn]]
([TIME[2018-08-09 17:27:47 +09:00]])
[431] [CITE@en[proposal-json-superset/README.md at master · tc39/proposal-json-superset]]
([TIME[2019-01-30 20:35:23 +09:00]])
[432] [CITE@en[CORB: protecting certain nosniff and 206 responses]]
([[anforowicz]]著, [TIME[2018-05-17 16:24:03 +09:00]])
[448] [CITE@en[Add "parse JSON into Infra values"]]
([[domenic]], [TIME[2019-05-11 00:47:58 +09:00]], [TIME[2021-04-12T05:29:04.000Z]])
[453] [CITE@en[Add "parse JSON into maps and lists" by domenic · Pull Request #249 · whatwg/infra]]
([TIME[2021-04-12T06:08:00.000Z]])
[23]
[[ECMA-404]] を[[日本語]]に翻訳したものが [DFN[JIS X 3061:2021]]
となっています。
[24] [CITE@en[Working with JSON data in Standard SQL | BigQuery | Google Cloud]]
([TIME[2022-01-06T01:22:52.000Z]], [TIME[2022-01-09T11:56:41.887Z]])