JSON とは何ですか? どのように使用しますか?
公開: 2022-08-14JSON (JavaScript Object Notation) は、構造化データを表すための標準化された形式です。 JSON は JavaScript プログラミング言語から派生したものですが、現在ではシステム間のデータ交換のユビキタスな方法になっています。 最新の API のほとんどは、JSON 要求を受け入れて JSON 応答を発行するため、形式とその機能に関する十分な実務知識があると役に立ちます。
この記事では、JSON とは何か、JSON がさまざまなデータ型を表現する方法、一般的なプログラミング言語で JSON を生成および使用する方法について説明します。 また、JSON のいくつかの制限と出現した代替案についても説明します。
JSON の基本
JSON はもともと Douglas Crockford によって、ブラウザーとサーバー間でデータを通信するためのステートレス形式として考案されました。 2000 年代初頭、Web サイトは、最初のページの読み込み後に、サーバーから追加のデータを非同期的に取得し始めていました。 JavaScript から派生したテキストベースの形式である JSON は、これらのアプリケーション内でのデータの取得と使用をより簡単にしました。 この仕様は、最終的に 2013 年に ECMA-404 として標準化されました。
JSON は常に文字列として送信されます。 これらの文字列は、数値、ブール値、配列、オブジェクトなど、さまざまな基本データ型にデコードできます。 これは、送信中にオブジェクトの階層と関係を保持し、受信側でプログラミング環境に適した方法で再構築できることを意味します。
基本的な JSON の例
これは、ブログ投稿の JSON 表現です。
{ "ID": 1001, "title": "JSONとは?", "著者": { "ID": 1, 「名前」:「ジェームズ・ウォーカー」 }、 "tags": ["api", "json", "プログラミング"], 「公開」: false, "publishedTimestamp": null }
この例は、すべての JSON データ型を示しています。 また、JSON 形式のデータの簡潔さも示しています。これは、API での使用を非常に魅力的にしている特徴の 1 つです。 さらに、JSON は、XML などのより冗長な形式とは異なり、そのままで比較的簡単に読み取ることができます。
JSON データ型
JSON では、次の 6 種類のデータをネイティブに表現できます。
- 文字列– 文字列は二重引用符で囲みます。 文字はバックスラッシュを使用してエスケープできます。
- 数字– 数字は引用符なしで数字として書かれます。 浮動小数点を表す小数コンポーネントを含めることができます。 ほとんどの JSON 解析の実装では、小数点がない場合は整数を想定しています。
- ブール値 – リテラル値
true
およびfalse
がサポートされています。 - Null –
null
リテラル値は、空または省略された値を示すために使用できます。 - 配列– 配列は、角括弧で示される単純なリストです。 リスト内の各要素はコンマで区切られています。 配列には任意の数の項目を含めることができ、サポートされているすべてのデータ型を使用できます。
- オブジェクト– オブジェクトは中かっこで作成されます。 これらは、キーが二重引用符で囲まれた文字列であるキーと値のペアのコレクションです。 各キーには、使用可能なデータ型のいずれかを取ることができる値があります。 オブジェクトをネストしてカスケード階層を作成できます。 キーと値のペアの終わりを示すために、各値の後にカンマを付ける必要があります。
JSON パーサーは、これらのデータ型を言語に適した構造に自動的に変換します。 たとえば、手動でid
を整数にキャストする必要はありません。 値を元のデータ形式にマッピングするには、JSON 文字列全体を解析するだけで十分です。
セマンティクスと検証
JSON には、データをエンコードするときに尊重する必要がある特定のルールがあります。 構文に従わない文字列は、コンシューマーによって解析できません。
文字列とオブジェクト キーを囲む引用符に注意することが特に重要です。 また、オブジェクトまたは配列の各エントリの後にカンマを使用する必要があります。 ただし、JSON では、最後のエントリの後にカンマを使用することはできません。意図せずコンマを含めると、検証エラーの一般的な原因となります。 ほとんどのテキスト エディターは構文の問題を強調表示し、間違いを発見するのに役立ちます。
これらの一般的なトリップ ポイントにもかかわらず、JSON は手動で書き込むのが最も簡単なデータ形式の 1 つです。 ほとんどの人は、構文に慣れると、構文がすばやく便利であることに気付きます。 全体として、JSON は XML よりもエラーが発生しにくい傾向があり、開始タグと終了タグの不一致、無効なスキーマ宣言、および文字エンコーディングの問題がしばしば問題を引き起こします。
JSON コンテンツの指定
.json
拡張子は通常、JSON がファイルに保存されるときに使用されます。 JSON コンテンツには標準化された MIME タイプapplication/json
がありますが、互換性の理由からtext/json
が使用されることがあります。 現在、 Accept
およびContent-Type
HTTP ヘッダーにはapplication/json
を使用する必要があります。
JSON を使用するほとんどの API は、すべてをトップレベル オブジェクトにカプセル化します。
{ 「エラー」: 1000 }
ただし、これは必須ではありません。リテラル型はファイルの最上位ノードとして有効であるため、次の例もすべて有効な JSON です。
1000
真実
ヌル
それらは、プログラミング言語のそれぞれのスカラーにデコードされます。
JSON の操作
ほとんどのプログラミング言語には、JSON サポートが組み込まれています。 いくつかの一般的な環境で JSON データを操作する方法を次に示します。
JavaScript
JavaScript では、 JSON.stringify()
およびJSON.parse()
メソッドを使用して、JSON 文字列をエンコードおよびデコードします。
constポスト= { ID : 1001 、 title : 「JSONとは?」 、 作者: { ID : 1 , 名前: 「ジェームズ・ウォーカー」 } } ; const encodedJson = JSON. stringify (ポスト) ; // {"id": 1001, "title": "JSON とは?", ...} コンソール。 ログ( encodedJson ) ; const decodedJson = JSON. 解析( encodedJson ) ; // ジェームズ・ウォーカー コンソール。 log ( decodedJson.author.name ) ; _
PHP
PHP で同等の関数はjson_encode()
とjson_decode()
です。
$post = [ "id" => 1001 、 "title" => "JSON とは?" 、 "著者" => [ "id" => 1 、 「名前」 => 「ジェームズ・ウォーカー」 ] ] ; $encodedJson = json_encode ( $post ) ; // {"id": 1001, "title": "JSON とは?", ...} $encodedJsonをエコーします。 $decodedJson = json_decode ( $encodedJson , true ) ; // ジェームズ・ウォーカー echo $decodedJson [ "作者" ] [ "名前" ] ;
パイソン
Python は、それぞれシリアル化および逆シリアル化するjson.dumps()
およびjson.loads()
を提供します。
jsonをインポート 投稿= { 「ID」 : 1001 、 "title" : "JSONとは?" 、 「作者」 : { 「ID」 : 1 、 「名前」 : 「ジェームズ・ウォーカー」 } } エンコードされたJson = json. ダンプ(ポスト) # {"id": 1001, "title": "JSON とは?", ...} 印刷( encodedJson ) デコードされたJson = json. 読み込み( encodedJson ) # ジェームズ・ウォーカー print ( decodedJson [ "作者" ] [ "名前" ] )
ルビー
Ruby はJSON.generate
とJSON.parse
を提供します:
「json」が必要 投稿 = { "id" => 1001 、 "title" => "JSON とは?" 、 "著者" => { "id" => 1 、 「名前」 => 「ジェームズ・ウォーカー」 } } エンコードされた Json = JSON. 生成(投稿) # {"id": 1001, "title": "JSON とは?", ...} エンコードされたJsonを置きます デコードされたJson = JSON. 解析( encodedJson ) # ジェームズ・ウォーカー puts decodedJson [ 「作成者」 ] [ 「名前」 ]
JSON の制限
JSON は、データ構造内で値を伝達することに重点を置いた軽量の形式です。 これにより、解析が迅速になり、操作が簡単になりますが、不満を引き起こす可能性のある欠点があることを意味します. ここにいくつかの最大の問題があります。
コメントはありません
JSON データにコメントを含めることはできません。 注釈がないと明快さが損なわれ、ドキュメントを別の場所に配置せざるを得なくなります。 これにより、設定ファイルなど、変更が頻繁に行われず、フィールドの目的が不明確な状況では、JSON が不適切になる可能性があります。
スキーマなし
JSON では、データのスキーマを定義できません。 たとえば、 id
が必須の整数フィールドであることを強制する方法はありません。 これにより、意図せず不正なデータ構造が作成される可能性があります。
参照なし
フィールドは、データ構造内の他の値を参照できません。 これにより、ファイルサイズが増加する繰り返しが発生することがよくあります。 前のブログ記事の例に戻ると、ブログ記事のリストは次のようになります。
{ "投稿": [ { "ID": 1001, "title": "JSONとは?", "著者": { "ID": 1, 「名前」:「ジェームズ・ウォーカー」 } }、 { "ID": 1002, "title": "SaaSとは?", "著者": { "ID": 1, 「名前」:「ジェームズ・ウォーカー」 } } ] }
両方の投稿の作成者は同じですが、そのオブジェクトに関連付けられた情報は複製する必要がありました。 理想的な世界では、JSON パーサーの実装は、次のような入力から上記の構造を生成できます。
{ "投稿": [ { "ID": 1001, "title": "JSONとは?", "作者": "{{ .authors.james }}" }、 { "ID": 1002, "title": "SaaSとは?", "作者": "{{ .authors.james }}" } ]、 "著者": { "ジェームズ": { "ID": 1, 「名前」:「ジェームズ・ウォーカー」 } } }
これは現在、標準の JSON では不可能です。
高度なデータ型なし
サポートされている 6 つのデータ型では、多くの一般的な種類の値が省略されています。 JSON は、日付、時刻、または位置情報ポイントをネイティブに保存できないため、この情報の独自の形式を決定する必要があります。
これにより、不都合な不一致やエッジ ケースが発生します。 アプリケーションが2022-07-01T12:00:00+00:00
のようにタイムスタンプを文字列として処理するが、外部 API が時刻を Unix エポック ( 1657287000
) を過ぎた秒数として表す場合、それぞれのフォーマット。
JSON の代替
YAML は主要な JSON の代替手段です。 これは、人間が読みやすい表示、カスタム データ型、および参照のサポートを備えた形式のスーパーセットです。 JSON に関連するユーザビリティの課題のほとんどに対処することを目的としています。
YAML は、構成ファイルや、DevOps、IaC、オブザーバビリティ ツール内で広く採用されています。 API のデータ交換形式として使用されることはあまりありません。 YAML の相対的な複雑さは、新規参入者にとっては親しみにくいことを意味します。 小さな構文エラーは、紛らわしい解析エラーを引き起こす可能性があります。
プロトコル バッファー (protobuf) は、構造化データをシリアル化するために設計されたもう 1 つの新しい JSON 候補です。 Protobuf には、データ型の宣言、必須フィールド、およびほとんどの主要なプログラミング言語のサポートがあります。 このシステムは、ネットワークを介してデータを送信するより効率的な方法として人気を集めています。
概要
JSON は、6 つの異なるデータ型をエンコードできるテキストベースのデータ表現形式です。 JSON は、ソフトウェア開発エコシステムの定番となっています。 すべての主要なプログラミング言語でサポートされており、過去 20 年間に開発されたほとんどの REST API のデフォルトの選択肢となっています。
JSON の単純さは人気の理由の 1 つですが、この形式で達成できることにも制限があります。 スキーマ、コメント、オブジェクト参照、およびカスタム データ型がサポートされていないということは、アプリケーションによっては、JSON で可能な範囲を超えて大きくなってしまうことを意味します。 YAML や Protobuf などの新しい代替手段は、これらの課題への対処に役立ちましたが、XML は、データ スキーマを定義する必要があり、冗長性を気にしないアプリケーションの候補として残っています。