翻訳

JavaScript オブジェクト表記

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

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] UNIXおよびLinuxシステム管理ハンドブックには、「 JSON形式に名前を付けて推進したダグラス・クロックフォードは、JSONという名前と同じように発音すると述べています。しかし、どういうわけか、「JAY-sawn」^[a]が技術コミュニティでより一般的になっているようです」と記載されています。^[5]クロックフォードは2011年に、「それをどのように発音するかについては多くの議論がありますが、私はまったく気にしません」と述べています。^[1]

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

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

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

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

JSONはJavaScriptスクリプト言語のサブセット（具体的には、標準ECMA -262第3版—1999年12月^{[11] ）に基づいており、JavaScriptでよく使用されますが、}言語に依存しないデータ形式です。JSONデータを解析および生成するためのコードは、多くのプログラミング言語で簡単に入手できます。JSONのWebサイトには、言語別に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" : "😐" } // または{ "face" : "\uD83D\uDE10" }   

   

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

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

• 数値: 小数部を含む可能性があり、指数E表記を使用できるが、 NaNなどの非数値を含めることができない符号付き10進数。この形式では、整数と浮動小数点を区別しません。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]このような合意が必要な例の1つは、日付や}正規表現など、JSON標準に含まれないデータ型のシリアル化です。

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

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 開発手法です。通常、その Web ページ上のユーザー操作に応じて、サーバーから新しいデータをレンダリングします。たとえば、ユーザーが検索ボックスに入力したものは、クライアント側のコードによってサーバーに送信され、サーバーは一致するデータベース項目 のドロップダウン リストで即座に応答します。

JSON は、設定言語としてアドホックに使用されてきました。しかし、コメントはサポートされていません。2012 年に、JSON の作成者である Douglas Crockford は、設定言語として使用された場合の JSON のコメントについて次のように述べています。「コメントがないことで一部の人が悲しむのはわかっていますが、そうすべきではありません。JSON を使用して設定ファイルを保存し、それに注釈を付けるとします。好きなコメントをすべて挿入してください。次に、JSMin ^[33]にパイプしてから、JSON パーサーに渡します。」^[21]

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

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

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

JSONは、XMLの低オーバーヘッドの代替として推奨されています。これは、これらの両方の形式が、一般的に使用されている実際の状況で作成、読み取り、およびデコードに対して広くサポートされているためです。^[39] XML以外の例としては、CSVやJSONのスーパーセットが挙げられます。Google Protocol Buffersは、データ交換言語ではありませんが、この役割を果たすことができます。CBORにはJSONデータ型のスーパーセットがありますが、テキストベースではありません。IonもJSONのスーパーセットであり、より幅広いプライマリタイプ、注釈、コメントがあり、末尾のカンマを許可しています。^[40]

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

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

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

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

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

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

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

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

CSON（「CoffeeScript Object Notation」）は、有意なインデント、引用符で囲まれていないキーを使用し、外部オブジェクト宣言を想定しています。これは、GitHubのAtomテキストエディタの設定に使用されました。^{[47] [48] [49]}

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

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

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

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

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

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

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

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

いくつかのシリアル化フォーマットはJSON仕様に基づいて構築されています。例には以下が含まれます。

• GeoJSON、単純な地理的特徴を表現するために設計されたフォーマット^{[65] [66]}

• JSON-LD 、 JSONを使用してリンクされたデータをエンコードする方法^{[67] [68]}
• JSON-RPC、JSONでエンコードされたリモートプロシージャコールプロトコル^[69]
• JsonML 、 XMLとJSON間のマッピングに使用される軽量マークアップ言語^{[70] [71]}
• スマイル（データ交換フォーマット）^{[72] [73]}
• UBJSON、JSONを模倣したバイナリコンピュータデータ交換フォーマットだが、必要なデータバイト数が少ない^{[74] [75]}

• ビーソン
• データシリアル化形式の比較
• Amazon Ion  – JSON のスーパーセット (ただし、一般的な JSON とは異なり、交換用の JSON のようにUTF-8に限定されています)
• ジャクソン (API)
• jaql – JSONクエリ処理に最もよく使用される関数型データ処理およびクエリ言語
• jq – 「JSON クエリ言語」および高水準プログラミング言語
• JSONiq – XQueryに基づく JSON 指向のクエリおよび処理言語
• JSONストリーミング
• S式

• 公式サイト