json - さまざまなタイプの JSON

Question

私はこの質問を見ていました

JSON 構造に付けられたさまざまな名前の間で混乱しています

単純な JSON とは?
JSON の配列 ?
JSON 配列の配列 ?
その他可能

例 1 :これは何と呼ばれていますか

{
    "MIT_COLLEGE": [
                    {
                      "_id": 1,
                      "StudentName": "Sam",
                      "Student_Age": "24",
                      "Student_phone": "8725436232",
                      "Student_sex": "Male",
                    },
                    {
                      "_id": 2,
                      "StudentName": "kira",
                      "Student_Age": "22",
                      "Student_phone": "8725136232",
                      "Student_sex": "Female",
                    }
                   ],
    "CAMBRIDGE_COLLEGE": [
                          {
                           "_id": 1,
                           "StudentName": "Paul",
                           "Student_Age": "26",
                           "Student_phone": "87333336232",
                           "Student_sex": "Male",
                          },
                          {
                           "_id": 2,
                           "StudentName": "michael",
                           "Student_Age": "22",
                           "Student_phone": "872115436232",
                           "Student_sex": "Male",
                          }
                    ]
}

例 2::これは何と呼ばれていますか

                             {
                               "_id": 2,
                               "StudentName": "michael",
                               "Student_Age": "22",
                               "Student_phone": "872115436232",
                               "Student_sex": "Male",
                              }

JSON で考えられるその他の構造と、それは何と呼ばれますか?

ありがとう...私が明確であることを願っています

score 2 · Accepted Answer

唯一の違いは、仕様間のものです。

違いは次のとおりです。

6 つの構造文字の前または後には、意味のない空白を使用できます (RFC 4627)。
トークンの前後に意味のない空白を使用できます。(ECMA-404)
JSON テキストは Unicode でエンコードする必要があります。デフォルトのエンコーディングは UTF-8 です。(RFC4627)
JSON テキストは、JSON 値文法に準拠する Unicode コードポイントから形成された一連のトークンです。(ECMA-404)
実装は、JSON テキストの先頭にバイトオーダーマークを追加してはなりません。(RFC7159)
I-JSON メッセージ内のオブジェクトは、名前が重複するメンバーを持ってはなりません。(RFC7493)
各行は、\n行区切り記号付きの有効な JSON (ndJSON)です。

そして、それらの背後にある理由は次のとおりです。

RFC4627

ECMA 標準は最小限であり、許可された文法構文のみを記述していますが、RFC はセマンティックとセキュリティに関する考慮事項も提供しています。

RFC7159

JSON 仕様、特に RFC4627 について、IETF でかなりの不平がありました。まず第一に、それは「標準トラック」ではなく「情報」であり、特定のコンテキストでそれを参照する官僚的な問題があったことを意味しました。第 2 に、4627 では JSON テキストがオブジェクトまたはリストのいずれかである必要があるという点で、それと ECMA バージョンは矛盾していましたが、ECMA バージョンは「42」または true だけで問題ありませんでした。最後に、4627 では、オブジェクトの重複キーや破損した Unicode 文字列など、誰もが悪い慣行であることに同意するいくつかのことを許可しました。

そのため、IETF は 2013 年に JSON ワーキンググループを立ち上げ、これらの問題を解決するために 4627 を改訂することを目的としました。

RFC7493

I-JSON は、JSON のチャンクを構築し、RFC 7159 で説明されている相互運用エラーを回避する場合、それを「I-JSON メッセージ」と呼ぶことができるというメモです。既知の JSON 実装が I-JSON メッセージを作成し、それを他の既知の JSON 実装に送信した場合、ソフトウェアで驚きが生じる可能性はほとんどありません。

JSON は、セキュリティ関連のプロトコル (暗号、認証/承認など) で多く使用され始めています。セキュリティ担当者は、悪い人や公務員が重複キーや慎重に改ざんされた Unicode などの愚かな JSON トリックを使用してこれらのプロトコルを攻撃することを懸念していることが判明しました。

そのため、ペイロードが I-JSON メッセージでなければならないことを指定し、受信者がそれをチェックする場合、心配する必要のない特定の攻撃クラスが 1 つあります。

ndJSON

ndJSON の一般的な使用例は、TCP や UNIX パイプなどのストリーミングプロトコルを介して JSON テキストの複数のインスタンスを配信することです。また、半構造化データの保存にも使用できます。

eJSON

eJSON は、より多くの型をサポートするための JSON の拡張です。すべての JSON セーフタイプに加えて、以下をサポートします。

Date (JavaScript Date) Binary (JavaScript Uint8Array または EJSON.newBinary の結果) ユーザー定義型

すべての eJSON シリアル化も有効な JSON です。たとえば、日付とバイナリバッファーを持つオブジェクトは、EJSON で次のようにシリアル化されます。

    {
     "d": { "$date": 1358205756553 },
     "b": { "$binary": "c3VyZS4=" }
    }

参考文献

json - さまざまなタイプの JSON

3 に答える 3

Related

Reference