JSONもどき

JSONの変種

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

JSON を称する非 JSON

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

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

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

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

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

[5] Field Reports 1.4 の新機能 (2) ― Unicode拡張漢字対応 ― - 合同会社フィールドワークス, 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 の派生仕様が存在しています。

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

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

[455] Should we consolidate the human-readable JSON efforts? · Issue #190 · json5/json5 · GitHub, https://github.com/json5/json5/issues/190

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

JSON マーケティング

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

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

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

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

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

JSON と JavaScript との違い

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

[119] >>27 より

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

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

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

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

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

JSON と YAML の関係

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

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

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

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

関連

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

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

メモ