[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]] - [8] [[Python]] の [CODE[json]] は [CODE[NaN]], [CODE[Infinity]], [CODE[-Infinity]] を出力します。 [SRC[>>7]] - [9] [[Ruby]] の [CODE[json]] は [CODE[allow_nan]] オプションを有効にすると [CODE[NaN]], [CODE[Infinity]], [CODE[-Infinity]] を出力します。 [SRC[>>7]] - [290] [[Perlモジュール]]である [CODE(perl)@en[[[JSON::XS]]]] は [[tagged value]] と称して [[Perlモジュール]]との対応付け情報が含まれた値を記述する構文を導入しています。 (ただし標準では無効になっています。) -- [CITE[JSON::XS]] ([TIME[2015-02-21 19:32:42 +09:00]] 版) -- [CITE[JSON::XS]] ([TIME[2015-02-21 19:33:08 +09:00]] 版) - [16] [[文字列リテラル]]に生の[[改行]]が含まれることがあります。 -- [CITE@ja[golang で Invalid な Json をパースした話 - ちなみに]] ([TIME[2016-08-24 16:30:03 +09:00]] 版) [457] 現在の仕様書である [[ECMA-404]] は、このような拡張の存在を認めていません。 適合する処理器は非標準の構文を受理するべきではないとしています。 従って、こうした[[JSONの変種]]は、かつて ([[平成時代]]頃) [[JSON]] と呼ばれ使われることが少なくもなかったとはいえ、今後は使うべきではなく、 [[JSON]] と呼ぶべきでもありません。 [SEE[ [[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]] だけを生成すること」 は、 [[相互運用性]]はもちろん、[[セキュリティー]]のためにも重要です。 [6] もちろん、「[[JSON]] であることが要求されて''いない''場面で、 「[[JSON]] のようだけど [[JSON]] でないもの」を '''[[JSON]] と呼ばずに'''使うこと」 は、今後も自由です。 用途に応じた適切な道具を使うことは技術者の責務で、虚偽の言明をしないことは人間の倫理です。 [19] [[JSON]] ではないのに [[JSON]] を称するものを利用する行為もまた、 虚偽の言明による混乱に加担する悪質な行為でありますから、 [[技術者倫理]]のもとに最大限回避することが求められます。 [REFS[ - [439] [CITE@en[[[RFC 7515]] - JSON Web Signature (JWS)]], [TIME[2020-03-29 16:13:43 +09:00]] - [7] [CITE@ja[JSONの小ネタと、JSONに対する拡張]], [TIME[2024-11-21T05:15:34.000Z]] ]REFS] [5] [CITE@ja-JP[Field Reports 1.4 の新機能 (2) ― Unicode拡張漢字対応 ― - 合同会社フィールドワークス]], [TIME[2023-09-05T14:56:48.000Z]] > 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]] [456] [[JSON]] がいかに画期的で1度限りの成功だったかがわかるなあ。 * JSON マーケティング [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] こうした宣伝は誤解と混乱を招くことがあります。 [EG[ [12] 例えば [[JSON5]] は [[JSON]] の新版のように誤解されることがありますし、 それを狙ったとしか思えない命名です。 ]EG] [13] 度を越したものは控えるべきですし、そうした技術や製品は採用しないのが[[技術者倫理]]というものでしょう。 [14] [CITE@en[Fast, Declarative, Reproducible, and Composable Developer Environments - devenv]], [TIME[2025-02-11T13:14:11.000Z]] >[B[ Simple JSON-like language]] > Declaratively define your development environment by toggling basic options. [15] >>14 例文見てもどこに [[JSON]] との共通性を見出したのか甚だ理解しがたい... [17] [CITE@ja[Xユーザーのデジタル競争の敗者さん: 「https://t.co/wYGEeUg6fPがNix言語のことを𝓢𝓲𝓶𝓹𝓵𝓮 𝓙𝓢𝓞𝓝-𝓵𝓲𝓴𝓮 𝓵𝓪𝓷𝓰𝓾𝓪𝓰𝓮って言ってて流石にライン超えだろって言ってる」 / X]], [TIME[午前2:43 · 2025年2月11日][2025-02-10T17:43:06.000Z]], [TIME[2025-02-11T06:33:13.000Z]] * JSON と JavaScript との違い [105] 当初 [[JavaScript]] の[[文字列リテラル]]では [CODE(char)[[[U+2028]]]] や [CODE(char)[[[U+2029]]]] を直接記述することは認められていませんでしたが、 [[JSON]] では認められています [SRC[>>36 15.12.2]]。 これが [[JavaScript]] と [[JSON]] の非互換性として問題になっていました。 [SEE[ [[U+2028]], [[JSON]] ]] [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]] 版) - [27] [CITE[JSON::XS - search.cpan.org]] ([TIME[2011-04-15 12:50:01 +09:00]] 版) ]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]] 版) ]REFS] ;; [70] 一部の人は真剣に [[YAML]] の[[部分集合]]であると主張しているようですが、 周囲からは冷ややかな目で見られています。また [[JSON]] 関係者からは相手にされていないようです。 [178] このため [[JSON]] であると称しながら実際には [[JSON]] ではない [[YAML]] のデータが存在しています。 [REFS[ - [18] [CITE@ja[改行を含んだJSON - 酒日記 はてな支店]] ([TIME[2016-08-24 16:32:21 +09:00]] 版) ]REFS] * 関連 [SEE[ JSON を使ったプロトコルやアプリケーションは [[JSONの応用]] ]] [SEE[ JSON を使ったデータストリーミングや改行区切りJSONは [[JSONストリーム]] ]] * メモ