--- title: アプリケーションキャッシュの使用 slug: Web/HTML/Using_the_application_cache tags: - Advanced - App - Cache - Guide - HTML - appcache - application cache - web cache translation_of: Web/HTML/Using_the_application_cache ---
このアプリケーションキャッシュ機能を使用しないでください!これはウェブプラットフォームから削除する手続中のものです。
HTML5 は、ウェブアプリケーションをオフラインで実行できるようにするためのアプリケーションキャッシュの仕組みを提供しています。この Application Cache (AppCache) インターフェイスは、ブラウザーがオフラインで利用できるようにキャッシュするべきリソースを列挙します。キャッシュされたアプリケーションは、ユーザーが更新ボタンを押しても、オフラインで読み込まれて正常に動作します。
アプリケーションキャッシュは以下のような利益をもたらします。
アプリケーションでアプリケーションキャッシュを有効にするには、 {{HTMLAttrxRef("manifest", "html")}} 属性をアプリケーションページ内の {{HTMLElement("html")}} 要素に設定してください。
<html manifest="/example.appcache"> … </html>
manifest 属性の値は キャッシュマニフェスト ファイルの URL を参照します。これはアプリケーションのためにブラウザーがキャッシュするべき URL を列挙したテキストファイルです。
キャッシュしてほしいサイトのすべてのページに manifest 属性を含めてください。ブラウザーは manifest 属性のないページは、マニフェストファイルで列挙されていない限りキャッシュしません。マニフェストファイルにキャッシュしてほしいページをすべて列挙する必要はありません。なぜなら、ブラウザーは、ユーザーが訪問したページに manifest 属性があると、暗黙的にアプリケーションキャッシュに追加するからです。
ブラウザーによっては (例: Firefox) は、ユーザーがアプリケーションキャッシュを利用するアプリケーションを読み込む初回時に通知バーを表示します。通知バーは以下のようなメッセージを表示します。
このサイト (example.com) はオフライン作業用データの保存を求めています。 [許可] [このサイトでは保存しない] [今回は保存しない]
「オフライン(利用可能) アプリケーション」という表現は、ときに、ユーザーがオフライン機能を利用することを許可したアプリケーションを具体的に指すこともあります。
アプリケーションキャッシュの利用は文書を読み込む通常のプロセスを変更します:
文書を読み込み、アプリケーションキャッシュを更新するプロセスの詳細は以下のようになります。
manifest 属性を含む文書を訪れたとき、アプリケーションキャッシュが存在しなければ、文書を読み込んでから、マニフェストファイルに列挙されたすべてのエントリーを取得して、アプリケーションキャッシュの最初のバージョンを作成します。window.applicationCache オブジェクトに checking イベントを送り、適切な HTTP キャッシュ規則に従い、マニフェストファイルを取得します。applicationCache オブジェクトに noupdate イベントを送り、更新プロセスは完了します。サーバー上のキャッシュされたリソースを変更する場合、マニフェストファイル自身も変更する必要があることに注意してください。そうすることで、ブラウザーはすべてのリソースを再び取得する必要があることを知ります。applicationCache.add() が呼ばれたことによってキャッシュに追加されたファイルが、適切な HTTP キャッシュ規則に従い、一時キャッシュに取得されます。この一時キャッシュに取得された各ファイル毎に、ブラウザーは applicationCache オブジェクトに progress イベントを送ります。エラーが起こった場合、ブラウザーは error イベントを送り、更新は中止されます。applicationCache オブジェクトに cached イベントを送ります。文書は既にキャッシュからブラウザーに読み込まれているので、更新された文書は文書が(手動かプログラムで)再読込されるまで描画されません。Chrome では、設定の "閲覧履歴データの消去..." を選択することか、chrome://appcache-internals/ を開くことで、オフラインキャッシュをクリアできます。Safari では、設定に、似たような "キャッシュを空にする" がありますが、ブラウザーの再起動も必要になるかもしれません。
Firefox では、オフラインキャッシュデータは Firefox プロファイルに分割して保存されています。以下が通常のディスクキャッシュです:
C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<salt>.<profile name>\OfflineCache/Users/<username>/Library/Caches/Firefox/Profiles/<salt>.<profile name>/OfflineCacheFirefox では、現在のステータスを about:cache ページ ("Offline cache device" の見出しがある箇所) で調査できます。オフラインキャッシュは ツール -> オプション -> 詳細 -> ネットワーク -> オフラインデータ の "削除..." ボタンを利用して各サイト毎に別々にクリアできます。
Firefox 11 以前から Firefox 11 まで、ツール -> 最近の履歴を消去、あるいは、ツール -> オプション -> 詳細 -> ネットワーク -> オフラインデータ -> 今すぐ消去 のどちらでもオフラインキャッシュを消せませんでしたが、このバグは修正されました。
Linux では、設定は Edit > Preferences > Advanced > Network > Offline Web Content and User Data にあります。
DOM Storage データをクリアするも参照してください。
アプリケーションキャッシュはもう利用されない状態にもなり得ます。アプリケーションマニフェストファイルがサーバーーから削除されたとき、ブラウザーはそのマニフェストを利用しているアプリケーションキャッシュをすべて削除し、applicationCache オブジェクトに "obsoleted" イベントを送信します。これはアプリケーションキャッシュの状態を OBSOLETE に設定します。
ウェブアプリケーションでの manifest 属性は、キャッシュマニフェストファイルからの相対パスか絶対 URL のどちらかを指定できます。 (絶対 URL はアプリケーションと同一生成元経由でなければなりません)。キャッシュマニフェストファイルはどんなファイル拡張子でもかまいませんが、text/cache-manifest MIME タイプで提供されなければなりません。
AddType text/cache-manifest .appcache を追加します。キャッシュマニフェストファイルはブラウザーがオフラインアクセスのためにキャッシュすべきリソースを列挙した単純なテキストファイルです。リソースは URI によって区別されます。キャッシュマニフェストに列挙されたエントリーはマニフェストと同じスキーマ、ホスト、およびポートでなければなりません。
以下は、www.example.com にある想像上のウェブサイトのための単純なキャッシュマニフェストファイルである example.appcache です。
CACHE MANIFEST # v1 - 2011-08-13 # これはコメントです。 http://www.example.com/index.html http://www.example.com/header.png http://www.example.com/blah/blah
キャッシュマニフェストファイルは3つのセクション (後述する CACHE, NETWORK, FALLBACK) を含んでいます。上記の例では、セクションヘッダーがありません。そのため、すべてのデータ行は明示的 (CACHE) セクションであるとみなされます。これは、ブラウザーは列挙されたリソースのすべてをアプリケーションキャッシュにキャッシュすべきということを意味します。リソースは絶対、もしくは、相対 URL (例:index.html) のどちらかを用いて指定できます。
上記例での "v1" コメントがあるのには正当な理由があります。ブラウザーがアプリケーションキャッシュを更新するのは、マニフェストファイルがバイト単位で更新されたときだからです。キャッシュされたリソースを変更したとき (例えば、 header.png 画像を新しい画像に差し替えた場合)、ブラウザーにキャッシュの更新が必要であることを知らせるためにマニフェストファイルの内容も変更する必要があります。どんな変更でもマニフェストファイルに対して行うことができますが、バージョン番号を修正することが、おすすめできるベストプラクティスです。
CACHE, NETWORK, FALLBACKマニフェストには3つの性質が異なるセクション、 CACHE、NETWORK、FALLBACK があります。
CACHE:CACHE: セクションヘッダー下 (もしくは CACHE MANIFEST の行の直後) に列挙されたファイルは、それらが初回時にダウンロードされた後に明示的にキャッシュされます。NETWORK:キャッシュマニフェストファイルにおける NETWORK セクションヘッダー下に列挙されたファイルは、サーバーーに接続する必要があるホワイトリスト化されたリソースです。ユーザーがオフライン状態であっても、これらのリソースへのリクエストはすべてキャッシュを無視します。ワイルドカードが利用できます。FALLBACK:FALLBACK: セクションは、リソースにアクセス不可能な場合にブラウザーが利用すべき代替ページを指定します。このセクションにおける各エントリーには 2 つの URI を列挙します。具体的には、最初はリソースであり、2 番目は代替リソースです。両方の URL は相対で、マニフェストファイルと同一生成元経由でなければなりません。ワイルドカードが利用できます。CACHE, NETWORK, FALLBACK の各セクションは、キャッシュマニフェストファイル内でどんな順番でも列挙でき、各セクションは単一のマニフェストにおいて、複数回定義することができます。
以下は、 www.example.com にある想像上のウェブサイト向けのより完全なキャッシュマニフェストファイルです:
CACHE MANIFEST # v1 2011-08-14 # これは別のコメントです index.html cache.html style.css image1.png # 利用可能ならネットワーク経由で利用する NETWORK: network.html # 代替コンテンツ FALLBACK: . fallback.html
この例は NETWORK と FALLBACK セクションを用いて、 network.html ページは常にネットワーク経由で取得し、 fallback.html ページは代替リソース (例えば、サーバーへの接続ができない場合) として提供されるべきであることを指定しています。
キャッシュマニフェストファイルは text/cache-manifest という MIME タイプで提供される必要があります。この MIME タイプを使って提供されるすべてのリソースは、このセクションで定義されている、アプリケーションキャッシュマニフェストのための構文に従う必要があります。
キャッシュマニフェストは UTF-8 形式のテキストファイルで、任意で BOM 文字を含むこともできます。改行文字は、ラインフィード (U+000A)、キャリッジリターン (U+000D)、あるいはその両方で表すことができます。
キャッシュマニフェストの1行目は、ゼロあるいはそれ以上のスペースまたはタブ文字に続けて「CACHE MANIFEST」という文字列で構成される必要があります。2 つの単語の間にはひとつのスペース (U+0020) が含まれます。1行目に書かれたそれ以外の文字列は無視されます。
キャッシュマニフェストの残りの部分は、ゼロあるいはそれ以上の、以下の行によって構成されます:
# 文字に続くゼロあるいはそれ以上のスペースまたはタブ文字と、それに続くゼロあるいはそれ以上のコメント文字列によって構成されます。コメントは (最初の CACHE MANIFEST 行の後の) 単独の行のみで用いることができ、他の行に付加することはできません。これは、フラグメント識別子を指定できないことを意味します。
セクションヘッダー 説明 CACHE:キャッシュマニフェストの明示的セクションに切り替えます。これは既定のセクションです。 NETWORK:キャッシュマニフェストのオンラインホワイトリストセクションに切り替えます。 FALLBACK:キャッシュマニフェストの代替セクションに切り替えます。
CACHE:) セクションでは、各行は、キャッシュのリソースを参照する妥当な URI または IRI です(このセクションではワイルドカード文字は一切利用できません)。各行の URI または IRI の前後には空白を含めることも可能です。 Fallback セクションでは、各行は、リソースと、それに続いて、サーバーとの接続ができないときに提供される代替リソースを参照する妥当な URI または IRI です。ネットワークセクションでは、各行は、ネットワークから取得できるリソースを参照する 妥当な URI または IRI です(このセクションではワイルドカード文字である * が利用できます)。
キャッシュマニフェストは、それぞれのセクションを任意で行き来することができます (つまり、各セクションヘッダを複数回用いることができます)。また、セクションを空白にしておくことも許容されています。
アプリケーションキャッシュには、少なくとも 1 つの URI で識別されるリソースが常に含まれています。すべてのリソースは以下のカテゴリのいずれかに当てはまります。
manifest 属性を使用してこのキャッシュにあることを示す文書が含まれていたためにキャッシュに追加されたリソースです。リソースのカテゴリについては、以下で詳しく説明します。
マスターエントリとは、 {{HTMLAttrxRef("manifest", "html")}} 属性を {{HTMLElement("html")}} 要素に含む HTML ファイルのことです。例えば、http://www.example.com/entry.html という HTML ファイルがあるとします。
<html manifest="example.appcache"> <h1>アプリケーションキャッシュの例</h1> </html>
entry.html が example.appcache キャッシュマニフェストファイルに掲載されていない場合、 entry.html ページにアクセスすると、 entry.html がマスターエントリとしてアプリケーションキャッシュに追加されます。
明示的なエントリは、キャッシュマニフェストファイルの CACHE セクションに明示的にリストされたリソースです。
キャッシュマニフェストファイルの NETWORK セクションは、ウェブアプリケーションがオンラインアクセスを必要とするリソースを指定します。アプリケーションキャッシュ内のネットワークエントリは本質的に「オンラインホワイトリスト」であり、 NETWORK セクションで指定された URI はキャッシュの代わりにサーバーから読み込まれます。これにより、ブラウザーのセキュリティモデルは、承認されたリソースへのアクセスを制限することで、潜在的なセキュリティ侵害からユーザーを保護することができます。
例として、ネットワークエントリを使用して、キャッシュの代わりにサーバーからスクリプトなどのコードをロードして実行することができます。
CACHE MANIFEST NETWORK: /api
上記のキャッシュマニフェストセクションは、 http://www.example.com/api/ サブツリーに含まれるリソースをロードするリクエストが、キャッシュにアクセスしようとせずに常にネットワークに移動することを保証します。
html 要素に設定された manifest 属性を持つファイル) をマニフェストファイルから単に省略しても、マスターエントリはアプリケーションキャッシュに追加され、その後アプリケーションキャッシュから提供されるため、同じ結果にはなりません。フォールバックエントリは、リソースの読み込みに失敗したときに使用されます。例えば、キャッシュマニフェストファイル http://www.example.com/example.appcache に以下の内容が含まれているとします。
CACHE MANIFEST FALLBACK: example/bar/ example.html
http://www.example.com/example/bar/ またはそのサブディレクトリとそのコンテンツへのリクエストにより、ブラウザーはリクエストされたリソースの読み込みを試みるためのネットワークリクエストを発行します。この試みがネットワーク障害や何らかのサーバーエラーのために失敗した場合、ブラウザーは代わりに example.html というファイルをロードします。
各アプリケーションキャッシュは、キャッシュの現在の状態を示す状態を持っています。同じマニフェスト URI を共有するキャッシュは同じキャッシュの状態を共有します。
UNCACHEDIDLECHECKINGDOWNLOADINGUPDATEREADYupdateready イベントがあり、新しい更新プログラムがダウンロードされたが swapCache() メソッドを使用してまだ有効化されていない場合に cached イベントの代わりに発生します。OBSOLETEJavaScript を使用して、アプリケーションが更新されたキャッシュマニフェストファイルを持っているかどうかをプログラムでテストすることができます。スクリプトが更新をテストするためにイベントリスナーをアタッチする前にキャッシュマニフェストファイルが更新されている可能性があるので、スクリプトは常に window.applicationCache.status をテストする必要があります。
function onUpdateReady() {
console.log('found new version!');
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
onUpdateReady();
}
新しいマニフェスト ファイルのテストを手動で開始するには、 window.applicationCache.update() を使用してください。
other-cached-page.html?parameterName=value) を使用してキャッシュされたファイルにアクセスしないでください。これは、ブラウザーがキャッシュをバイパスしてネットワークから取得しようとすることになります。 JavaScript で解析されたパラメータを持つキャッシュされたリソースにリンクするには、リンクのハッシュ部分に other-cached-page.html#whatever?parameterName=value のような引数を使用します。window.applicationCache.swapCache() を使用してプログラムで行うことができますが、すでに読み込まれているリソースは影響を受けません。リソースが新しいバージョンのアプリケーションキャッシュから読み込まれるようにするには、ページをリフレッシュするのが理想的です。*.appcache ファイルの expires ヘッダを設定して、すぐに期限切れになるようにすることをお勧めします。これにより、マニフェストファイルをキャッシュするリスクを回避することができます。例えば、 Apache ではこのような設定を次のように指定することができます。ExpiresByType text/cache-manifest "access plus 0 seconds"{{Compat("html.elements.html.manifest")}}