Webフロントエンドによるローカルストレージの実現
6602 ワード
Webフロントエンドのローカルストレージについて言及するときは、まずローカライズストレージの概念と歴史を紹介する必要があります.ローカライズされたストレージは、Webアプリケーションがデスクトップアプリケーションに匹敵したり、超えたりすることを追求しているため、珍しい概念ではありません.しかし、デスクトップアプリケーションがWebアプリケーションより優れているのは、ローカライズされたストレージがサポートされているためです.ローカル・アプリケーションの場合、オペレーティング・システムは、レジストリ、INIファイル、またはオペレーティング・システムの実装に応じて、ローカル・アプリケーション・シーケンスがキー値ペア形式のローカル・ストレージだけでなく、組み込みデータベースまたは他の多くのソリューションを使用する必要がある場合に、アプリケーション固有のデータを格納および取得する抽象層を提供します.Webアプリケーションでは、ローカルストレージを一歩一歩今日のHTML 5ローカルストレージに移行するのは容易ではありません.その歴史を説明するために、まず写真を見ることができます.
画像から分かるように、ストレージデータのサイズや互換性から見ても、webフロントエンドのローカルストレージは容易ではありません.HTML 5のローカルストレージを重点的に紹介する前に、前のいくつかのストレージ方式の概念を見てみましょう. HTTP cookie:HTTP cookieの欠点は明らかで、最大4 KBのデータしか保存できず、HTTPリクエストごとにサーバに転送され、明示的に転送されます(SSLを使用しない限り).ここでCookieについて簡単に紹介します.CookieはHTTPの無状態の特性を解決するために出現し,ユーザ識別メカニズムと呼ぶこともできる.一般的なユーザー識別メカニズムは次のとおりです. ユーザ情報を担持するHTTPヘッダ .クライアントIPアドレス追跡技術は、ユーザのIPアドレスによって識別する である.ユーザはログインし、認証メカニズムでユーザ を識別する.デブURLは、URLに識別情報を埋め込む技術 である. cookie、強力で効率的な持続的アイデンティティ識別技術
ショッピングサイトにとって、クッキーはとても重要で、ショッピングカートの機能を実現するために、すでに選んだものをクッキーに入れて、異なるページ間のデータの同期を実現することができて、同時に注文を提出する時またこれらのクッキーをバックグラウンドに伝えることができて、大いに前後の発行を便利にしました userDataは、マイクロソフトが1990年代のブラウザ大戦時に発表したローカルストレージスキームであり、DHTMLのbehaviour属性を利用してローカルデータを格納し、各ページに最大64 Kデータを格納することができ、各サイトに最大640 Kデータを格納することができる.userDataの欠点は明らかで、Web標準の一部ではない.プログラムがIEをサポートする必要がない限り、ほとんど役に立たない. Flash Cookieの名前は少し誤解されていますが、実際にはHTTP cookieとは違います.その名前は「Flashローカルストレージ」と呼ぶべきかもしれませんが、Flashクッキーはデフォルトで各サイトに100 K以下のデータを格納できます.それを超えると、Flashは自動的にユーザーにより大きなストレージスペースを要求します.FlashのExternalInterfaceインタフェースを利用して、JavascriptでFlashのローカルストレージを簡単に操作できます.Flashの問題は簡単です.Flashだからです. GearsはGoogleが07年に発表したオープンソースブラウザプラグインで、各ブラウザの互換性を改善することを目的としている.GearsはSQLiteベースの組み込みSQLデータベースを内蔵し、統一APIを提供してデータベースにアクセスし、ユーザーの許可を得た後、各サイトはSQLデータベースにサイズ制限のないデータを格納することができ、Gearsの問題はGoogle自身がそれを使用しなくなったことだ.
上記の概要から、従来、ローカルストレージが直面していた主な問題は、ストレージ容量が大きい方法では、特定のプラグインサポートが必要であることです.プラグインのサポートを必要としないストレージ方式では、セキュリティの問題やサイズの制限によって殺されます.このような二重の矛盾を前に、HTML 5のローカルストレージが登場し、フロントエンドの開発者にとって大きな福音である.
HTML 5ローカルストレージというより正確な言い方はDOMストレージです.MDNの定義による、DOMの格納メカニズムは、文字列タイプのキー/値ペアを格納ことにより、安全なアクセス方式を提供する.この追加機能の目的は、インタラクティブなアプリケーションを作成するための包括的な方法(オフラインでしばらく作業できるなどの高度な機能を含む)を提供することです.
HTML 5のDOMストレージは、SessionStorageとLocalStorageの2種類に分けられています.現代のブラウザでの互換性は以下の通りです.上図で述べたglobalStorageは非標準であり、廃棄されています.ここでは無視します.一方、sessionStorageとlocalStorageは、ほとんどの現代ブラウザでよくサポートされていますが、ほとんどである以上、この2つのオブジェクトをサポートしていないブラウザの世話をしなければなりません.ブラウザがこの2つのオブジェクトをサポートしているかどうかを検出するには、簡単に次のコードで検出できます.
幸いなことに、この2つのオブジェクトの使用方法は非常に簡単です.ここではネット上の図を借ります.まず、sessionStorageを見てみましょう.sessionStorageはグローバルオブジェクトで、ページセッション中に有効なストレージスペースを維持しています.ブラウザが開いている限り、ページセッションサイクルは継続します.ページが再ロードされたり、リカバリされたりすると、ページセッションも常に存在します.新しいラベルまたは新しいウィンドウで新しいページを開くたびに、新しいセッションが初期化されます.この言葉は抽象的に見えますが、demoを直接見てみましょう.
ブラウザで開くと、ウィンドウがポップアップされ、「yuanzm」が表示されます.F 12キーを押して、ブラウザのデバッグウィンドウを表示します.
ブラウザのローカルストレージsessionStorageにkey値が「myname」の項目が既に存在することがわかります.このとき、sessionStorageを呼び出さないと「yuanzm」がポップアップされます.removeItem()または手動でこのアイテムをクリアすると、このアイテムはずっと存在します.「ブラウザが開いている限り、ページ・セッションのサイクルは継続します.ページが再ロードされたり、リカバリされたりするたびに、ページ・セッションは常に存在します.新しいラベルやウィンドウで新しいページを開くたびに、mynameの値を再設定しないと、新しいセッションが開始されます」という意味です.新しいブラウザラベルを開くか、ブラウザウィンドウを再度開くと、この値は存在しません.nullです.これを検証するには、簡単に上の2行のコードの最初の行をコメントしてページをリフレッシュし、新しいブラウザラベルでこのファイルを開きます.この2つの動作はそれぞれどのような効果を生みますか?答えは簡単で、再びページをリフレッシュすると「yuanzm」がポップアップされます.このデータはローカルに保存されているため、コードを変更した後、新しいページで開き、現在のページセッションに「myname」という値がないためnullとなります.
次にlocalStorageを見てみましょう.彼は複数のウィンドウにまたがり、現在のセッションを超える範囲で持続します.ブラウザが閉じてから再開すると、データは依然として使用可能であることを意味します.上記の例では、コードを変更した後も、新しいラベルでページを開くと「yuanzm」がポップアップされ、ブラウザで再び効果を表示します.
この2つのオブジェクトの使用は簡単なので、しばらくここに紹介します.次に紹介したいのが互換性の問題です.理由は簡単です.すべてのブラウザがこの2つのオブジェクトをサポートしているわけではありません.ここでの互換性には、localStorageをサポートしていないブラウザで使用される2つのタイプがあり、2つ目は、異なるブラウザで使用される2つの使い方の違いを互換化することです.1つ目の場合、MDNには互換コードが与えられます.
2つ目はgithubに優れたコードがたくさんあります.ブロガーはその1つをお勧めします.https://github.com/mortzdk/localStorage
画像から分かるように、ストレージデータのサイズや互換性から見ても、webフロントエンドのローカルストレージは容易ではありません.HTML 5のローカルストレージを重点的に紹介する前に、前のいくつかのストレージ方式の概念を見てみましょう.
ショッピングサイトにとって、クッキーはとても重要で、ショッピングカートの機能を実現するために、すでに選んだものをクッキーに入れて、異なるページ間のデータの同期を実現することができて、同時に注文を提出する時またこれらのクッキーをバックグラウンドに伝えることができて、大いに前後の発行を便利にしました
上記の概要から、従来、ローカルストレージが直面していた主な問題は、ストレージ容量が大きい方法では、特定のプラグインサポートが必要であることです.プラグインのサポートを必要としないストレージ方式では、セキュリティの問題やサイズの制限によって殺されます.このような二重の矛盾を前に、HTML 5のローカルストレージが登場し、フロントエンドの開発者にとって大きな福音である.
HTML 5ローカルストレージというより正確な言い方はDOMストレージです.MDNの定義による、DOMの格納メカニズムは、文字列タイプのキー/値ペアを格納ことにより、安全なアクセス方式を提供する.この追加機能の目的は、インタラクティブなアプリケーションを作成するための包括的な方法(オフラインでしばらく作業できるなどの高度な機能を含む)を提供することです.
HTML 5のDOMストレージは、SessionStorageとLocalStorageの2種類に分けられています.現代のブラウザでの互換性は以下の通りです.上図で述べたglobalStorageは非標準であり、廃棄されています.ここでは無視します.一方、sessionStorageとlocalStorageは、ほとんどの現代ブラウザでよくサポートされていますが、ほとんどである以上、この2つのオブジェクトをサポートしていないブラウザの世話をしなければなりません.ブラウザがこの2つのオブジェクトをサポートしているかどうかを検出するには、簡単に次のコードで検出できます.
function storageSupport() {
try {
return 'localStorage' in window && window['localStorage'] !== null;
} catch (e) {
return false;
}
}
幸いなことに、この2つのオブジェクトの使用方法は非常に簡単です.ここではネット上の図を借ります.まず、sessionStorageを見てみましょう.sessionStorageはグローバルオブジェクトで、ページセッション中に有効なストレージスペースを維持しています.ブラウザが開いている限り、ページセッションサイクルは継続します.ページが再ロードされたり、リカバリされたりすると、ページセッションも常に存在します.新しいラベルまたは新しいウィンドウで新しいページを開くたびに、新しいセッションが初期化されます.この言葉は抽象的に見えますが、demoを直接見てみましょう.
var name = sessionStorage.setItem("myname","yuanzm");
alert(sessionStorage.getItem("myname"));
ブラウザで開くと、ウィンドウがポップアップされ、「yuanzm」が表示されます.F 12キーを押して、ブラウザのデバッグウィンドウを表示します.
ブラウザのローカルストレージsessionStorageにkey値が「myname」の項目が既に存在することがわかります.このとき、sessionStorageを呼び出さないと「yuanzm」がポップアップされます.removeItem()または手動でこのアイテムをクリアすると、このアイテムはずっと存在します.「ブラウザが開いている限り、ページ・セッションのサイクルは継続します.ページが再ロードされたり、リカバリされたりするたびに、ページ・セッションは常に存在します.新しいラベルやウィンドウで新しいページを開くたびに、mynameの値を再設定しないと、新しいセッションが開始されます」という意味です.新しいブラウザラベルを開くか、ブラウザウィンドウを再度開くと、この値は存在しません.nullです.これを検証するには、簡単に上の2行のコードの最初の行をコメントしてページをリフレッシュし、新しいブラウザラベルでこのファイルを開きます.この2つの動作はそれぞれどのような効果を生みますか?答えは簡単で、再びページをリフレッシュすると「yuanzm」がポップアップされます.このデータはローカルに保存されているため、コードを変更した後、新しいページで開き、現在のページセッションに「myname」という値がないためnullとなります.
次にlocalStorageを見てみましょう.彼は複数のウィンドウにまたがり、現在のセッションを超える範囲で持続します.ブラウザが閉じてから再開すると、データは依然として使用可能であることを意味します.上記の例では、コードを変更した後も、新しいラベルでページを開くと「yuanzm」がポップアップされ、ブラウザで再び効果を表示します.
この2つのオブジェクトの使用は簡単なので、しばらくここに紹介します.次に紹介したいのが互換性の問題です.理由は簡単です.すべてのブラウザがこの2つのオブジェクトをサポートしているわけではありません.ここでの互換性には、localStorageをサポートしていないブラウザで使用される2つのタイプがあり、2つ目は、異なるブラウザで使用される2つの使い方の違いを互換化することです.1つ目の場合、MDNには互換コードが与えられます.
if (!window.localStorage) {
Object.defineProperty(window, "localStorage", new (function () {
var aKeys = [], oStorage = {};
Object.defineProperty(oStorage, "getItem", {
value: function (sKey) { return sKey ? this[sKey] : null; },
writable: false,
configurable: false,
enumerable: false
});
Object.defineProperty(oStorage, "key", {
value: function (nKeyId) { return aKeys[nKeyId]; },
writable: false,
configurable: false,
enumerable: false
});
Object.defineProperty(oStorage, "setItem", {
value: function (sKey, sValue) {
if(!sKey) { return; }
document.cookie = escape(sKey) + "=" + escape(sValue) + "; path=/";
},
writable: false,
configurable: false,
enumerable: false
});
Object.defineProperty(oStorage, "length", {
get: function () { return aKeys.length; },
configurable: false,
enumerable: false
});
Object.defineProperty(oStorage, "removeItem", {
value: function (sKey) {
if(!sKey) { return; }
var sExpDate = new Date();
sExpDate.setDate(sExpDate.getDate() - 1);
document.cookie = escape(sKey) + "=; expires=" + sExpDate.toGMTString() + "; path=/";
},
writable: false,
configurable: false,
enumerable: false
});
this.get = function () {
var iThisIndx;
for (var sKey in oStorage) {
iThisIndx = aKeys.indexOf(sKey);
if (iThisIndx === -1) { oStorage.setItem(sKey, oStorage[sKey]); }
else { aKeys.splice(iThisIndx, 1); }
delete oStorage[sKey];
}
for (aKeys; aKeys.length > 0; aKeys.splice(0, 1)) { oStorage.removeItem(aKeys[0]); }
for (var iCouple, iKey, iCouplId = 0, aCouples = document.cookie.split(/\s*;\s*/); iCouplId < aCouples.length; iCouplId++) {
iCouple = aCouples[iCouplId].split(/\s*=\s*/);
if (iCouple.length > 1) {
oStorage[iKey = unescape(iCouple[0])] = unescape(iCouple[1]);
aKeys.push(iKey);
}
}
return oStorage;
};
this.configurable = false;
this.enumerable = true;
})());
}
2つ目はgithubに優れたコードがたくさんあります.ブロガーはその1つをお勧めします.https://github.com/mortzdk/localStorage