25

次の JSON 応答を検討してください。

[{
    Name: 'Saeed',
    Age: 31
}, {
    Name: 'Maysam',
    Age: 32
}, {
    Name: 'Mehdi',
    Age: 27
}]

これは少量のデータには問題なく機能しますが、大量のデータ (たとえば、何千ものレコードなど) を提供したい場合は、応答 JSON でプロパティ名の繰り返しを何らかの方法で防止することが論理的であるように思われます。

私はその概念 (DRYing JSON) をグーグル検索しましたが、驚いたことに、関連する結果が見つかりませんでした。もちろん、1 つの方法は、単純な自家製のアルゴリズムを使用して JSON を圧縮し、それを消費する前にクライアント側で解凍することです。

[['Name', 'Age'], 
['Saeed', 31], 
['Maysam', 32], 
['Mehdi', 27]]

ただし、ベスト プラクティスは、各開発者が車輪の再発明を試みるよりも優れています。これについて広く受け入れられている有名なソリューションを見たことがありますか?

4

5 に答える 5

15

まず第一に、JSON はデータを表現する最もコンパクトな方法ではありません。これは、それ以上解析せずにすぐに使用できるように設計された JavaScript データ構造に直接解析可能であることを意図しています。サイズを最適化する場合は、JSON を自己記述したくない可能性が高く、データを処理して使用する方法についてコードで一連の仮定を作成し、受信時に手動で解析できるようにする必要があります。終わり。スペースを節約できるのは、これらの仮定と追加のコーディング作業です。

サーバー応答のプロパティ名と形式がコードで既にわかっている場合は、データを交互の値の配列として返すことができます。

['Saeed', 31, 'Maysam', 32, 'Mehdi', 27]

または、名前にカンマが含まれていないと仮定しても安全な場合は、カンマで区切られた文字列を返すこともできます。これを分割して独自のデータ構造に貼り付けることができます。

"Saeed, 31, Maysam, 32, Mehdi, 27"

または、それでも有効なJSONにしたい場合は、その文字列を次のように配列に入れることができます。これは、アイテム自体が配列要素である最初のバージョンよりもわずかに優れています:

["Saeed, 31, Maysam, 32, Mehdi, 27"]

これらの仮定とコンパクトさにより、独自の JavaScript でデータを解析する責任が大きくなりますが、最初に使用した完全な JSON の自己記述的な性質を取り除くことで、よりコンパクトな性質につながります。

于 2012-12-30T07:53:11.310 に答える
10

解決策の 1 つは、hpack アルゴリズムとして知られています。

https://github.com/WebReflection/json.hpack/wiki

于 2012-12-30T07:31:09.460 に答える
7

プロパティ名は 1 回しか指定しないため、JSON の代わりに CSV 形式を使用できる場合があります。ただし、これには、例のような厳格な構造が必要です。

JSON は、実際に DRY に適した種類のものではありません。JSON で何ができるかを考えると、すでに十分にパッケージ化されているからです。個人的には、後で使用するためにファイルに格納される JSON データにはベア配列を使用しましたが、単純な AJAX 要求の場合はそのままにしておきます。

DRY は通常、自分で記述したものを指します。そのため、オブジェクトが動的に生成されている場合でも、気にする必要はありません。

于 2012-12-30T07:33:39.090 に答える
5

通常、ほとんどの Web サーバーとクライアントに容易に組み込まれている gzip 圧縮を使用しますか?

両端で JSON を生成および解析するには、まだいくらかの (余分な) 時間とメモリが必要ですが、ネットワーク経由で送信するのにそれほど時間はかからず、最小限の実装作業で済みます。

ソースデータを何らかの方法で事前に圧縮したとしても、一見の価値があるかもしれません。

于 2012-12-30T11:24:26.090 に答える
1

多くの場合、大量の文字列または「プロパティ」の重複が発生することは、実際にはJSONの問題ではありません（XMLの問題でもありません）。

これはまさに、DEFLATE アルゴリズム アドレスの重複文字列除去コンポーネント (GZip で使用) です。

ほとんどのブラウザー クライアントは GZip 圧縮された応答を受け入れることができますが、サーバーに戻るトラフィックは受け入れられません。

「JSON圧縮」（つまり、 hpackまたはその他のスキーム）の使用を保証しますか？

  1. Javascript で GZip 圧縮を実装するよりもはるかに高速になる可能性は低いです (これは不可能ではありません。適度に高速なマシンでは、250 ミリ秒で 100 KB を圧縮できます)。

  2. 信頼されていない JSON 入力を安全に処理することはかなり困難です。ストリームベースの解析を使用して、複雑さの最大しきい値を決定する必要があります。そうしないと、サーバーが予期せぬ事態に陥る可能性があります。たとえば、Armin Ronacher のStart Writing More Classesを参照してください。

    きちんとした小さな Web サーバーが gevent を介して 1 秒あたり 10000 のリクエストを取得しているが、json.loads を使用している場合、すべての CPU を占有する、巧妙に作成され、ネストされた 16 MB の JSON をサーバーに送信することで、クロールを停止させることができます。

于 2013-03-01T09:41:20.257 に答える