Web データストレージ: Cookie、UserData、SessionStorage、WebSqlDatabase

クッキー

これはクライアントブラウザの状態を保存するための標準的な方法です。Cookie はブラウザが誕生してすぐに登場したようです。なぜ Cookie が必要なのでしょうか? HTTP プロトコルには状態がないため、クライアントブラウザとサーバーが通信するときにクライアントブラウザの現在の状態がわかるように、クライアントブラウザの現在の状態を記録するフラグ/ストレージが必要です。 Cookie はこの状態を記録するコンテナです。Cookie はリクエストごとにサーバーに返されるため、サーバーはブラウザの現在の状態を把握できます。Cookie はサーバーに返されるため、Cookie の内容は多すぎることはなく、最大でも 4K を超えることはできません。4K 制限の紹介は http://ec.europa.eu/ipg/standards/cookies/index_en.htm をご覧ください。
その一節にはこう書かれている。

ブラウザに必要なのは、全体で最大 300 個の Cookie を保存し、各ドメインの最新の 20 個だけを維持することです。Cookie の最大サイズは 4K のディスク領域です。

ただし、シナリオによっては、4K 以上のデータを保存する必要が生じる場合がありますが、このデータはリクエストが行われるたびにサーバーに戻す必要はありません。顧客のブラウザに保存でき、Javascript で簡単に読み書きできる限り、問題ありません。この要求は、中規模および大規模 RIA のアプリケーションシナリオでは特に切実です。帯域幅を節約し、閲覧速度を向上させるために、一部のデータは顧客のブラウザに配置されます。 HTML5 標準では、sessionStorage、webSqlDatabase など、このニーズを満たすソリューションがすでに提供されており、Microsoft の IE には userData ソリューションがあります。

ユーザーデータ
Microsoft による USERDATA の紹介: http://msdn2.microsoft.com/en-us/library/ms531424(VS.85).aspx
その一節にはこう書かれている。

セキュリティ警告：セキュリティ上の理由から、UserData ストアは、ストアを永続化するために使用される同じディレクトリおよび同じプロトコルでのみ使用できます。
セキュリティ警告: この動作を誤って使用すると、アプリケーションのセキュリティが侵害される可能性があります。UserData ストアのデータは暗号化されていないため、安全ではありません。UserData が保存されているドライブにアクセスできるすべてのアプリケーションがデータにアクセスできます。したがって、クレジットカード番号などの機密データを保持しないことをお勧めします。詳細については、「セキュリティに関する考慮事項: DHTML と既定の動作」を参照してください。
…
userData 動作は、各オブジェクトに対して 1 つの UserData ストアを使用して、セッション間でデータを保持します。UserData ストアは、save メソッドと load メソッドを使用してキャッシュに保持されます。UserData ストアが保存されると、Microsoft Internet Explorer を閉じて再度開いた場合でも、再読み込みできます。
html、head、title、または style オブジェクトに userData 動作クラスを設定すると、save メソッドまたは load メソッドが呼び出されたときにエラーが発生します。

UserData は同じディレクトリで同じプロトコルを使用してアクセスでき、クライアントマシンに長期間保存されます。最大ストレージ容量も大幅に増加しました。 UserData は Dom 要素にバインドする必要があります。 userData メソッドには removeAttribute メソッドがあります。コードをテストした後、removeAttribute メソッドはあまり役に立たないことがわかりました。userData 属性を完全に削除するには、cookie 有効期限などのメソッドを使用する必要があります。
http://www.itwen.com/04web/11skill/skill20060918/60588.html では、userData は X:\Documents and Settings\current user\UserData\ ディレクトリに保存されると紹介されています。 MS は、userData ドキュメントで具体的な詳細を提供していません。

セッションストレージ
HTML5 標準の sessionStorage の紹介: http://www.whatwg.org/specs/web-apps/current-work/
sessionStorageの導入:

この仕様では、クライアント側で構造化データを保存するための、HTTP セッションクッキー [RFC2965] に似た 2 つの関連メカニズムを導入しています。
1 つ目は、ユーザーが単一のトランザクションを実行しているが、同時に異なるウィンドウで複数のトランザクションを実行する可能性があるシナリオ向けに設計されています。
クッキーは、実際にはこのケースをうまく処理しません。たとえば、ユーザーが同じサイトを使用して、2 つの異なるウィンドウで航空券を購入するとします。サイトがクッキーを使用してユーザーが購入する航空券を追跡する場合、ユーザーが両方のウィンドウでページ間をクリックしたときに、現在購入中の航空券が 1 つのウィンドウから別のウィンドウに「漏れ」、ユーザーが気付かないうちに同じフライトの航空券を 2 つ購入してしまう可能性があります。
これに対処するために、この仕様では sessionStorage DOM 属性を導入しています。サイトはセッションストレージにデータを追加することができ、そのウィンドウで開かれたオリジンのどのページからもアクセスできるようになります。

Html5 セッションストレージデモ: http://html5demos.com/storage
以下は、http://www.blogjava.net/emu/archive/2006/10/04/73385.html に従った IE FF 互換の userData のテストコードです。

コードをコピー

コードは次のとおりです。

関数isIE() {
!!document.all を返します。
}
関数initUserData() {
if (isIE()) document.documentElement.addBehavior("#default#userdata");
}
関数 saveUserData(キー, 値) {
var ex;
if (isIE()) {
//IE
(document.documentElement) で試してください {
ロード(キー);
setAttribute("値", 値);
保存(キー);
getAttribute("値"); を返します。
} キャッチ (例) {
アラート(例:メッセージ)
}
} それ以外の場合 (window.sessionStorage) {
//FF2.0以降
試す {
sessionStorage.setItem(キー、値)
} キャッチ (例) {
警告(例);
}
} それ以外 {
alert("ユーザーデータの保存中にエラーが発生しました。お使いのブラウザはユーザーデータをサポートしていません。");
}
}
関数loadUserData(キー) {
var ex;
if (isIE()) {
//IE
(document.documentElement) で試してください {
ロード(キー);
getAttribute("値"); を返します。
} キャッチ (例) {
アラート(ex.message); nullを返します。
}
} それ以外の場合 (window.sessionStorage) {
//FF2.0以降
試す {
sessionStorage.getItem(キー) を返す
} キャッチ (例) {
警告(例)
}
} それ以外 {
alert("ユーザーデータの読み込み中にエラーが発生しました。お使いのブラウザはユーザーデータをサポートしていません。")
}
}
関数deleteUserData(キー) {
var ex;
if (isIE()) {
//IE
(document.documentElement) で試してください {
ロード(キー);
有効期限 = new Date(315532799000).toUTCString();
保存(キー);
}
キャッチ（例）{
アラート(例:メッセージ);
}
} それ以外の場合 (window.sessionStorage) {
//FF2.0以降
試す {
sessionStorage.removeItem(キー)
} キャッチ (例) {
警告(例)
}
} それ以外 {
alert("ユーザーデータの削除中にエラーが発生しました。お使いのブラウザはユーザーデータをサポートしていません。")
}
}

userData と sessionStorage の共通点は、どちらのオブジェクトも Cookie よりもはるかに多くのコンテンツを保存できることです。また、リクエストごとにサーバーに返されることはありません。しかし、Html5 標準とテストによると、userData と sessionStorage は多くの場所で異なることがわかります。

以下はテストページです:
31_110118_jg9ncookieVsStoragegif

SetInsurance リンクは、IE では userData、FF では sessionStore を使用してデータを書き込み、JavaScript を操作します。 IE の場合、書き込まれた値は IE を閉じたりマシンを再起動したりしても失われません。 FF の状況は非常に興味深いです。このページに書き込まれた値は、このページおよびこのページによって開かれた他のページからアクセスできます。しかし、このページが開いている場合でも、ナビゲーションバーにアドレスを入力してこのページを開くと、保存された値にアクセスすることはできません。このページに保存されている値は、親ページ（このページを開いたページ）ではアクセスできません。 Html5標準をもう一度調べてみました。 sessionStorage の完全な名前は、クライアント側のセッションと名前/値のペアの永続的なストレージです。これは、クライアントに保存されているコンテンツがセッション関連であり、保存された値がセッションによって維持されることを意味します。セッションが中断または失われると、保存された値は消えます。そのため、ページにセッションがない場合（親ページ、アドレスバーで開いたページ）、値を取得できません。 FF をシャットダウンしたり、マシンを再起動したりすると、必然的に値は取得されなくなります。

webSqlデータベース
webSqlDatabase は HTML5 標準の非常に優れた機能です。SQL クエリを JavaScript で記述でき、データベースはブラウザー内にあります。これは以前はほとんど想像もできませんでした。しかし、今日では Safari、Chrome、Opera はすべてこれをサポートしています。webSqlDatabase のデモページが 2 つあります: http://html5demos.com/database http://html5demos.com/database-rollback
W3C の WEBSQLDATABASE 紹介ページ: http://dev.w3.org/html5/webdatabase/
Wiki での簡潔な説明: http://en.wikipedia.org/wiki/Web_SQL_Database

W3C より: 「...SQL のバリエーションを使用してクエリできるデータベースにデータを保存するための API」
Web SQLデータベースはGoogle Chrome[1]、Opera、Safariでサポートされていますが、Mozilla(Firefox)[2]では実装されず、代わりにIndexed Database APIアクセスが提案されています。

HTML 5 の SQLDB がブラウザーでどの程度サポートされるかはわかりませんが、sessionStorage は基本的にニーズを満たすことができそうです。

<<: jQueryのコピーオブジェクトの詳細な説明

>>: nginx サーバーでの 502 不正なゲートウェイエラーの原因のトラブルシューティング