JSON
チェック済み
ページは変更保留のため保護されています

JavaScript オブジェクト表記
JSONのロゴはメビウスの輪です
JSONのロゴはメビウスの輪です
ファイル名拡張子
.json
インターネットメディアの種類
アプリケーション/json
タイプコード文章
統一型識別子（UTI）公開.json
フォーマットの種類データ交換
延長からJavaScript
標準STD 90（RFC  8259）、ECMA-404、ISO/IEC 21778:2017
オープンフォーマット?はい
Webサイトjson.org​

JSON（JavaScript Object Notation、発音：/ ˈdʒ eɪ s ən /または/ ˈdʒ eɪ ˌ s ɒ n /）は、オープンスタンダードのファイル形式およびデータ交換形式であり、人間が読めるテキストを使用して、名前と値のペアや配列（またはその他のシリアル化可能な値）で構成されるデータオブジェクトを保存および転送します。これは、Webアプリケーションとサーバー間のデータ交換を含む、電子データ交換のさまざまな用途で広く使用されているデータ形式です。

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

ダグラス・クロックフォードは2000年代初頭にJSON形式を最初に仕様化しました。[ 1 ]彼とチップ・モーニングスターは2001年4月に最初のJSONメッセージを送信しました。

命名と発音

2017年の国際標準規格（ECMA-404およびISO/IEC 21778:2017）では、「JSON」は「 『ジェイソンとアルゴノーツ』のように、/ ˈ dʒ eɪ . s ə n /と発音する」と規定されている。[ 2 ] [ 3 ] ECMA-404の初版（2013年）では発音については触れられていなかった。[ 4 ]クロックフォードは2011年に「発音については多くの議論があるが、私は全く気にしない」と述べている。[ 1 ] / ˈ dʒ eɪ ˌ s ɒ n /も一般的な発音である。[ 5 ]

標準

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

歴史

ヤフービルのダグラス・クロックフォード（2007年）

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

JSON 形式は、クロックフォード氏が初めて仕様を定め、普及させたものです。[ 1 ]この頭字語は、クロックフォード氏らが 2001 年 3 月に共同設立した State Software 社で生まれました。共同設立者たちは、標準ブラウザの機能を利用し、Web 開発者がステートフル Web アプリケーションを作成できる抽象化レイヤーを提供するシステムを構築することに合意しました。このアプリケーションは、2 つのハイパーテキスト転送プロトコル(HTTP) 接続を開いたままにしておき、それ以上データが交換されない場合は標準ブラウザのタイムアウト前にそれらの接続を再利用することで、Web サーバーとの永続的な二重接続を実現します。共同設立者たちは円卓会議を開き、データ形式を JSML (JavaScript Markup Language) と呼ぶか JSON (JavaScript Object Notation) と呼ぶか、またどのようなライセンスの下で提供するかについて投票を行いました。JSON.org [ 9 ]の Web サイトは 2001 年に開設されました。2005 年 12 月、Yahoo! は一部のWeb サービスをJSON で提供し始めました。[ 10 ]

JSONライブラリの前身は、 Communities.comのCartoon Orbitという子供向けデジタル資産取引ゲームプロジェクトで使用されていました。このゲームでは、ブラウザ側のプラグインで独自のメッセージング形式を使用してDHTML要素を操作していました。初期のAjax機能を発見すると、digiGroups、Nooshなどがフレームを使用して、Webアプリケーションのビジュアルコンテキストを更新せずにユーザーのブラウザの視覚フィールドに情報を渡し、Netscape 4.0.5以降とInternet Explorer 5以降の標準的なHTTP、HTML、JavaScript機能のみを使用してリアルタイムでリッチなWebアプリケーションを実現しました。その後、CrockfordはJavaScriptをそのようなシステムのオブジェクトベースのメッセージング形式として使用できることを発見しました。このシステムは、Sun Microsystems、Amazon.com、EDSに売却されました。

JSONはJavaScriptスクリプト言語のサブセット（具体的には、1999年12月発行のECMA -262規格第3版[ 11 ] ）に基づいており、JavaScriptでよく使用されますが、言語に依存しないデータ形式です。JSONデータを解析および生成するためのコードは、多くのプログラミング言語で容易に入手できます。JSONのウェブサイトには、言語別にJSONライブラリがリストされています。

2013年10月、Ecma InternationalはJSON標準ECMA-404の初版を公開した。[ 4 ]同年、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日、インターネット技術タスクフォースはRFC 7159を廃止し、インターネット標準STD 90の現在のバージョンであるRFC 8259を公開した。 [ 12 ] [ 13 ]      

クロックフォードは、JSONライブラリをオープンソース化するために、企業弁護士や過度に衒学的にこだわる人々を嘲笑しながら、「ソフトウェアは善のために使用されなければならない」という条項をJSONライセンスに追加しました。しかし、この条項は、オープンソースソフトウェアやフリーソフトウェアは通常、使用目的に制限を設けていないため、 JSONライセンスと他のオープンソースライセンスとのライセンス互換性の問題を引き起こしました。[ 14 ]

構文

次の例は、人物を説明する 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" ], "spouse" : null }

文字エンコーディング

Crockfordは当初、JSONはJavaScriptとECMAScriptの厳密なサブセットであると主張していましたが[ 15 ]、彼の仕様では実際にはJavaScriptではない有効なJSON文書が許可されています。JSONでは、引用符で囲まれた文字列内でUnicodeの行末文字U+2028 LINE SEPARATORとU+2029 PARAGRAPH SEPARATORをエスケープせずに使用できますが、ECMAScript 2018以前では許可されていません。[ 16 ] [ 17 ]これは、JSONが「制御文字」のみを許可していないことに起因しています。移植性を最大限に高めるため、これらの文字はバックスラッシュでエスケープされます。

オープンエコシステムにおけるJSONの交換は、UTF-8でエンコードする必要があります。[ 6 ]このエンコードは、基本多言語面（U+0000からU+FFFF）外の文字を含む、Unicode文字セット全体をサポートしています。ただし、エスケープする場合は、これらの文字はUTF-16サロゲートペアを使用して記述する必要があります。例えば、絵文字U+1F610 😐 NEUTRAL FACEをJSONに含めるには、次のように 記述します。

{ "顔" : "😐" }

または： 

{ "face" : "\uD83D\uDE10" }

JSONは2019年の言語改訂以降、ECMAScriptの厳密なサブセットとなった。[ 17 ] [ 18 ]

データ型

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

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

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

初期のJSONバージョン（RFC 4627で規定されているものなど）では、有効なJSONテキストはオブジェクトまたは配列型のみで構成され、その中に他の型を含めることができるという制約がありました。この制約はRFC 7158で廃止され、JSONテキストは任意のシリアル化された値として再定義されました。   

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

コメントはJSONから意図的に排除されました。2012年、ダグラス・クロックフォードは自身の設計決定について次のように述べています。「コメントを解析指示の保持に使用していた人がいたため、JSONからコメントを削除しました。これは相互運用性を損なう行為でした。」[ 21 ]

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

相互運用性

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 はRFC 7493を公開し、これらの相互運用性の問題を可能な限り回避するために JSON の構文と処理を制限する JSON の制限付きプロファイルである「I-JSON メッセージ形式」について説明しました。  

セマンティクス

JSONはデータ交換のための構文フレームワークを提供しますが、明確なデータ交換には、JSON構文の特定の使用の意味についてプロデューサーとコンシューマーの間で合意が必要です。[ 25 ]このような合意が必要な一例として、日付や正規表現など、JSON標準に含まれないデータ型のシリアル化が挙げられます。

メタデータとスキーマ

JSONテキストの公式MIMEタイプは[ 26 ]application/jsonであり、ほとんどの最新の実装ではこれを採用しています。従来のMIMEタイプには、、、などがあります。[ 27 ] 標準のファイル名拡張子は.jsonです。[ 28 ]text/jsontext/x-jsontext/javascript

JSONスキーマは、JSONデータの構造を定義し、検証、ドキュメント化、およびインタラクション制御を行うためのJSONベースのフォーマットを規定しています。これは、特定のアプリケーションに必要なJSONデータとそのデータの変更方法に関する規約を提供します。[ 29 ] JSONスキーマはXMLスキーマ（XSD）の概念に基づいていますが、JSONベースです。XSDと同様に、スキーマとデータの両方に同じシリアル化/デシリアル化ツールを使用でき、自己記述型です。IETFのインターネットドラフトで規定されており、2024年時点での最新バージョンは「ドラフト2020-12」です。[ 30 ]異なるプログラミング言語向けに複数のバリデーターが用意されており、[ 31 ]それぞれ準拠レベルが異なります。

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

用途

JSON-RPCは、 XML-RPCやSOAPの代替としてJSON上に構築されたリモートプロシージャコール（RPC）プロトコルです。これは、少数のデータ型とコマンドのみを定義するシンプルなプロトコルです。JSON-RPCを使用すると、システムは通知（応答を必要としないサーバーへの情報）を送信したり、順序に関係なく応答できる複数のサーバー呼び出しを実行したりできます。

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

JSONは設定言語としてアドホックに使用されてきました。しかし、コメントはサポートされていません。2012年、JSONの考案者であるダグラス・クロックフォードは、設定言語として使用されるJSONのコメントについて次のように述べています。「コメントがないことに不満を感じる人もいるでしょうが、そうすべきではありません。例えば、JSONを使って設定ファイルを保存し、注釈を付けたいとします。好きなコメントをすべて挿入し、JSMin [ 33 ]にパイプしてからJSONパーサーに渡してください。」[ 21 ]

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

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

安全性

JSON は JavaScript のサブセットであるため、JSON テキストを JavaScript 関数に渡しても安全だという誤解を招く可能性がありますeval()。これは安全ではありません。有効な JSON テキストの中には、U+2028 LINE SEPARATORやU+2029 PARAGRAPH SEPARATORを含むものなどがあり、2019 年に JavaScript 仕様が更新されるまでは有効な JavaScript コードではなかったため、古いエンジンではサポートされない可能性があります。[ 36 ]インターネットから任意のコードを実行することで生じる多くの落とし穴を避けるため、新しい関数 がECMAScript の第 5 版に初めて追加され、[ 37 ] 2017 年現在、すべての主要ブラウザーでサポートされています。サポートされていないブラウザー向けに、Douglas Crockfordによって API 互換の JavaScript ライブラリが提供されています。[ 38 ]さらに、TC39 提案「Subsume JSON」により、ECMAScript は2019 年の言語改訂時点で厳密な JSON スーパーセットになりました。[ 17 ] [ 18 ]さまざまなJSONパーサー実装は、サービス拒否攻撃と大量代入の脆弱性に悩まされてきた。[ 39 ] [ 40 ]JSON.parse()

代替案

JSONはXMLの低オーバーヘッドの代替として推奨されています。なぜなら、これらのフォーマットはどちらも、実世界の状況で一般的に使用されている作成、読み取り、デコードにおいて広くサポートされているからです。[ 41 ]具体的なユースケースに応じて、JSONの代替には次のようなものがあります。

  • テキスト形式としては、CSVとJSONのスーパーセット（下記参照）があります。IonはJSONのスーパーセットであるテキスト形式も提供しています（より幅広い基本型、注釈、コメント、末尾のカンマの許容など）。[ 42 ]
  • 人間による可読性を犠牲にして処理速度を向上させるために、すべてのJSONオブジェクトを表現できるデータ交換形式としては、 CBOR（IETF RFC標準）やIonバイナリなどがあります。[ 42 ] Google Protocol Buffersもスキーマなしで解析できるため、このニッチなニーズを満たすことができますが、交換言語として意図されているわけではありません。さらに、SQLiteやPostgreSQLなどのデータベースには、「JSONB」と呼ばれる独自の内部バイナリ表現がありますが、これは外部での使用を想定していません。[ 43 ]

XML

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

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

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

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

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

XMLはコメントをサポートしていますが、JSONはサポートしていません。[ 45 ] [ 21 ]

スーパーセット

コメントやその他の機能のサポートは有用であるとみなされ、いくつかの非標準JSONスーパーセットが作成されました。その中には、HJSON、[ 46 ]、HOCON、JSON5（名前にもかかわらず、JSONの5番目のバージョンではありません）などがあります。[ 47 ] [ 48 ]

ヤムル

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

CSON

CSON（「CoffeeScript Object Notation」）は、意味のあるインデントと引用符で囲まれていないキーを使用し、外部オブジェクト宣言を前提としています。これはGitHubのAtomテキストエディタの設定に使用されました。[ 50 ] [ 51 ] [ 52 ]

また、 CSON（「Cursive Script Object Notation」）と呼ばれる無関係なプロジェクトもあり、これは構文的にはJSONに似ています。 [ 53 ]

ホーコン

HOCON （「Human-Optimized Config Object Notation」）は、人間が読めるデータのフォーマットであり、JSONのスーパーセットです。[ 54 ] HOCONの用途は次のとおりです。

JSON5

JSON5（「JSON5データ交換フォーマット」）はJSON構文の拡張であり、JSONと同様にJavaScript構文としても有効です。仕様策定は2012年に開始され、2018年にバージョン1.0.0で完了しました。[ 65 ] JSON構文との主な違いは以下のとおりです。

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

JSON5構文は、JSON構文の拡張として一部のソフトウェアでサポートされており、例えばSQLiteなどです。[ 66 ]

JSONC

JSONC （コメント付きJSON）は、MicrosoftのVisual Studio Codeで使用されているJSON5のサブセットです。[ 67 ]

  • 単一行コメント（//）とブロックコメント（/* */）をサポートします
  • 末尾のカンマは許容されるが、推奨されず、エディタは警告を表示する。

デリバティブ

JSON仕様に基づいて、あるいはJSON仕様から構築されたシリアル化フォーマットは数多く存在します。例としては、

  • GeoJSONは、単純な地理的特徴を表現するために設計されたフォーマットである[ 68 ] [ 69 ]
  • Jsonnetは、JSONファイルを生成するプロトタイプベースのドメイン固有言語です。すべてのJSONドキュメントは有効なJsonnetプログラムであり、実行時に変更されずに出力されます。Jsonnetは、変数、インポート、ループ、コメントなどをサポートすることでJSONを拡張します。[ 79 ] [ 80 ] Jsonnetは、クラウドインフラストラクチャエンジニアリングの設定言語として使用されています。[ 81 ]

参照

参考文献

  1. ^ a b cクロックフォード、ダグラス (2011 年 8 月 28 日)。JSON サーガ(ビデオ)。ゆいライブラリー。2022 年2 月 21 日に取得– YouTube経由。
  2. ^ a b c「ISO/IEC 21778:2017 情報技術 — JSONデータ交換構文」 . ISO . 2025年6月24日閲覧。
  3. ^ 「ECMA-404: JSONデータ交換構文」（第2版）. Ecma International . 2017年12月. p. iii, 脚注. 2019年10月27日時点のオリジナルよりアーカイブ（PDF） 。 2024年4月29日閲覧。
  4. ^ a b c「ECMA-404: JSONデータ交換フォーマット」（第1版）. Ecma International . 2013年10月. 2013年11月1日時点のオリジナルよりアーカイブ（PDF） . 2023年11月20日閲覧。
  5. ^ Sweigart, Al (2015). 『Pythonで退屈な作業を自動化：初心者のための実践プログラミング』 No Starch Press . p. 319. ISBN 97815932768502019年10月29日閲覧。「ジェイソン」と発音しても「ジェイソン」と発音しても、どちらでも構いません。どちらにしても、人々は「発音が間違っている」と言うでしょう。（cot-caughtの合併を想定：「sawn」/ s ɔː n / → [sɒn]）。
  6. ^ a b Bray, T. (2017年12月). Bray, T (編). JavaScript Object Notation (JSON) データ交換フォーマット. IETF. doi : 10.17487/RFC8259 . S2CID 263868313. RFC 8259. 2018年2月16日閲覧。 
  7. ^ Bray, Tim. 「JSON Redux AKA RFC7159」進行中. 2014年3月16日閲覧。
  8. ^ 「非公式Javaの歴史」Edu4Java、 2014年5月26日。 2014年5月26日時点のオリジナルよりアーカイブ。 2019年8月30日閲覧。1996年、MacromediaはJavaとActiveXが残した領域を埋めるFlashテクノロジーを発表し、クライアントサイドのアニメーションにおける事実上の標準となった。
  9. ^ "JSON" . json.org .
  10. ^ Yahoo!. 「Yahoo! WebサービスでJSONを使用する」 . 2007年10月11日時点のオリジナルよりアーカイブ。2009年7月3日閲覧。
  11. ^ Crockford, Douglas (2009年5月28日). 「JSONの紹介」 . json.org . 2009年7月3日閲覧。これは、JavaScriptプログラミング言語標準ECMA-262第3版（1999年12月）のサブセットに基づいています。
  12. ^ Bray, Tim (2017年12月). 「draft-ietf-jsonbis-rfc7159bis-04 の履歴」 . IETF Datatracker . Internet Engineering Task Force . 2019年10月24日閲覧. 2017-12-13 [...] RFC公開
  13. ^ Bray, Tim (2017年12月13日). 「RFC 8259 - JavaScript Object Notation (JSON) データ交換フォーマット」 . IETF Datatracker . Internet Engineering Task Force . 2019年10月24日閲覧.タイプ: RFC - インターネット標準 (2017年12月; エラッタ); RFC 7159 を廃止; STD 90 とも呼ばれる
  14. ^ LWN.net の Jake Edge による「 Apache と JSON ライセンス」(2016 年 11 月 30 日)。
  15. ^ Douglas Crockford (2016年7月10日). 「JSON in JavaScript」 . 2016年7月10日時点のオリジナルよりアーカイブ。 2016年8月13日閲覧。JSONはJavaScriptのオブジェクトリテラル表記のサブセットです。
  16. ^ Holm, Magnus (2011年5月15日). 「JSON: 存在しないJavaScriptのサブセット」 . The timeless repository. 2012年5月13日時点のオリジナルよりアーカイブ。 2016年9月23日閲覧。
  17. ^ a b c「JSONの包含：すべてのJSONテキストをECMA-262に適合させるための提案」。Ecma TC39。2019年8月23日。 2019年8月27日閲覧。
  18. ^ a b「ステージ4へ進む - tc39/proposal-json-superset」。GitHub 。 2018年5月22日。
  19. ^ 「BigInt - MDN Web doc 用語集」 . Mozilla . 2020年10月18日閲覧。
  20. ^ ECMA-404、第 2 版、3 ページ：「JSON 構文では、名前として使用される文字列に制限は課されず、名前文字列が一意である必要はなく、名前/値のペアの順序に意味は割り当てられません。」
  21. ^ a b c d e Crockford, Douglas (2012年4月30日). 「JSONのコメント」 . 2015年7月4日時点のオリジナルよりアーカイブ。2019年8月30日閲覧。JSONからコメントを削除したのは、コメントを解析指示子として使用している人がいるのを見たためです。これは相互運用性を損なう行為でした。コメントがないことで残念に思う人もいるでしょうが、そうすべきではありません。例えば、JSONを使用して設定ファイルを保存し、それに注釈を付けたいとします。好きなコメントをすべて挿入してください。そして、JSMinにパイプしてからJSONパーサーに渡してください。
  22. ^ Andrysco, Marc; Jhala, Ranjit; Lerner, Sorin (2016年2月18日).浮動小数点数の印刷：常に正しい方法(PDF) (レポート) . 2025年5月31日閲覧。
  23. ^ “末尾のカンマ - JavaScript | MDN” . developer.mozilla.org . 2023年9月12日. 2023年12月16日閲覧。
  24. ^ “JSON5” . json5. 2020年11月29日時点のオリジナルよりアーカイブ。2020年12月16日閲覧。
  25. ^ ECMA-404 第2版、p. iii：「JSON構文は完全なデータ交換の仕様ではありません。意味のあるデータ交換には、JSON構文の特定の使用法に付随するセマンティクスについて、プロデューサーとコンシューマーの間で合意が必要です。JSONが提供するのは、そのようなセマンティクスを付加できる構文フレームワークです。」
  26. ^ 「メディアタイプ」 . iana.org . 2015年9月13日閲覧。
  27. ^ 「JSONの正しいContent-Typeヘッダー」ReqBin . 2023年1月13日. 2024年3月23日閲覧。
  28. ^ Bray, Tim (2017年12月). Bray, T. (編). 「11. IANAに関する考慮事項」 . RFC 8259: JavaScript Object Notation (JSON) データ交換フォーマット. IETF . doi : 10.17487/RFC8259 . S2CID 263868313 . 
  29. ^ 「JSONスキーマとハイパースキーマ」 . json-schema.org . 2021年6月8日閲覧。
  30. ^ 「JSONスキーマ - 仕様リンク」 . json-schema.org . 2024年3月22日閲覧。
  31. ^ 「JSONスキーマ実装」 . json-schema.org . 2021年6月16日時点のオリジナルよりアーカイブ。2021年6月8日閲覧。
  32. ^ Zyp, Kris (2012年9月16日). Bryan, Paul C. (編). 「JSONリファレンス: draft-pbryan-zyp-json-ref-03」 .インターネット技術タスクフォース.
  33. ^ Crockford, Douglas (2019年5月16日). 「JSMin」 . 2020年8月12日閲覧。JSMin [2001] は、JavaScriptファイルからコメントと不要な空白を削除する縮小ツールです。
  34. ^ 「JSONBデータ型」 . www.cockroachlabs.com . 2025年4月1日閲覧。
  35. ^ 「JSONデータ型」 . dev.mysql.com . 2025年4月1日閲覧。
  36. ^ 「JSON: JavaScriptのサブセットではないもの」 Magnus Holm. 2012年5月13日時点のオリジナルよりアーカイブ。2011年5月16日閲覧。
  37. ^ 「ECMA-262: ECMAScript 言語仕様」（第5版）2009年12月。2011年4月14日時点のオリジナルよりアーカイブ（PDF） 。 2011年3月18日閲覧。
  38. ^ "douglascrockford/JSON-js" . GitHub . 2019年8月13日.
  39. ^ 「JSONにおけるサービス拒否および安全でないオブジェクト作成の脆弱性（CVE-2013-0269）」 。 2016年1月5日閲覧。
  40. ^ 「Microsoft .NET Framework JSONコンテンツ処理におけるサービス拒否の脆弱性」。2018年11月6日時点のオリジナルよりアーカイブ。 2016年1月5日閲覧。
  41. ^ 「JSON: XMLに代わる無駄のない代替手段」 . json.org . 2011年3月14日閲覧。
  42. ^ a b “Amazon Ion” . Amazon . 2024年8月12日時点のオリジナルよりアーカイブ。2024年8月26日閲覧。
  43. ^ 「SQLite JSONB フォーマット」 . sqlite.org .
  44. ^ 「XML 1.1仕様」 . ワールド・ワイド・ウェブ・コンソーシアム. 2019年8月26日閲覧。
  45. ^ Saternos, Casimir (2014). JavascriptとJavaによるクライアントサーバー型Webアプリ. O'Reilly Media, Inc.. p. 45. ISBN 9781449369316。
  46. ^ Edelman, Jason; Lowe, Scott; Oswalt, Matt. Network Programmability and Automation . O'Reilly Media .データ表現には、YAML、YAMLEX、JSON、JSON5、HJSON、または純粋なPythonのいずれかを選択できます。
  47. ^ a b McCombs, Thayne (2018年7月16日). 「なぜJSONは良い設定言語ではないのか」 . Lucid Chart . 2019年6月15日閲覧。
  48. ^ 「HOCON (Human-Optimized Config Object Notation)」 . GitHub . 2019年1月28日. 2019年8月28日閲覧.主な目標は、JSONのセマンティクス（ツリー構造、型セット、エンコード／エスケープ）を維持しながら、人間が編集可能な設定ファイル形式としてより使いやすくすることです。
  49. ^ a b「YAML Ain't Markup Language (YAML) バージョン 1.2」yaml.org . 2015年9月13日閲覧。
  50. ^ Dohm, Lee (2014). 「CoffeeScript Object Notation」 . The Big Book of Atom . 2023年4月22日時点のオリジナルよりアーカイブ。 2024年4月29日閲覧。
  51. ^ 「基本的なカスタマイズ」 . Atom Flight Manual . GitHub . 2024年4月29日時点のオリジナルよりアーカイブ。 2024年4月29日閲覧。
  52. ^ "CSON" . Bevry. 2023年12月20日. 2024年4月23日時点のオリジナルよりアーカイブ。2024年4月29日閲覧– GitHub経由。
  53. ^ Seonghoon, Kang (2021年7月1日). 「CSON」 . 2023年12月16日時点のオリジナルよりアーカイブ。2023年2月27日閲覧– GitHub経由。
  54. ^ “config/HOCON.md at master · lightbend/config” . GitHub . 2021年8月5日閲覧。
  55. ^ 「Config File - 2.5.x」 . www.playframework.com . 2021年8月5日閲覧。
  56. ^ Akka.NET HOCON ドキュメント
  57. ^ 「Akka.NETドキュメント」 . getakka.net . 2021年8月5日閲覧。
  58. ^ 「PuppetでHOCON設定ファイルを管理する」 。 2017年2月11日時点のオリジナルよりアーカイブ。2023年3月4日閲覧。
  59. ^ 「StreamBaseドキュメント」 . docs.streambase.com . 2021年8月5日閲覧。
  60. ^ 「構成ガイド」 . docs.streambase.com . 2021年8月5日閲覧。
  61. ^ 「StreamBase 新着・注目アーカイブ」 . docs.streambase.com . 2021年8月5日閲覧。
  62. ^ “Exabeam Advanced Analytics Release Notes” . 2020年10月20日時点のオリジナルよりアーカイブ。2023年3月4日閲覧。
  63. ^ JITSIプロジェクト. 「Config phase 1」 . GitHub . 2021年2月16日閲覧。
  64. ^ JITSIプロジェクト. 「reference.conf」 . GitHub . 2021年2月16日閲覧。
  65. ^ 「JSON5データ交換フォーマット」 。 2022年6月25日閲覧。
  66. ^ SQLite. 「JSON関数と演算子」 . 2023年6月25日閲覧。
  67. ^ 「コメント付きJSON - Visual Studio CodeでのJSON編集」 Visual Studio CodeMicrosoft 2024年4月29日閲覧。
  68. ^ Butler, H.; Daly, M.; Doyle, A.; Gillies, Sean; Schaub, T.; Hagen, Stefan (2016年8月). 「RFC 7946 - GeoJSONフォーマット」 . IETF Datatracker . 2022年6月17日閲覧。
  69. ^ "GeoJSON" . geojson.org . 2022年8月7日閲覧。
  70. ^ 「JSON-LD 1.1」。ワールド・ワイド・ウェブ・コンソーシアム。2020年7月16日。 2022年6月17日閲覧。
  71. ^ 「JSON-LD - JSON for Linking Data」 . json-ld.org . 2022年8月7日閲覧。
  72. ^ "JSON-RPC" . jsonrpc.org . 2022年6月17日閲覧。
  73. ^ 「JsonML (JSONマークアップ言語)」 . JsonML.org . 2022年6月17日閲覧。
  74. ^ McKamey, Stephen (2022年6月14日) JsonML 、 2022年8月7日閲覧。
  75. ^ 「FasterXML/smile-format-specification: Smile形式の新しいホーム」 . GitHub . 2022年6月17日閲覧。
  76. ^ Gupta, Ayush (2019年2月10日). 「Smileを理解する — JSONベースのデータフォーマット」 . Code with Ayush . 2022年8月7日閲覧。
  77. ^ 「ユニバーサルバイナリJSON仕様 – バイナリJSONのユニバーサル互換フォーマット仕様」ubjson.org . 2022年6月17日閲覧。
  78. ^ 「UBJSON - JSON for Modern C++」 . json.nlohmann.me . 2022年8月7日閲覧。
  79. ^ Bryan Feuling 「GitOpsによる再現性、信頼性、スケーラビリティ」 2021年、129ページ。
  80. ^ ウィリアム・ヘゲダス. 「プロメテウスをマスターする」 . 2024年. p. 194 - 198.
  81. ^ Eric LiangとAaron Davidson 「Jsonnetテンプレート言語による宣言型インフラストラクチャ」 2017年。
「 https://en.wikipedia.org/w/index.php?title=JSON&oldid=1334443059」から取得