[2] JSON と似ていて JSON でない JSONの変種はいろいろあります。
[258]
かつて JSON を規定していた RFC が拡張された JSON に対応することを認めていたためもあって
(現行仕様では認められていません)
" で括られないことがあります。var name = 」のような文字列がつくことがあります。, が余分に挿入されることがあります。)]}」のようなごみを挿入することがあります。
Source Map はこれを明示的に認めています。JSON::XS は、符号化時に数値としての inf や nan が与えられると引用符のない
inf や nan を出力します。 (復号はできず構文エラーになります。) json は NaN, Infinity, -Infinity
を出力します。
>>7json は allow_nan オプションを有効にすると
NaN, Infinity, -Infinity
を出力します。
>>7JSON::XS は tagged value
と称して Perlモジュールとの対応付け情報が含まれた値を記述する構文を導入しています。
(ただし標準では無効になっています。)[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 だけを生成すること」 は、 相互運用性はもちろん、セキュリティーのためにも重要です。
[6] もちろん、「JSON であることが要求されていない場面で、 「JSON のようだけど JSON でないもの」を 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文字も受け付けられるように独自改造を行なっています。
[267] JSON と互換性のあるもの、ないもの、 JSON 自体で表現できないデータモデルを JSON として表現する方法を定義するもの、 JSON に触発されただけで実際には JSON と関係性が薄いもの、JSON のプロファイルも含め、次のような名前がついた 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
[4] JSON 以後のデータ形式にとって、 JSON との良好な関係性は宣伝の重要なポイントとなり得るようです。 JSON から派生した形式はもちろんのこと、 JSON と親類関係にない次のようなデータ形式も、 宣伝文句として JSON を使っています。
[10] JSON からの派生形式の多くが JSON を名前に含んでいます (>>454)。
[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 + α のようなものと称しています。 テキストファイルでこそあれ、 構文もデータモデルも互換性はありません。
[11] こうした宣伝は誤解と混乱を招くことがあります。
[105] JavaScript の文字列リテラルでは U+2028 や U+2029
を直接記述することは認められていませんでしたが、 JSON では認められています
>>36 15.12.2。
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 とは非互換であることになります。
[176] Perl コミュニティーの一部など、 JSON 以前に YAML が広く用いられていた人達の中には、 JSON は YAML の部分集合であるとして、 YAML の実装を元にした JSON の実装が行われていました。