JSON

JavaScript オブジェクト表記法
ファイル名の拡張子
.json
インターネットメディアの種類
アプリケーション/json
タイプコード文章
統一タイプ識別子 (UTI)パブリック.json
フォーマットの種類データ交換
からの拡張JavaScript
標準STD 90 ( RFC  8259)、ECMA-404 (PDF)、ISO/IEC 21778:2017
オープンフォーマットはい
Webサイトjson.org

JSON ( JavaScript Object Notation、発音/ ˈ s ən / ; または/ ˈ ˌ s ɒ n / ) は、人間が読めるテキストを使用して、以下で構成されるデータ オブジェクトを保存および送信するオープン標準ファイル形式およびデータ交換形式です。属性と値のペア配列(またはその他のシリアル化可能な値)。これは、サーバーとのWeb アプリケーションなど、電子データ交換でさまざまな用途に使用される一般的に使用されるデータ形式です

JSON は言語に依存しないデータ形式です。これはJavaScriptから派生したものですが、多くの最新のプログラミング言語には、JSON 形式のデータを生成および解析するコードが含まれています。JSON ファイル名には拡張子 が使用されます.json

Douglas Crockford は、 2000 年代初頭に JSON 形式を最初に指定しました。[1]彼とChip Morningstar は、 2001 年 4 月に最初の JSON メッセージを送信しました。

命名と発音

2017 年の国際標準(ECMA-404 および ISO/IEC 21778:2017) では、「JSON」は「 『ジェイソンアルゴノーツのように/ ˈ . s ə n /と発音される」と指定されています。[2] [3] ECMA-404 の初版 (2013 年) では、発音については言及されていませんでした。[4] UNIXおよび Linux システム管理ハンドブックには、「 JSON 形式を命名し推進したDouglas Crockford氏は、JSON 形式はジェイソンという名前のように発音されると言っています。しかしどういうわけか、技術コミュニティでは「JAY-sawn」の方が一般的になったようです」と述べられています。 。」[5]クロックフォードは2011年に、「それをどのように発音するかについては多くの議論があるが、私はまったく気にしない」と述べた。[6]

規格

RFC  4627 が 2006 年から「情報」仕様として利用可能になった後、JSON は 2013 年にECMA -404 として初めて標準化されました。[7] 2017 年に公開されたRFC 8259 は、インターネット標準STD 90 の現行バージョンであり、ECMA-404 との一貫性を保っています。[8]同年、JSON もISO / IEC 21778:2017 として標準化されました。[2] ECMAおよびISO / IEC標準では、許可される構文のみが説明されていますが、RFC ではセキュリティと相互運用性に関する考慮事項がいくつかカバーされています[9]

歴史

ダグラス・クロックフォード、ヤフービルにて (2007)

JSON は、2000 年代初期に主流だったFlashJavaアプレットなどのブラウザ プラグインを使用せずに、リアルタイムのサーバーからブラウザへのセッション通信プロトコルの必要性から生まれました。[10]

Crockford が最初に JSON 形式を指定し、普及させました。[11]この頭字語は、2001 年 3 月に Crockford らによって共同設立された会社、State Software に由来します。共同創設者は、標準のブラウザ機能を使用し、Web 開発者がステートフルな Web アプリケーションを作成するための抽象化層を提供するシステムを構築することに同意しました。これは、2 つのハイパーテキスト転送プロトコル(HTTP) 接続を開いたままにして、データがさらに交換されない場合に標準ブラウザのタイムアウトになる前にそれらをリサイクルすることにより、Web サーバーへの永続的な二重接続を実現していました。共同創設者らはラウンドテーブルディスカッションを行い、データ形式を JSML (JavaScript Markup Language) と呼ぶか JSON (JavaScript Object Notation) と呼ぶか、またそれをどのライセンスタイプで利用可能にするかを投票しました。JSON.org [12] Web サイトは 2001 年に開設されました。2005 年 12 月には、Yahoo! は、一部のWeb サービスをJSON で提供し始めました。[13]

JSON ライブラリの前身は、Communities.com [要出典] (州の共同創設者全員が以前この会社で働いていた) の Cartoon Network [要出典]のCartoon Orbitという子供向けデジタル資産取引ゲーム プロジェクトで使用されました。DHTML要素を操作するために独自のメッセージング形式を持つブラウザ側プラグインを使用しました(このシステムも 3DO によって所有されています[要出典] )。初期のAjax機能を発見すると、digiGroups、Noosh などはフレームを使用して、Web アプリケーションのビジュアル コンテキストを更新せずにユーザー ブラウザのビジュアル フィールドに情報を渡し、標準の HTTP、HTML、および JavaScript 機能のみを使用してリアルタイムのリッチな Web アプリケーションを実現しました。 Netscape 4.0.5 以降および IE 5 以降。Crockford 氏は、JavaScript がそのようなシステムのオブジェクトベースのメッセージング形式として使用できることを発見しました。このシステムは、Sun MicrosystemsAmazon.com、およびEDSに販売されました。

JSON はJavaScriptスクリプト言語のサブセット(具体的には、Standard ECMA -262 第 3 版 - 1999 年 12 月[14] )に基づいており、JavaScript で一般的に使用されますが、言語に依存しないデータ形式です。JSON データを解析して生成するコードは、多くのプログラミング言語ですぐに利用できますJSON の Web サイトには、JSONライブラリが言語ごとにリストされています。

2013 年 10 月、Ecma International はJSON 標準 ECMA-404 の初版を発行しました。[7]同年、RFC  7158 は ECMA-404 を参照として使用しました。2014 年に、RFC  7159 が JSON のインターネット使用の主な参照となり、RFC  4627 とRFC  7158 に取って代わりました (ただし、ECMA-262 と ECMA-404 は主な参照として維持されます)。2017 年 11 月、ISO/IEC JTC 1/SC 22 はISO/IEC 21778:2017 [2]を国際規格として発行しました。2017 年 12 月 13 日、インターネット エンジニアリング タスク フォースは、インターネット標準STD 90 の現行バージョンである RFC 8259 を発行し、RFC 7159 廃止ました。 [15] [16]

Crockford は、企業弁護士や過度に衒学的な人たちを嘲笑しながら、JSON ライブラリをオープンソース化するために、「ソフトウェアは悪ではなく善のために使用されるものとする」という条項を JSONライセンスに追加しました。一方で、オープンソース ソフトウェアフリー ソフトウェアには通常、使用目的の制限がないため、この条項により、 JSON ライセンスと他のオープンソース ライセンスとのライセンス互換性の問題が発生ました。[17]

構文

次の例は、人物を記述する可能な JSON 表現を示しています。

{ 
"first_name" : "John" "last_name" : "Smith" "is_alive" : true "age" : 27 "address" : { "street_address" : "21 2nd Street" "city" : "New York" , "state" : "NY" , "postal_code" : "10021-3100" }, "phone_numbers" : [ { "type" : "home" , "number" : "212 555-1234" }, { " type" : "office" "number" : "646 555-4567" } ]、"children" : [ "Catherine" "Thomas" "Trevor" ]、"配偶者" : null }   
   
   
   
   
     
     
     
     
  
   
    
       
       
    
    
       
       
    
  
   
    
    
    
  
   

文字コード

Crockford は当初、JSON は JavaScript と ECMAScript の厳密なサブセットであると主張していましたが、[18]彼の仕様では実際には、有効な JavaScript ではない有効な JSON ドキュメントが許可されています。JSON では、Unicode 行終端記号 U+2028 LINE SEPARATORおよびU+2029 PARAGRAPH SEPARATOR を引用符で囲まれた文字列内でエスケープせずに表示できますが、ECMAScript 2018 以前ではサポートされていません。[19] [20]これは、JSON が「制御文字」のみを禁止した結果です。移植性を最大限に高めるには、これらの文字をバックスラッシュでエスケープする必要があります。

オープン エコシステムでの JSON 交換はUTF-8でエンコードする必要があります。[8]エンコーディングは、基本多言語面(U+0000 から U+FFFF) の外側の文字を含む、完全な Unicode 文字セットをサポートします。ただし、エスケープする場合、それらの文字はUTF-16 サロゲート ペアを使用して書き込む必要があります。たとえば、絵文字文字U+1F610 😐 NEUTRAL FACE をJSON に含めるには、次のようにします。

{ "顔" : "😐" } // または{ "顔" : "\uD83D\uDE10" }   

   

JSON は、2019 年の言語改訂時点で ECMAScript の厳密なサブセットになりました。[20] [21]

データ型

JSON の基本的なデータ型は次のとおりです。

  • 数値: 小数部分を含むことができ、指数E 表記を使用できる符号付き 10 進数ですが、 NaNなどの非数値を含めることはできませんこの形式では、整数と浮動小数点は区別されません。JavaScript はすべての数値にIEEE-754 倍精度浮動小数点形式を使用します (後にBigInt [22]もサポートします)。ただし、JSON を実装する他の言語では数値を異なる方法でエンコードする場合があります。
  • String : 0 個以上のUnicode文字のシーケンス文字列は二重引用符で区切られ、バックスラッシュエスケープ構文をサポートします。
  • ブール値: いずれかの値true、またはfalse
  • Array : 0 個以上の要素の順序付きリスト。それぞれの要素は任意の型にすることができます。配列では、要素をカンマで区切った角括弧表記を使用します。
  • オブジェクト:名前 (キーとも呼ばれる) が文字列である名前と値のペアのコレクション。現在の ECMA 標準では、「JSON 構文は、名前として使用される文字列にいかなる制限も課さず、名前文字列が一意であることも要求せず、名前と値のペアの順序にいかなる重要性も割り当てません。」と規定されています。[23]オブジェクトは中括弧 で区切られ、カンマを使用して各ペアを区切ります。各ペア内ではコロン「:」文字がキーまたは名前とその値を区切ります。
  • null: 空の値、単語を使用null

構文要素 (値と句読点、ただし文字列値内では不可) の周囲または間に空白は許可され、無視されます。この目的では、スペース水平タブ改行復帰の4 つの特定の文字が空白とみなされます特に、バイト オーダー マークは、準拠する実装によって生成されてはなりません (ただし、JSON の解析時には受け入れられる可能性があります)。JSON にはコメントの構文がありません[24]

JSON の初期バージョン ( RFC 4627で指定されているものなど ) では、有効な JSON テキストはオブジェクトまたは配列型のみで構成されている必要があり、その中に他の型を含めることもできます。この制限はRFC 7158で削除され 、JSON テキストはシリアル化された値として再定義されました。

JSON の数値は、プログラミング言語内での表現に関しては依存しません。これにより、任意の精度の数値をシリアル化できますが、移植性の問題が発生する可能性があります。たとえば、整数値と浮動小数点値は区別されないため、実装によっては 、 、 を同じ数値として扱う場合もあれ4242.04.2E+1そうでない場合もあります。JSON 標準では、オーバーフローアンダーフロー、精度の損失、丸め、符号付きゼロなどの実装の詳細に関する要件は設けられていませんが、「良好な相互運用性」のためにIEEE 754 binary64以上の精度を期待しないことが推奨されていますこれを正確に行うための公開されたアルゴリズムが存在するため、浮動小数点数のマシンレベルのバイナリ表現 (binary64 など) を人間が判読できる 10 進表現 (JSON の数値など) にシリアル化したり、その逆にシリアル化したりする際に、固有の精度の損失はありません。そして最適に。[25]

コメントは JSON から意図的に除外されました。2012 年に、Douglas Crockford は自身の設計上の決定を次のように説明しました。「JSON からコメントを削除したのは、人々が解析ディレクティブを保持するためにコメントを使用しているのが見えたためであり、これは相互運用性を破壊する可能性があります。」[24]

JSON では、データ構造内の最後の値の後のカンマである「末尾のカンマ」は許可されません。[26]末尾のカンマは、使いやすさを向上させるための JSON 派生の一般的な機能です。[27]

セマンティクス

JSON はデータ交換のための構文フレームワークを提供しますが、明確なデータ交換には、JSON 構文の特定の使用のセマンティクスについてプロデューサーとコンシューマーの間で合意することも必要です。[28]このような合意が必要となる一例は、 JSON 標準の一部ではないJavaScript 構文で定義されたデータ型(日付、関数、正規表現など)のシリアル化ですundefined[29]

相互運用性

RFC 8259 では、仕様上は合法ですが、相互運用性の問題を引き起こす可能性がある JSON 構文の特定の側面について説明しています。

  • 特定の JSON 実装は、オブジェクトまたは配列を表す JSON テキストのみを受け入れます。相互運用性を確保するには、JSON を交換するアプリケーションはオブジェクトまたは配列であるメッセージを送信する必要があります。
  • 仕様では、同じ名前の複数のメンバーを含む JSON オブジェクトが許可されています。重複した名前を持つオブジェクトを処理する実装の動作は予測できません。相互運用性を確保するために、アプリケーションは JSON オブジェクトを送信するときに重複した名前を避ける必要があります。
  • 仕様では、JSON オブジェクト内のメンバーの順序は重要ではないと特に規定されています。相互運用性を確保するために、アプリケーションは、解析ソフトウェアがその順序を可視化する場合でも、メンバーの順序に意味を割り当てないようにする必要があります。
  • 仕様では JSON 数値リテラルの大きさや精度に制限はありませんが、広く使用されている JavaScript 実装では、それらを IEEE754 の「binary64」量として保存します。相互運用性を確保するために、アプリケーションは、この方法では表現できない数値 (1E400 や 3.141592653589793238462643383279 など) の送信を避ける必要があります。
  • 仕様では JSON テキスト内の Unicode 文字の文字エンコーディングを制限していませんが、実装の大部分はUTF-8エンコーディングを前提としています。相互運用性を確保するために、アプリケーションは常に JSON メッセージのみを UTF-8 でエンコードする必要があります。
  • 仕様では、Unicode 文字を正しく表現しないバイト シーケンスの送信は禁止されていません。相互運用性を確保するには、アプリケーションはそのようなバイト シーケンスを含まないメッセージを送信する必要があります。
  • この仕様は、アプリケーションが Unicode 文字列を比較する方法を制約しません。相互運用性を確保するために、アプリケーションは常にこのような比較をコード単位ごとに実行する必要があります。

2015 年、IETF は、これらの相互運用性の問題を可能な限り回避するために JSON の構文と処理を制限する JSON の制限付きプロファイルである「I-JSON メッセージ フォーマット」について説明した RFC7493 を公開しました。

メタデータとスキーマ

JSON テキストの公式MIME タイプapplication/jsonは「 」[30]であり、最新の実装のほとんどはこれを採用しています。非公式の MIME タイプ " text/json" またはコンテンツ タイプ " text/javascript" も、従来の理由により、多くのサービス プロバイダー、ブラウザ、サーバー、Web アプリケーション、ライブラリ、フレームワーク、および API でサポートされています。注目すべき例には、Google Search API、[31] Yahoo!、[31] [32] Flickr、[31] Facebook API、[33] Lift フレームワーク[34]、Dojo Toolkit 0.4 などがあります。[35]

JSON スキーマは、検証、文書化、および対話制御のための JSON データの構造を定義するための JSON ベースの形式を指定します。これは、特定のアプリケーションに必要な JSON データのコントラクトと、そのデータを変更する方法を提供します。[36] JSON スキーマはXML スキーマ(XSD)の概念に基づいていますが、JSON ベースです。XSD と同様に、同じシリアル化/逆シリアル化ツールをスキーマとデータの両方に使用でき、自己記述的です。これは、IETF のインターネット ドラフト(現在は 2020-12 ドラフトであり、2021 年 1 月 28 日にリリースされました) で指定されています。 [37]さまざまなプログラミング言語で利用できるバリデーターがいくつかあり、[38]それぞれ適合レベルが異なります。標準のファイル名の拡張子は .json です。[39]

JSON 標準はオブジェクト参照をサポートしていませんが、JSON ベースのオブジェクト参照に関するIETFドラフト標準が存在します。[40]

用途

JSON-RPC は、XML-RPCまたはSOAPの代替として、JSON に基づいて構築されたリモート プロシージャ コール(RPC) プロトコルですこれは、少数のデータ型とコマンドのみを定義する単純なプロトコルです。JSON-RPC を使用すると、システムは通知 (応答を必要としないサーバーへの情報) と、順不同で応答できるサーバーへの複数の呼び出しを送信できます。

非同期 JavaScript および JSON (または AJAJ) は、 Ajaxと同じ動的 Web ページ手法を指しますが、データ形式はXMLではなくJSON です。AJAJ は、 Web ブラウザに読み込まれたWeb ページが新しいデータを要求できるようにする Web 開発技術です通常、その Web ページでのユーザーのアクションに応じて、サーバーから新しいデータがレンダリングされます。たとえば、ユーザーが検索ボックスに入力した内容が、クライアント側のコードからサーバーに送信され、サーバーはすぐに一致するデータベース項目のドロップダウン リストを返します。

JSON は、設定言語としてアドホックに使用されてきましたただし、コメントはサポートされていません。2012 年、JSON の作成者である Douglas Crockford は、構成言語として使用される JSON 内のコメントについて次のように述べています。「コメントがないと悲しむ人もいるとは思いますが、そうすべきではありません。注釈を付けたい設定ファイルです。先に進み、必要なコメントをすべて挿入してください。次に、JSON パーサーに渡す前に、 JSMin [41]にパイプ処理します。[24]

MongoDB は、ドキュメント指向データベースに JSON のようなデータを使用します

PostgreSQL や MySQL などの一部のリレーショナル データベースには、ネイティブ JSON データ型のサポートが追加されています。これにより、開発者は、JSON データを別のデータ形式に変換することなく、リレーショナル データベースに直接保存できるようになります。

安全性

JSON は JavaScript のサブセットであるため、JSON テキストを JavaScripteval()関数に渡しても安全であるという誤解が生じる可能性があります。これは安全ではありません。特定の有効な JSON テキスト、特にU+2028 LINE SEPARATORまたはU+2029 PARAGRAPH SEPARATORを含むテキストは、2019 年に JavaScript 仕様が更新されるまで有効な JavaScript コードではないため、古いエンジンではサポートされない可能性があります。[42]インターネットから任意のコードを実行することによって引き起こされる多くの落とし穴を回避するために、新しい関数がECMAScript の第 5 版に初めて追加されました[43]。2017 年の時点ですべての主要なブラウザーでサポートされています。サポートされていないブラウザの場合は、API 互換の JavaScript ライブラリがDouglas Crockfordによって提供されます。[44]さらに、TC39 提案「Subsume JSON」により、ECMAScript は言語の 2019 年改訂時点で厳密な JSON スーパーセットになりました。[20] [21]さまざまな JSON パーサー実装は、サービス拒否攻撃大量割り当ての脆弱性の 影響を受けています[45] [46] JSON.parse()

代替案

JSON は、XML のどちらの形式も一般的に使用される現実の状況で作成、読み取り、デコードを幅広くサポートしているため、オーバーヘッドの低い XML の代替として推進されています。[47] XML とは別に、例にはCSVや JSON のスーパーセットが含まれる可能性があります。Google プロトコル バッファーは、データ交換言語ではありませんが、この役割を果たすことができます。CBOR には JSON データ型のスーパーセットがありますが、テキストベースではありません。

XML

XML は、構造化データを記述し、オブジェクトをシリアル化するために使用されてきました。同じ種類のデータ交換を目的として、JSON と同じ種類のデータ構造を表すさまざまな XML ベースのプロトコルが存在します。データはいくつかの方法で XML にエンコードできます。タグのペアを使用した最も拡張的な形式では、JSON よりも (文字数の) 表現が大幅に大きくなりますが、データが属性と終了タグが に置き換えられた「短いタグ」形式で保存されている場合/>、表現は多くの場合ほぼ同じサイズになります。 JSON として、または少し大きいサイズで。ただし、XML 属性は単一の値のみを持つことができ、各属性は各要素に最大 1 回しか出現できません。

XML では (要素と属性を使用して) 「データ」と「メタデータ」を分離しますが、JSON にはそのような概念がありません。

もう 1 つの重要な違いは、値のアドレス指定です。JSON には単純な「キー」から「値」へのマッピングを持つオブジェクトがありますが、XML ではアドレス指定は「ノード」上で行われ、すべてのノードが XML プロセッサーを介して一意の ID を受け取ります。さらに、XML 標準では、xml:idユーザーが ID を明示的に設定するために使用できる共通属性を定義しています。

XML タグ名には、文字!"#$%&'()*+,/;<=>?@[\]^`{|}~やスペース文字を含めることはできません。また-.、 、または数字で始めることもできません。一方、JSON キーには (引用符とバックスラッシュをエスケープする必要がある場合でも) 含めることができます。[48]

XML 値は文字列であり、型安全性は組み込まれていませんXML にはスキーマの概念があり、強い型指定、ユーザー定義の型、事前定義されたタグ、および形式的な構造が許可され、XML ストリームの形式的な検証が可能になります。JSON にはいくつかの型が組み込まれており、JSON スキーマにも同様のスキーマ概念があります。

XML はコメントをサポートしますが、JSON はコメントをサポートしません。[49] [24]

スーパーセット

コメントやその他の機能のサポートは有用であると考えられており、これによりいくつかの非標準の JSONスーパーセットが作成されています。その中には、HJSON、[50] HOCON、および JSON5 (その名前にもかかわらず、JSON の 5 番目のバージョンではありません) があります。[51] [52]

YAML

YAMLバージョン 1.2 は JSON のスーパーセットです。以前のバージョンには厳密な互換性がありませんでした。たとえば、/バックスラッシュを使用してスラッシュをエスケープすること\は、JSON では有効ですが、YAML では無効でした。[53] YAML はコメントをサポートしますが、JSON はサポートしません。[53] [51] [24]

CSON

CSON (「筆記体オブジェクト表記法」) は、RFC 4627 で指定されている JSON ABNF文法への小さな文法追加として定義されています。YAML と同様、JSON の厳密なスーパーセットです。YAML とは対照的に、すべての CSON データは JSON に相互に変換できるため、JSON のみを理解するライブラリを引き続き使用でき、既存の JSON を変換する必要はありません。このような JSON の等価性に加えて、設計上の考慮事項は次のとおりです: [54]

  • 記述が簡単で、コメント、一重引用符と二重引用符の文字列、複数行の文字列、冗長なカンマをサポートしています。
  • 解析が容易で、 LL(1)であり、コンテキストの依存性を明示的に回避します。
  • JavaScript との非互換性は厳密ではないため、HTTP 上の CSON は避けてください。
  • 空白は重要ではありません。
  • YAML と同様、厳密な文字列であり、TOMLなどとは異なり、データ型はありません。追加のデータ型はデータ形式の仕事であってはならず、あらゆる実装が困難になります。

C、JavaScript、Python、Rust のライブラリが存在します。

ホーコン

HOCON (「Human-Optimized Config Object Notation」は、人間が読めるデータの形式であり、JSON のスーパーセットです。[55] HOCON の用途は次のとおりです:

  • これは主にPlay フレームワーク[56]と組み合わせて使用​​され、Lightbendによって開発されました
  • Akka.NET [57] [58]およびPuppetを介して .NET プロジェクトの構成形式としてもサポートされています[59]
  • TIBCO ストリーミング: [60] HOCON は、TIBCOストリーミング リリース 10 の時点で、TIBCO ストリーミング[61]製品ファミリー (StreamBase、LiveView、および Artifact Management Server)の主要な構成ファイル形式です。[62]
  • これは、Exabeam Advanced Analytics のいくつかのサブシステムの主要な構成ファイル形式でもあります。[63]
  • Jitsi はこれを「新しい」構成システムとして使用し、.properties -Files をフォールバックとして使用します[64] [65]

JSON5

JSON5 (「JSON5 データ交換形式」) は、JSON 構文の拡張機能であり、JSON と同様に、有効な JavaScript 構文でもあります。この仕様は 2012 年に開始され、2018 年にバージョン 1.0.0 で終了しました。[66] JSON 構文の主な違いは次のとおりです。

  • オプションの末尾のカンマ
  • 引用符で囲まれていないオブジェクトキー
  • 一重引用符と複数行の文字列
  • 追加の数値形式
  • コメント

JSON5 構文は、 SQLiteなど、一部のソフトウェアで JSON 構文の拡張機能としてサポートされています[67]

JSONC

JSONC (コメント付き JSON) は JSON5 のサブセットで、主に Microsoft によって使用されます。

  • 単一行コメント ( //) とブロック コメント ( /* */)をサポートします。
  • 末尾のカンマは受け入れられますが、推奨されておらず、エディターに警告が表示されます[68]

デリバティブ

いくつかのシリアル化形式は、JSON 仕様に基づいて、または JSON 仕様から構築されています。例としては次のものが挙げられます。

  • GeoJSON、単純な地理的特徴を表すために設計された形式[69] [70]
  • JSON→URL、JSON データ モデルの言語に依存しないデータ交換形式[71] [72]
  • JSON-LD 、 JSON を使用してリンクされたデータをエンコードする方法[73] [74]
  • JSON-RPC、JSON でエンコードされたリモート プロシージャ コール プロトコル[75]
  • JsonML 、 XMLと JSONの間のマッピングに使用される軽量マークアップ言語[76] [77]
  • スマイル(データ交換形式)[78] [79]
  • UBJSON、JSON を模倣するバイナリ コンピュータ データ交換形式ですが、必要なデータのバイト数は少なくなります[80] [81]

こちらも参照

参考文献

  1. ^ 「ダグラス・クロックフォード: JSON サーガ」. ユーチューブ。2011 年 8 月 28 日2022 年2 月 21 日に取得
  2. ^ abc "ISO/IEC 21778:2017" . ISO 2019 年7 月 29 日に取得
  3. ^ 「標準 ECMA-404 – JSON データ交換構文」(PDF)エクマ・インターナショナル。2017 年 12 月。p. 1、脚注2019 年10 月 27 日に取得
  4. ^ ECMA-404: JSON データ交換フォーマット(PDF) (第 2 版)。ジュネーブ: ECMA インターナショナル。2017 年 12 月。
  5. ^ ネメス、エヴィ; ガース・スナイダー。ハイン、トレント R. ホエーリー、ベン。ダン・マッキン(2017)。「19:ウェブホスティング」。UNIX および Linux システム管理ハンドブック(第 5 版)。アディソン・ウェスリー・プロフェッショナル。ISBN 97801342782922019 年10 月 29 日に取得
  6. ^ “Douglas Crockford: JSON Saga – トランスクリプト動画”. トランスクリプトビデオ.com 2019 年10 月 29 日に取得
  7. ^ ab 「JSON データ交換形式」(PDF)ECMAインターナショナル。2013年10月2023 年11 月 20 日に取得
  8. ^ ab ブレイ、T. (2017 年 12 月)。ブレイ、T (編)。「JavaScript Object Notation (JSON) データ交換形式」。IETF。土井:10.17487/RFC8259。S2CID  263868313 2018 年2 月 16 日に取得 {{cite journal}}:引用ジャーナルが必要です|journal=(ヘルプ)
  9. ^ ブレイ、ティム。「JSON Redux 別名 RFC7159」。進行中2014 年3 月 16 日に取得
  10. ^ “非公式 Java の歴史”. Edu4Java2014 年 5 月 26 日。2014 年 5 月 26 日のオリジナルからアーカイブ2019 年8 月 30 日に取得1996 年に Macromedia は、Java と ActiveX が残したスペースを占有する Flash テクノロジーを発表し、クライアント側のアニメーションの事実上の標準になりました。
  11. ^ "Douglas Crockford — JSON サーガ". ユーチューブ。2011 年 8 月 28 日2016 年9 月 23 日に取得
  12. ^ 「JSON」。json.org
  13. ^ Yahoo!. 「Yahoo! Web サービスでの JSON の使用」。2007 年 10 月 11 日のオリジナルからアーカイブ2009 年7 月 3 日に取得
  14. ^ ダグラス・クロックフォード(2009 年 5 月 28 日)。「JSONのご紹介」。json.org 2009 年7 月 3 日に取得これは、JavaScript プログラミング言語、標準 ECMA-262 第 3 版 (1999 年 12 月) のサブセットに基づいています。
  15. ^ ブレイ、ティム (2017 年 12 月). 「draft-ietf-jsonbis-rfc7159bis-04 の履歴」。IETF データトラッカーインターネット エンジニアリング タスク フォース2019 年10 月 24 日に取得2017-12-13 [...] RFC が公開されました
  16. ^ ブレイ、ティム (2017 年 12 月 13 日)。「RFC 8259 - JavaScript Object Notation (JSON) データ交換形式」。IETF データトラッカーインターネット エンジニアリング タスク フォース2019 年10 月 24 日に取得タイプ: RFC - インターネット標準 (2017 年 12 月; 正誤表)。RFC 7159 は廃止されます。STD 90とも呼ばれます
  17. ^ 「Apache と JSON ライセンス」LWN.net、Jake Edge 著 (2016 年 11 月 30 日)。
  18. ^ ダグラス・クロックフォード (2016 年 7 月 10 日)。「JavaScript の JSON」。2016年7月10日のオリジナルからアーカイブ2016 年8 月 13 日に取得JSON は、JavaScript のオブジェクト リテラル表記のサブセットです。
  19. ^ ホルム、マグナス (2011 年 5 月 15 日)。「JSON: そうでない JavaScript サブセット」。時代を超越したリポジトリ。2012 年 5 月 13 日のオリジナルからアーカイブ2016 年9 月 23 日に取得
  20. ^ abc "JSON の包含: すべての JSON テキストを ECMA-262 有効にする提案". エクマTC39。2019 年 8 月 23 日2019 年8 月 27 日に取得
  21. ^ ab "ステージ 4 に進む - tc39/proposal-json-superset". GitHub2018 年 5 月 22 日。
  22. ^ "BigInt - MDN Web ドキュメント用語集". モジラ2020 年10 月 18 日に取得
  23. ^ JSON データ交換構文(PDF) (第 2 版)。エクマインターナショナル2017 年 12 月。p. 3. JSON 構文は、名前として使用される文字列に制限を課さず、名前文字列が一意である必要もなく、名前と値のペアの順序に重要性を割り当てません。
  24. ^ abcde クロックフォード、ダグラス (2012 年 4 月 30 日)。「JSONでのコメント」。2015 年 7 月 4 日のオリジナルからアーカイブ2019 年8 月 30 日に取得私が JSON からコメントを削除したのは、人々がコメントを解析ディレクティブの保持に使用しているのを確認したためです。これは相互運用性を破壊する行為です。コメントがないことで悲しむ人もいるとは思いますが、そうすべきではありません。JSON を使用して構成ファイルを保持しており、そのファイルに注釈を付けたいとします。好きなコメントをすべて挿入してください。次に、それをJSON パーサーに渡す前に、JSMin を介してパイプ処理します。
  25. ^ マーク・アンドリスコ; ジャラ、ランジット。ラーナー、ソリン。「浮動小数点数の印刷 - 常に正しい方法」(PDF) 2019 年7 月 27 日に取得
  26. ^ "末尾のカンマ - JavaScript | MDN". 開発者.mozilla.org2023 年 9 月 12 日2023 年12 月 16 日に取得
  27. ^ 「JSON5」。json5. 2020年11月29日のオリジナルからアーカイブ2020 年12 月 16 日に取得
  28. ^ 「JSON データ交換構文」(PDF)エクマ・インターナショナル。2017 年 12 月2019 年10 月 27 日に取得JSON 構文は、完全なデータ交換の仕様ではありません。意味のあるデータ交換には、JSON 構文の特定の使用に付随するセマンティクスについて、プロデューサーとコンシューマーの間で合意する必要があります。JSON が提供するのは、そのようなセマンティクスを付加できる構文フレームワークです。
  29. ^ 「ECMAScript 2019 言語仕様」(PDF) . エクマ・インターナショナル。2019 年 6 月。2015年 4 月 12 日のオリジナル(PDF)からアーカイブ2019 年10 月 27 日に取得
  30. ^ 「メディアの種類」。イアナ.org 2015 年9 月 13 日に取得
  31. ^ abc "benschwarz による application/json & text/json のハンドル · プル リクエスト #2 · misslav/faraday-stack". GitHub 2015 年9 月 13 日に取得
  32. ^ "Yahoo!、JavaScript、および JSON". プログラマブルウェブ2005 年 12 月 16 日2015 年9 月 13 日に取得
  33. ^ "JSON リクエストでテキスト/JavaScript コンテンツを許可するようにする by jakeboxer · Pull Request #148 · AFNetworking/AFNetworking". GitHub 2015 年9 月 13 日に取得
  34. ^ "マスターでのリフト/Req.scala · リフト/リフト · GitHub". GitHub 2015 年9 月 13 日に取得
  35. ^ "legacy/branches/0.4/src/io の BrowserIO.js – Dojo Toolkit". dojotoolkit.org2016 年 1 月 10 日のオリジナルからアーカイブ2015 年9 月 13 日に取得
  36. ^ “JSON スキーマとハイパースキーマ”. json-schema.org 2021 年6 月 8 日に取得
  37. ^ "draft-handrews-json-schema-00 - JSON スキーマ: JSON ドキュメントを記述するためのメディア タイプ". json-schema.org/2021年1月28日2021 年6 月 8 日に取得
  38. ^ "JSON スキーマの実装". json-schema.org 2021 年6 月 8 日に取得
  39. ^ ブレイ、ティム (2017 年 12 月). ブレイ、T. (編)。「11. IANA に関する考慮事項」。RFC 8259: JavaScript Object Notation (JSON) データ交換形式IETF土井:10.17487/RFC8259。S2CID  263868313。
  40. ^ Zyp、クリス (2012 年 9 月 16 日)。ブライアン、ポール C. (編)。「JSON リファレンス:draft-pbryan-zyp-json-ref-03」。インターネット エンジニアリング タスク フォース
  41. ^ ダグラス、クロックフォード (2019 年 5 月 16 日)。「JSmin」2020 年8 月 12 日に取得JSMin [2001] は、JavaScript ファイルからコメントと不要な空白を削除する縮小ツールです。
  42. ^ "JSON: そうでない JavaScript サブセット". マグナス・ホルム。2012 年 5 月 13 日のオリジナルからアーカイブ2011 年5 月 16 日に取得
  43. ^ 「ECMAScript 第 5 版」(PDF)2011 年 4 月 14 日のオリジナル(PDF)からアーカイブ2011 年3 月 18 日に取得
  44. ^ "ダグラスロックフォード/JSON-js". GitHub2019年8月13日。
  45. ^ 「JSON におけるサービス拒否と安全でないオブジェクト作成の脆弱性 (CVE-2013-0269)」. 2016 年1 月 5 日に取得
  46. ^ "Microsoft .NET Framework JSON コンテンツ処理のサービス拒否の脆弱性". 2018年11月6日のオリジナルからアーカイブ2016 年1 月 5 日に取得
  47. ^ "JSON: XML に代わるファットフリーの手段". json.org 2011 年3 月 14 日に取得
  48. ^ 「XML 1.1 仕様」. ワールドワイドウェブコンソーシアム2019 年8 月 26 日に取得
  49. ^ サテルノス、カシミール (2014). Javascript と Java を使用したクライアントサーバー Web アプリ「オライリー・メディア株式会社」。p. 45.ISBN _ 9781449369316
  50. ^ エデルマン、ジェイソン; ロウ、スコット。オズワルト、マット。ネットワークのプログラマビリティと自動化オライリーメディアデータ表現には、YAML、YAMLEX、JSON、JSON5、HJSON、または純粋な Python のいずれかを選択できます。
  51. ^ ab マコームズ、セイン (2018 年 7 月 16 日)。「JSON が適切な構成言語ではない理由」。明晰なチャート2019 年6 月 15 日に取得
  52. ^ "HOCON (Human-Optimized Config Object Notation)". GitHub2019年1月28日2019 年8 月 28 日に取得主な目標は、JSON のセマンティクス (ツリー構造、タイプのセット、エンコード/エスケープ) を維持しながら、人間が編集できる構成ファイル形式としてより便利にすることです。
  53. ^ ab 「YAML はマークアップ言語ではありません (YAML™) バージョン 1.2」。yaml.org 2015 年9 月 13 日に取得
  54. ^ CSON、仕様、および README、最終更新日: 2021-07-01。
  55. ^ "マスターでのconfig/HOCON.md · lightbend/config". GitHub 2021 年8 月 5 日に取得
  56. ^ 「構成ファイル - 2.5.x」。www.playframework.com 2021 年8 月 5 日に取得
  57. ^ Akka.NET HOCON ドキュメント
  58. ^ “Akka.NET ドキュメント | Akka.NET ドキュメント”. getakka.net 2021 年8 月 5 日に取得
  59. ^ Puppet を使用した HOCON 設定ファイルの管理
  60. ^ 「StreamBase ドキュメント」。docs.streambase.com 2021 年8 月 5 日に取得
  61. ^ 「設定ガイド」。docs.streambase.com 2021 年8 月 5 日に取得
  62. ^ “StreamBase の新しい注目すべきアーカイブ”. docs.streambase.com 2021 年8 月 5 日に取得
  63. ^ Exabeam Advanced Analytics リリース ノート
  64. ^ JITSI プロジェクト。「構成フェーズ 1」。GitHub2021 年2 月 16 日に取得
  65. ^ JITSI プロジェクト。「参照.conf」。GitHub2021 年2 月 16 日に取得
  66. ^ "JSON5 データ交換形式" . 2022 年6 月 25 日に取得
  67. ^ SQLite。「JSON 関数と演算子」2023 年6 月 25 日に取得
  68. ^ "コメント付きの JSON - Visual Studio Code での JSON 編集". code.visualstudio.com 2023 年10 月 2 日に取得
  69. ^ バトラー、H. デイリー、M. ドイル、A. ギリース、ショーン。シャウブ、T. ハーゲン、ステファン (2016 年 8 月)。「RFC 7946 - GeoJSON 形式」。IETFデータトラッカー2022 年6 月 17 日に取得
  70. ^ 「GeoJSON」。geojson.org 2022 年8 月 7 日に取得
  71. ^ 「JSON→URLの指定」. 進行中2021 年4 月 9 日に取得
  72. ^ "URL 内の JSON". jsonurl 2022 年8 月 7 日に取得
  73. ^ "JSON-LD 1.1". ワールドワイドウェブコンソーシアム2020年7月16日2022 年6 月 17 日に取得
  74. ^ "JSON-LD - データをリンクするための JSON". json-ld.org 2022 年8 月 7 日に取得
  75. ^ "JSON-RPC". jsonrpc.org 2022 年6 月 17 日に取得
  76. ^ “JsonML (JSON マークアップ言語)”. JsonML.org 2022 年6 月 17 日に取得
  77. ^ McKamey、Stephen (2022 年 6 月 14 日)、JsonML 、 2022 年8 月 7 日取得
  78. ^ "FasterXML/smile-format-仕様: Smile フォーマットの新しいホーム". GitHub 2022 年6 月 17 日に取得
  79. ^ グプタ、アユシュ (2019 年 2 月 10 日)。「Smile を理解する — JSON に基づいたデータ形式」。Ayush を使用したコード2022 年8 月 7 日に取得
  80. ^ "ユニバーサル バイナリ JSON 仕様 – バイナリ JSON の普遍的に互換性のある形式の仕様". ubjson.org 2022 年6 月 17 日に取得
  81. ^ "UBJSON - 最新の C++ 用の JSON". json.nlohmann.me 2022 年8 月 7 日に取得

外部リンク

  • 公式ウェブサイト
「https://en.wikipedia.org/w/index.php?title=JSON&oldid=1208962569#HOCON」から取得