ディレクトリ
A、ウェブストレージの概念の紹介
1.ウェブストアとは何ですか？
（この代わりにウェブストレージの前記ストレージレベルの広いウェブであることに注意）これは、少量のデータのローカルストレージのクライアント（例えばブラウザ）によってウェブ・ストレージ・ウェブ通信処理を指します。ウェブストレージ古いクッキーなどの種類だけでなく、HTML5のsessionStorage、のlocalStorageとのIndexedDBの導入など。
ウェブホスティング環境は、通常はブラウザが提供するJavaScriptのインターフェースと、ブラウザに保存されている、我々は、変更、検索データにこれらの追加と削除を達成することができます。
2.なぜウェブストア？
これは、最初からクッキーの最も古いものです。
出生クッキーは矛盾に由来します。httpプロトコルはステートレスで、サーバーと異なるクライアントの実際のニーズの区別があります。
まずステートレスなHTTPプロトコルを理解しています。ステートレスを指し、任意のデータ転送のためにHTTPプロトコルにはメモリ容量がありません。あなたのサービスとクライアントがメッセージを送信した場合、その後、サーバは別のメッセージを送信し、サーバが同じクライアントからのこれら2つのメッセージを知ることができない近づきました。
彼らは深刻な同時サーバーの能力を制限することができ、大のサーバの消費、のパフォーマンス上のすべてのクライアントの接続状態を維持したいので、あなたは、HTTPプロトコルにしたい理由は、ステートレスに設計されています。そして、ほとんどの場合、この状態はどんなメリットをもたらすものではありません維持します。だから、デザイナー、HTTPプロトコルは、単純な状態を維持しません。
しかし、多くの場合、サーバーは、異なるクライアント間を区別しなければなりません。注文要求を受け取ると、サーバはそれが現在のシングルログイン要求と同じクライアント（またはクライアントそれぞれからの以前の要求を知っていなければならないことを要求されたユーザー、次のいずれか、知っている必要があり、淘宝網にそれを取ります回は）自分のアカウント情報にリクエストを送信し、すべてのパラメータを取る必要があります。
この目的を達成するために、サーバーの設計セッション（セッション）のメカニズム。ユーザーがログオンした後、サーバは、ユーザに関連付けられている（例えば、ユーザ名、ログイン時間、など）のパラメータを記憶し、ユーザのためのセッション・オブジェクトを作成し、ユーザまでのオブジェクトは、ログアウトまたはログインタイムアウトが破壊されます。各セッション・オブジェクトであれば、クライアントは、次にIDに送信される要求で搬送されるように、サーバが送信されるユーザ要求を判断することができる、固有のIDを有しています。
このように、クライアントはそれがにログインする前に各要求のIDを運ぶことができることを確認するためにIDを格納するためのメカニズムを持っている必要があります。だから、クッキーが誕生しました。
ユーザーがログオンには、サーバがユーザ（セッション）のセッションオブジェクトを作成すると、サーバのセッションオブジェクトIDパラメータ書かれた応答がクライアントに送信されます。クライアントはブラウザに保存された抽出されたパラメータに対するレスポンスを受信します。各後続の送信要求時のユーザからの要求と判断してもよい。このサーバIDに従って、このIDを運びます。この特定のフィールドは、（クッキーのみのidセッションを保存することができ、もちろん、あなたはまた、他のパラメータを格納することができます）クッキーと呼ばれる、IDを格納するために使用されます。
だから、基本的な役割は、サーバーが別のクライアントを区別しやすくするために、ユーザーIDのクッキーを運ぶことです。
メモリのクッキータイプの後：理由のsessionStorage、のlocalStorageとのIndexedDBは、非常にシンプルな表示されます。ブラウザに保存されているより多くのセッションデータは、あなたはそれを、このクッキーを使用することもできるが、（サイトのパフォーマンスを向上させ、ネットワークトラフィックを削減することができますが、個々の能力は4キロバイトである、それは）そのような目的には適していません。
二、詳細なウェブストレージ
1.クッキー
我々はここでは詳細にcookieのソースを持っていますが、上記のクッキーの使用状況や機能を導入することです。
クッキーHTTPクッキーと呼ばれる値が格納されている=フォーム名が文字列の一部としてHTTPリクエストヘッダのSet-Cookie HTTPレスポンスで送信されます。遠位端への応答を受信した後、それは、ブラウザクッキーに格納され、文字列たびにユーザ要求を伝送します。
：document.cookieクッキーのような、フロントエンドで得ることができます
> document.cookie
< "_ga=77911531582348967; _gid=10966846041582958782"
_gaと_gid、二つのパラメータは、セミコロンとスペースで区切って：クッキーの上に二つのパラメータの合計を格納します。クッキーはは、decodeURIComponentに対応し、対応する復号値を与えるために、中国、必要性が含まれている場合、encodeURIComponentでクッキー自体は、それゆえ、符号化、およびされています。
キーと値の他に、各パラメータもdocument.cookie出力を使用する場合、これらのパラメータは見ることができないなど、ドメイン、パス、有効期限、安全標識、を含むいくつかの他の特性を伝送するが、デバッグ・ツールで見ることができます。
つまり、いくつかのパラメータは上記のとおりです。
- キー、キー名。
- 値、キー値。
- つまり、サイトのドメインが配置されているドメイン、Cookieドメインは、クッキーのドメインは大文字とポート番号ではないことに留意すべきです。
- パスは、クッキーのストレージ・パスは、デフォルトのパスは、現在のプロジェクトのルートです。
- /マックス・エイジ、クッキーの有効期限は、ミリ秒単位で有効期限。デフォルトでは設定されていないときに、セッションで失敗期限が切れます。
- サイズ、クッキーの大きさ。
- HttpOnlyの、唯一のHTTPリクエストの送信による場合。（例えばセッションIDなど）いくつかの重要なクッキーは、背景だけで設定することができ、あなたがこのフラグを設定することができ、修正するための自由ではありません。
- セキュア、安全標識。パラメータを設定した後、HTTPSのみでクッキーがリクエストが実行されます。
- ：SameSiteは、CSRF攻撃とトラックユーザーと新しいセキュリティプロパティを防ぐために、特にルアンYifengを参照してくださいクッキーのSameSiteプロパティ。
のみに関連付けられたログイン情報を保存するための一般的な、クッキーには、最も重要なのは、サーバー側のセッションID（セッション）のオブジェクトです。ブラウザは4キロバイトを超えることはできない各クッキーのサイズを制限するので、大量のデータを格納するには適していません。また、ブラウザのクッキーが制限の下でも、単一のドメインの数で、数はブラウザによって異なり、開発者のために、この数は、一般的に20以上のではありません。
デフォルトのクッキーを使用すると、手動で変更することができ、セッションの終了時に失効するmax-ageか、Expires以前の定義されているクッキー、クッキーの有効期限を設定するためのパラメータ後者はクッキーがいくつかの点で不合格に定義されている間、何秒後に期限切れ。両方のこれら2つのパラメータの場合、最大エージング優先順位が高いです。
非常に単純なパラメータのクッキーを追加します。
document.cookie = "name=oeschger";
document.cookie = "favorite=tripe;max-age=120;path=/";
alert(document.cookie);
// 显示: name=oeschger; favorite=tripe
私たちが好きなのために設定されているが、他のパラメータは、document.cookieをプリントアウトし、彼らがまだ有効であるされていないことに注意してください。セッション名サーバの破壊は、120秒後に失敗したのお気に入りになる時には、上記の例では、失敗します。
ダイレクトインターフェイスパラメータを提供していません削除クッキーは、それはパラメータが0に設定されているか、現在の時刻を設定するなどの目的を達成するために、クッキーを削除し、すぐに無効にするために有効期限最大エージングすることによって得ることができます。
document.cookie = "favorite=; max-age=0;";
これは好みのクッキーから削除することができます。
クライアントとしてCookieストアは、大きな利点があり、影響のエンドアーキテクチャは、サービスではありません。私たちは、分散型アーキテクチャでは、さまざまなサーバー間で共有することは困難でセッションを知っています。クッキーは、それがどのサーバーに送信することができ、それがクライアントに格納され、絶対的に問題ではありません。
同時に、クッキーは、いくつかの明らかな欠点があります。クライアントの認証情報に保存されたセキュリティ上の問題、クッキーは、盗まれた場合には、予測不可能な損失をもたらす可能性があります。上記のもう一つの問題はそれほど広くウェブCookieストアを使用していない容量、です。また、クッキーの通信性能コストは無視することはできません。クッキーのすべてのパラメータは、あなたがバックエンドにリクエストを送信するたびに実行されますのでクッキーが大きい場合、それは、サイトの応答速度に影響を与え、すべてのHTTP要求量が増加につながります。要約すると、ユーザ認証情報の非常に少ない量、およびクッキーの暗号化ポリシー伝送のセキュリティを確保する必要性を保存するためにのみクッキー。
2.のsessionStorage和のlocalStorage
なぜそれがこれら2にまとめ紹介？
それらはから継承されているのでStorage、文法の原則とインターネットの2つの間の類似点と相違点に関する記事を多数導入していることを、高い類似性を持っています。彼らの共通点で見てみましょう：
（1）同じ点
ブラウザに保存されているどちらの原理において、。前者は呼ばれている「セッションストレージ」と呼ばれる「ローカルストレージ。」彼らはwindowオブジェクトに配備されている、それは次の方法でアクセスすることができます。
window.localStorage
// 或者直接访问localStorage
window.sessionStorage
// 或者直接访问sessionStorage
構文両方の2動作は同じである（ここでのlocalStorageに例えば）：
localStorage.setItem("name", "carter"); // 设置name: carter
localStorage.age = "24"; // 设置age: 24
localStorage.getItem("name"); // 获取name的值carter
localStorage.removeItem("name"); // 删除name
localStorage.clear(); // 清空localStorage
上記のsessionStorageの構文。
3.同一生成元ポリシーに従ってください両方。あなたは、データのセキュリティを確保することができますので、それは、唯一の店が同じドメイン内で共有することができ、クロスドメインアクセスすることはできませんです。
4.localStorageのsessionStorageそれぞれが収納スペースの5メガバイトを有し、唯一の文字列データ型を格納します。データの非文字列タイプの場合、典型的には使用が必要JSON.stringify次に文字列の使用に圧縮する方法JSON.parse解析を。
（2）異なる点
1.故障までの時間は両方とも異なっています。
localStorage自体は、ブラウザを閉じても、だまされてはいけないことができ、あなたがサイトを訪問し、次回はまだ有効です。localStorageは、有効期限を設定するための直接的な方法を提供していない、我々は定期のlocalStorageを削除するには、特別な戦略を使用する必要があります。
localStorage.setItem("name", JSON.stringify({
value: "carter",
time: (new Date()).getTime() // 保存时间戳
}))
function getItem(key, maxAge){
let obj = localStorage.getItem(key);
if(obj){ // 获取变量值对象
obj = JSON.parse(obj);
}
// 存储时间小于最大生命周期时才读取该参数，否则将其清除
if((new Date()).getTime() - obj.time < maxAge){
return obj.value;
} else {
localStorage.removeItem(key);
return "";
}
}
getItem("name", 60 * 60 * 1000); // 失效时间为1小时
簡単に言えば、ストレージに一緒に時間のlocalStorageを節約時間の値と、手動でタイムアウトか否かを決定することです。
セッションの有効期限が切れたときのsessionStorageセッションは、ページにページをバインドされている。しかし、対応のsessionStorageはクリアされます。sessionStorageは唯一、何らかの方法で（例えば、ブラウザの戻るボタンをクリックするか、機能を回復し、ブラウザのページを使用）する場合、現在のページのページを復元したり、リフレッシュすることである、セッションのページフォルトで期限切れとなる、という注意ページはのsessionStorage、のsessionStorageを作成したときのsessionStorageはと失敗することはありません、他の言葉で、それは常にその滅びるが作成されます。
2つの異なる有効範囲。
クロスドメインなしでは、タブ間のlocalStorageは、現在のタブの範囲内で効果が、のsessionStorageを取ります。
あなたは新しいものを開くと、新しいページが現在のドメインでのlocalStorageページと現在のページとページを共有することになるが、のsessionStorageを共有することができないことをこれが意味。あなたはiframeおよびノークロスドメインで現在のページを開いて、あれば、その後のlocalStorageのsessionStorageはすべて共有することができます。
3.のIndexedDB
5Mスペースが比較的大きくなっていますが、それでもすべてのフロントエンドのストレージ要件を満たすことができません。
ウェブサイトのパフォーマンスを向上させるため、フロントエンドのデータ・キャッシュが巨大であるためです（HTTP、それが効果的に通常サイトカトンにつながる最も重要な要因であるデータ伝送量を減らすことができます）ので、より多くのサイトでは、フロントエンドに傾向がありますより多くのデータを保存します。sessionStorageのlocalStorageと、理由は一方では、彼らの能力だけ5Mサイズを、この需要を満たすことができない。一方、非構造化ストレージ、大量のデータから、彼らは十分に速く動作します。
このため、HTML5の仕様では、トランザクションデータベースのIndexedDBのフロントエンドを開始しました。それは（もちろん、これまで機能性と容量とバックエンドのデータベースから）の読み取りと書き込みの性能はほぼ同等のバックエンドのデータベースを持つ、構造化データを大量に保存することができます。
IndexedDBは、おそらく次のプロセスを使用する必要があります。
- データベースを開きます。
var request = window.indexedDB.open(databaseName, version);
だから、開いたり、新規のIndexedDBデータベースを作成することができます。入ってくるデータベース名が存在しない場合は、新しいデータベースを作成します、または彼らは、既存のデータベースを開きます。データベースのバージョン番号が省略された場合、データベースが既に存在する場合、現在のバージョン、またはバージョン番号にデフォルト設定1。
- イベント登録プロセス
openメソッドの戻りを呼び出した後IDBRequest、オブジェクト、その登録error、success及びupgradeneddedイベントの結果として得られるデータを開くが処理することができます。
errorこれは、データベースのオープンが失敗したことを示します。
request.onerror = function(err){
console.log("数据库打开失败：" + err);
}
successそして、あなたは、データベースの読み出し動作を行うことができ、データベースが正常に開かれていることを示します：
request.onsuccess = function (event) {
let db = request.result;
console.log('数据库打开成功');
};
upgradeneededアップグレードするデータベースのニーズを表し、データベースの内容の各変更は、データベースのバージョンをアップグレードする必要があり、のIndexedDBバックエンドデータベースとは異なります。
request.onupgradeneeded = function (event) {
let db = event.target.result;
}
upgradeneededイベントの必要性故に、新しいデータベース自体に関連する操作は、データベースのアップグレード版として分類されていることに留意すべきです。
request.onupgradeneeded = function (event) {
db = event.target.result;
var objectStore;
if (!db.objectStoreNames.contains('person')) {
objectStore = db.createObjectStore('person', { keyPath: 'id' });
}
}
- 欠失は、検索操作の実行データを変更します
仕事以来のIndexedDB、実務経験の欠如を使用することをまだ持っていたので、一時的にここで詳しく説明。興味のある方は、ルアンYifengを参照してください。ブラウザデータベースのIndexedDB入門チュートリアル。
3つのフロントエンドとバックエンド・ストレージ・ストレージとの間の関係
我々は、貯蔵の4種類全てのフロントエンド・ストレージは、クッキーに加えて、他の三つが直接アクセスされるとJavaScriptによって操作される上に導入しました。
厳密に、なぜ私たちはフロントエンドの店にそれが必要なのか、クッキーに加えて、ストレージの他の3種類が絶対に必要ではない、話しますか？
答えは、HTTPデータ伝送を減らし、サイトのパフォーマンスを改善することです。
私たちは同じ学校の図書館に行くように理解を容易にするために、我々はアナロジーを作るために、サイトにアクセスするためのプロセス全体を入れて、それはです。ライブラリ全体のサイト自体は、本棚には、我々は、バックエンドデータベースを使用しているものであり、本は、すべてのウェブサイトのデータは棚上のデータベースに保存されているということです。
ライブラリのライブラリ管理システムは、ユーザーにオフィスのカード、検索、ボロー、だけでなく、書籍、その他のサービスを提供し、ウェブサイトのサービスの背景です。
ライブラリ内のフロントデスクを読んだように、私たちは、読書テーブルに自分の好きな本を読むことができます。そして、私たちは本を読んで、サイトの静的ページを提供してくれています。
それでは、どのフロントエンドキャッシュそれを理解するには？
私たちが手元に読まれる本を読んで、テーブルの上にあるみたいです。我々は再本棚に審査を終えたびに、効率は明らかに非常に低い場合、我々は、図書館に10冊を見に1を削除する必要がある場合を想像してみてください。これは、私たちが読書のテーブルの上にすべての10本を引き継ぐ初めてです。だから、私たちのために、書籍の机の上に、この10の指先は、我々が棚から本を見つけるために、プロセスを10回繰り返す必要はありませんので、彼らは私たちの近くにそうです、私たちのフロントエンドのキャッシュです。
私たちは、ストレージのさまざまなタイプを理解するための更なるメタファーを作ります。
想像してみて、今のライブラリが予約システムを導入している、それぞれの読者が本にライブラリのアクセスに図書館に来る前に予約をしたいことがあり、ライブラリは別々に配置する準備ができて、これらの数冊の本を進めることができるようになりますその予約された予約領域。各予約エリアは、サーバセッションに格納されているユーザセッション（セッション）オブジェクトに対応しています。
それでは、どのようにライブラリた本は、誰がそれを予定している知っていますか？非常に単純な、カード番号を読む人への各予約領域の対応は、カードはお使いのカードがクッキーを読み取り、対応する書籍の予約領域を、読んで除去することができます。
あなたは、ライブラリの長年のユーザーであれば、あなたは読み取り領域を予約するために、具体的ライブラリーは、あなたは常に、あなたが残していても、ここに自分の本を読むことができ、それは図書館の本をクリーンアップしません。この長期的な調査地域利用可能なのlocalStorageです。
あなただけの普通のユーザであれば、一時的なライブラリの後にエリアを読み取る作品を検索します。あなたはライブラリを去るときに、ライブラリは、あなただけのきれいなうちに学区から本を借りるかかります。あなたは、ライブラリ、あなたは再び借りる必要があり、これらの本に来て、次回は、この一時的な学区でのsessionStorageです。
だから、のIndexedDBそれは何ですか？誰かのニーズは、図書館の本のさまざまなカテゴリを含むブッククラブ、参加者の多数の数を、保持することができる場合。ボローブックに迅速にその参加者を確保するためには、ライブラリーは、すべての照合可能なすべてのブックを使用するように別の領域を開くことを決めた、とブッククラブのための小さなライブラリ管理システムを設計しました。ブッククラブ、ライブラリ全体から、この領域と管理スタイルの異なるに配置された書籍（なぜバックエンドリレーショナルデータベースの使用、およびフロントエンドのトランザクションデータベースを説明する）の特徴の一部以来、あなたが本の小さな量を確保することができますので、場合には、より高い効率を貸します。これは（その子会社のライブラリ管理システムを含む）別の領域を開きますので、フロントエンドデータベースのIndexedDBです。
概要
ストレージは、基本的には完全にデータを一時的に記憶計画の前に隠された形に置き換えられている、Webブラウザの1最も一般的に使用される機能を開発者に提供しています。
その構文を習得するだけでなく、ライフサイクル、ストレージ容量、およびその他の使用シナリオに注意を払うようにするだけでなく、ウェブストレージのすべての種類をマスターしたいと考えています。フロントエンドの技術開発とフロントエンドユーザーエクスペリエンスの要件の継続的な改善では、フロントエンド・ストレージ・サイトの必要性が必然的に成長しているので、現在一般のIndexedDBを使用していない、将来的にも、標準のウェブサイトが呼び出すことができます。フロントエンドの開発者として、彼らはの包括的な理解、そして仕事でより多くの使用、およびより多くの合計を持っている必要があります。
