9.txt

[2] [[JSON]] と似ていて [[JSON]] でない [DFN[JSONの変種]]はいろいろあります。


* JSON を称する非 JSON

[258] 
かつて [[JSON]] を規定していた [[RFC]] が拡張された [[JSON]] に対応することを認めていたためもあって
[WEAK[(現行仕様では認められていません)]]
[SEE[ [[JSON]] ]]、また [[JSON]]
が広い分野で用いられていることもあり、いろいろな [[JSONの変種]]が「[[JSON]]」
と呼ばれていることがあります。


- [22] [[JSONP]] が [[JSON]] として扱われることがあります。
- [295] [[改行区切りJSON列]]その他の [[JSON]] ストリームが [[JSON]] として扱われることがあります。
- [23] [[オブジェクト]]の[[特性名]]を表す[[文字列リテラル]]が [CODE(char)[[["]]]] で括られないことがあります。
- [24] [[JSON]] の前に「[CODE(JS)[[[var]] name = ]]」のような[[文字列]]がつくことがあります。
- [25] [[YAML]] の [[serializer]] によって実際には [[JSON]] ではない [[YAML]] が [[JSON]] であるとして出力されることがあります (>>176)。
- [87] [[JavaScript]] の[[注釈]]が含まれることがあります。
-- /* ... */
-- // ...
- [88] [[配列]]や[[オブジェクト]]の最後の[[メンバー]]の後に [CODE(char)[[[,]]]] が余分に挿入されることがあります。
- [110] 果ては[[関数リテラル]]が含まれることすらあります。
- [112] # ... のような注釈が使われることがあります。
- [117] 0x0000 のような数値の16進数表記が用いられることがあります。
- [158] [[XSSI]] 防止のために本来の [[JSON]] データの前に「[CODE[)]}]]」のようなごみを挿入することがあります。
[[Source Map]] はこれを明示的に認めています。
- [165] [[Perl]] モジュールである [CODE(perl)@en[[[JSON::XS]]]] は、[[符号化]]時に数値としての [[inf]] や [[nan]] が与えられると[[引用符]]のない
[CODE[inf]] や [CODE[nan]] を出力します。 ([[復号]]はできず構文エラーになります。) [TIME[2014-01-09T11:35:59.600Z]]
- [290] [[Perlモジュール]]である [CODE(perl)@en[[[JSON::XS]]]] は [[tagged value]]
と称して [[Perlモジュール]]との対応付け情報が含まれた値を記述する構文を導入しています。
(ただし標準では無効になっています。)
-- [CITE[JSON::XS]] ([TIME[2015-02-21 19:32:42 +09:00]] 版) <http://pod.tst.eu/http://cvs.schmorp.de/JSON-XS/XS.pm#OBJECT_SERIALISATION>
-- [CITE[JSON::XS]] ([TIME[2015-02-21 19:33:08 +09:00]] 版) <http://pod.tst.eu/http://cvs.schmorp.de/JSON-XS/XS.pm#TAGGED_VALUE_SYNTAX_AND_STANDARD_JSO>
- [16] [[文字列リテラル]]に生の[[改行]]が含まれることがあります。
-- [CITE@ja[golang で Invalid な Json をパースした話 - ちなみに]] ([TIME[2016-08-24 16:30:03 +09:00]] 版) <http://sixeight.hatenablog.com/entry/2014/04/16/213243>


[457] 
現在の仕様書である [[ECMA-404]] は、このような拡張の存在を認めていません。
適合する処理器は非標準の構文を受理するべきではないとしています。
従って、こうした[[JSONの変種]]は、かつて [[JSON]]
と呼ばれ使われることが少なかったとはいえ、今後は使うべきではなく、
[[JSON]] と呼ぶべきでもありません。


[440] 
[[JSON]]
の[[応用]]の1つである
[[JWS]] 
を規定する
[[RFC 7515]]
は、[[構文解析器]]が [[RFC 7159]] の構文に反するものを拒絶しなければ[MUST[ならない]]としています。
[SRC[>>439]]

[441] [CODE[{"a":"b"}c]] のように余分なデータが含まれるものも不正な入力としなければならないことが特に注意されています。
[SRC[>>439]]

[458] 
「[[JSON]] と呼ばれるものが [[ECMA-404]] の定める [[JSON]] であること」
「[[JSON]] を解釈する実装が [[ECMA-404]] の定める [[JSON]] だけを受理すること」
「[[JSON]] を生成する実装が [[ECMA-404]] の定める [[JSON]] だけを生成すること」
は、
[[相互運用性]]はもちろん、[[セキュリティー]]のためにも重要です。


[REFS[
- [439] [CITE@en[[[RFC 7515]] - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]] <https://tools.ietf.org/html/rfc7515#section-10.12>
]REFS]


[5] [CITE@ja-JP[Field Reports 1.4 の新機能 (2) ― Unicode拡張漢字対応 ― - 合同会社フィールドワークス]], [TIME[2023-09-05T14:56:48.000Z]] <https://www.field-works.co.jp/2011/12/15/field-reports-1-4-%E3%81%AE%E6%96%B0%E6%A9%9F%E8%83%BD-2-unicode%E6%8B%A1%E5%BC%B5%E6%BC%A2%E5%AD%97%E5%AF%BE%E5%BF%9C/>

> Field Reportsでパラメータをファイルを介して渡す際に利用するJSONでは,規格として用意されているのは16ビット形式の“\uhhhh”のみです。Field Reportsでは,JSONの規格からは外れますが“\Uhhhhhhhh”形式の32ビットUnicode文字も受け付けられるように独自改造を行なっています。 


* JSON に影響されたデータ形式

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

[FIG(short list)[ [454] [[JSON]] からの派生
- [[BSON]]
- [[B-JSON]]
- [[I-JSON]]
- [[JSON-B]]
- [[JSON-C]]
- [[JSON+C]]
- [[JSON-D]]
- [[JSON-L]]
- [[JSON5]]
- [[JSON6]]
- [[Smile]]
- [[Universal Binary JSON]] ([[UBJSON]])
- [[JSYNC]]
- [[MongoDB Extended JSON]]
- [[JSONx]]
- [[XJSON]]
- [[PSON]]
- [[Jsonnet]]
- [[hjson]]
- [[EXI for JSON]]
- [[JCR]]
- [[MSON]]
- [[NSON]]
- [[HOCON]]
- [[CSON]]
- [[EXI for JSON]]
- [[TJSON]]
- [[Oracle JSON lax syntax]]
- [[EJSON]]
- [[JSCN]]
- [[JSON Canonical Form]]
- [[JSON Canonicalization Scheme]]
- [[Canonical JSON (NPM)]]
- [[Canonical JSON (OLPC)]]
- [[jsonc]]
- [[ICL]]
- [[STON]]
- [[JSONext]]
- [[JSOX]]
- [[ESON]]
- [[CANON]]
]FIG]


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

[459] 
これらの [[JSON]] の変種の中には、 [[JSON]] データが与えられた時にそれを処理できることをメリットの1つとして謳っているものもあります
(がそうではないものもあります)。



[455] 
[CITE@en[Should we consolidate the human-readable JSON efforts? · Issue #190 · json5/json5 · [[GitHub]]]], [TIME[2021-09-21T05:50:49.000Z]] <https://github.com/json5/json5/issues/190>

[456] 
[[JSON]] がいかに画期的で1度限りの成功だったかがわかるなあ。

* JSON マーケティング

[4] 
[[JSON]]
以後の[[データ形式]]にとって、
[[JSON]]
との良好な関係性は宣伝の重要なポイントとなり得るようです。
[[JSON]]
から派生した形式はもちろんのこと、
[[JSON]]
と親類関係にない次のような[[データ形式]]も、
宣伝文句として
[[JSON]]
を使っています。


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

[21] [[MessagePack]] は [[JSON]] の派生仕様ではなく互換性はありませんが
([[テキストファイル]]ですらありません。)、
「It's like JSON. but fast and small.」と謳っています。各言語のライブラリーが存在し、
それなりに広く利用されているようですが、 [[JSON]] ほどとは言えなそうですし、
対象分野も必ずしも近いとは言えなそうです。少なくても [[Web API]] 等の[[疎結合]]な [[API]]
を通じた情報交換目的で [[MessagePack]] が [[JSON]] と競合しているようには見えません。
しかし普及の障害でありつつ踏み台にもし得る存在として [[JSON]]
を強く意識していることがわかります。


[460] 
[[YAML]]
は歴史的には [[JSON]] より古いですが、 [[JSON]] との「互換性」
が特徴に謳われたり、
それを理由に推したりする人がいます
(>>176)。

[3] 
[[Dhall]]
は
[[JSON]] + α
のようなものと称しています。
[[テキストファイル]]でこそあれ、
構文もデータモデルも互換性はありません。




* JSON と JavaScript との違い

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

[REFS[
- [1] [CITE[[[ECMAScript]]]]
-- [36] [CSECTION[The JSON Object]]
- [28] [CITE[JSON: The JavaScript subset that isn't — Timeless]]
([TIME[2011-05-16 04:05:34 +09:00]] 版)
<http://timelessrepo.com/json-isnt-a-javascript-subset>
- [27] [CITE[JSON::XS - search.cpan.org]] ([TIME[2011-04-15 12:50:01 +09:00]] 版) <http://search.cpan.org/dist/JSON-XS/XS.pm#JSON_and_ECMAscript>
]REFS]

[FIG(quote)[
[FIGCAPTION[
[119] >>27 より
]FIGCAPTION]

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

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

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

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

* JSON と YAML の関係

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

[26] しかし [[JSON]] は [[YAML]] の[[部分集合]]であるとの主張は'''嘘'''とされています
[SRC[>>177]]。

[REFS[
- [177] [CITE[JSON::XS - search.cpan.org]] ([TIME[2011-04-15 12:50:01 +09:00]] 版) <http://search.cpan.org/dist/JSON-XS/XS.pm#JSON_and_YAML>
]REFS]

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

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

[REFS[
- [18] [CITE@ja[改行を含んだJSON - 酒日記 はてな支店]] ([TIME[2016-08-24 16:32:21 +09:00]] 版) <http://sfujiwara.hatenablog.com/entry/20060620/1150797461>
]REFS]



* 関連

[SEE[ JSON を使ったプロトコルやアプリケーションは [[JSONの応用]] ]]

[SEE[ JSON を使ったデータストリーミングや改行区切りJSONは [[JSONストリーム]] ]]

* メモ