このページは翻訳中です。
翻訳作業に参加する場合は、履歴にある翻訳者と連絡·調整してください。
非推奨
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.
ここで説明しているアプリケーションキャッシュ機能の使用は、現在とても好ましくありません。これをWeb プラットフォームから削除する手続きを進めています。代わりに Service Worker を使用してください。実際、Firefox 44 ではオフラインサポートのために AppCache を使用すると、代わりに Service Worker を使用するよう開発者に案内する警告メッセージをコンソールに表示します (バグ 1204581)。
はじめに
HTML5 は Web ベースのアプリケーションをオフラインで実行できるようにするためのアプリケーションキャッシュメカニズムを提供します。開発者は、ブラウザがキャッシュし、オフライン状態のユーザが利用できるようにすべきリソースを指定するために Application Cache (AppCache) インターフェースを利用できます。キャッシュが行われたアプリケーションは、ユーザがオフラインになったときに更新ボタンを押した場合でも、正常に読み込まれ、正常に動作します。
アプリケーションキャッシュを利用することは以下の利点をアプリケーションにもたらします:
- オフラインブラウジング: ユーザがオフライン状態であるときにもサイトを閲覧できます。
- 速度: キャッシュされたリソースはローカルに置かれることになり、その結果、より速く読み込まれます。
- サーバ読み込みの削減: ブラウザはサーバから変更されたリソースのみをダウンロードします。
アプリケーションキャッシュはどのように動作するか
アプリケーションキャッシュを有効にする
アプリケーションのためにアプリケーションキャッシュを有効にするには、アプリケーションページ内の html 要素に manifest 属性を含めなければなりません。以下に例を示します:
<html manifest="example.appcache">
...
</html>
manifest 属性の値は キャッシュマニフェスト ファイルへの参照となっています。キャッシュマニフェストファイルは、ブラウザがそのアプリケーションのためにキャッシュすべきリソース（ファイル）を列挙したテキストファイルです。
キャッシュされて欲しいアプリケーションのすべてのページに manifest 属性を含めるべきです。ブラウザは た manifest 属性を持つすべてのページを暗黙的にアプリケーションキャッシュに追加するからです。
いくつかのブラウザ (例: Firefox) は、ユーザがアプリケーションキャッシュを利用するアプリケーションを読み込む初回時に通知バーを表示します。通知バーは以下のようなメッセージを表示します:
このサイト (www.example.com) はオフライン作業用データの保存を求めています。 [許可] [このサイトでは保存しない] [今回は保存しない]
"オフライン(利用可能) アプリケーション" という表現は、ときに、ユーザがオフライン機能を利用することを許可したアプリケーションを具体的に指すこともあります。
ドキュメントを読み込む
アプリケーションキャッシュの利用はドキュメントを読み込む通常のプロセスを変更します:
- アプリケーションキャッシュが存在する場合、ブラウザはドキュメントを読み込んで、それに関連付けられたリソースをネットワークにアクセスせずにキャッシュから直接取得します。これはドキュメントの読み込み時間をスピードアップさせます。
- ブラウザはキャッシュマニフェストがサーバ上で更新されているかどうかをチェックします。
- キャッシュマニフェストが更新されていた場合、ブラウザはマニフェストの新しいバージョンとそのマニフェスト内に列挙されたリソースをダウンロードします。これはバックグランドで行われ、パフォーマンスに大きな影響を与えません。
ドキュメントを読み込み、アプリケーションキャッシュを更新するプロセスの詳細は以下のようになります:
- ブラウザは
manifest属性を含むドキュメントを訪れたとき、アプリケーションキャッシュが存在しなければ、ドキュメントを読み込んでから、マニフェストファイルに列挙されたすべてのエントリーを取得して、アプリケーションキャッシュの最初のバージョンを作成します。 - そのドキュメントへのその後の訪問では、ブラウザはドキュメントとマニフェストファイルで指定されたその他のリソースを（サーバからではなく）アプリケーションキャッシュから読み込みます。さらに、ブラウザは
window.applicationCacheオブジェクトにcheckingイベントを送り、適切な HTTP キャッシュ規則に従い、マニフェストファイルを取得します。 - マニフェストファイルの現在のキャッシュされたコピーが最新であった場合、ブラウザは
applicationCacheオブジェクトにnoupdateイベントを送り、更新プロセスは完了します。サーバ上のキャッシュされたリソースを変更する場合、マニフェストファイル自身も変更する必要があることに注意してください。そうすることで、ブラウザはすべてのリソースを再び取得する必要があることを知ります。 - マニフェストファイルが変更されていた場合、マニフェストに列挙されたファイルのすべて、および、
applicationCache.add()が呼ばれたことによってキャッシュに追加されたファイルが、適切な HTTP キャッシュ規則に従い、一時キャッシュに取得されます。この一時キャッシュに取得された各ファイル毎に、ブラウザはapplicationCacheオブジェクトにprogressイベントを送ります。エラーが起こった場合、ブラウザはerrorイベントを送り、更新は中止されます。 - すべてのファイルが正常に取得されれば、それらは本当のオフラインキャッシュに動的に移動され、
applicationCacheオブジェクトにcachedイベントを送ります。ドキュメントは既にキャッシュからブラウザに読み込まれているので、更新されたドキュメントはドキュメントが（手動かプログラムで）再読込されるまで描画されません。
ストレージの場所とオフラインキャッシュをクリアする
Chrome では、設定の "閲覧履歴データの消去..." を選択することか、chrome://appcache-internals/ を開くことで、オフラインキャッシュをクリアできます。Safari では、設定に、似たような "キャッシュを空にする" がありますが、ブラウザの再起動も必要になるかもしれません。
Firefox では、オフラインキャッシュデータは Firefox プロファイルに分割して保存されています。以下が通常のディスクキャッシュです:
- Windows Vista/7:
C:\Users\<username>\AppData\Local\Mozilla\Firefox\Profiles\<salt>.<profile name>\OfflineCache - Mac/Linux:
/Users/<username>/Library/Caches/Firefox/Profiles/<salt>.<profile name>/OfflineCache
Firefox では、現在のステータスを about:cache ページ （"Offline cache device" の見出しがある箇所）で調査できます。オフラインキャッシュは ツール -> オプション -> 詳細 -> ネットワーク -> オフラインデータ の "削除..." ボタンを利用して各サイト毎に別々にクリアできます。
Firefox 11 以前から Firefox 11 まで、ツール -> 最近の履歴を消去、あるいは、ツール -> オプション -> 詳細 -> ネットワーク -> オフラインデータ -> 今すぐ消去 のどちらでもオフラインキャッシュを消せませんでしたが、このバグは修正されました。
DOM Storage データをクリアするも参照してください。
アプリケーションキャッシュはもう利用されない状態にもなり得ます。アプリケーションマニフェストファイルがサーバーから削除されたとき、ブラウザはそのマニフェストを利用しているアプリケーションキャッシュをすべて削除し、applicationCache オブジェクトに "obsoleted" イベントを送信します。これはアプリケーションキャッシュの状態を OBSOLETE に設定します。
キャッシュマニフェストファイル
キャッシュマニフェストファイルを参照する
Web アプリケーションでの manifest 属性はキャッシュマニフェストファイルからの相対パスか絶対 URL のどちらかを指定できます。（絶対 URL はアプリケーションと同一生成元経由でなければなりません）。キャッシュマニフェストファイルはどんなファイル拡張子でもかまいませんが、text/cache-manifest MIME タイプで提供されなければなりません。
キャッシュマニフェストファイルのエントリー
キャッシュマニフェストファイルはブラウザがオフラインアクセスのためにキャッシュすべきリソースを列挙した単純なテキストファイルです。リソースは URI によって区別されます。キャッシュマニフェストに列挙されたエントリーはマニフェストと同じスキーマ、ホスト、およびポートでなければなりません。
例 1: 単純なキャッシュマニフェストファイル
以下は、www.example.com にある想像上の Web サイトのための単純なキャッシュマニフェストファイルである example.appcache です。
CACHE MANIFEST # v1 - 2011-08-13 # これはコメントです。 https://www.example.com/index.html https://www.example.com/header.png https://www.example.com/blah/blah
キャッシュマニフェストファイルは 3 つのセクション（後述する CACHE、NETWORK、およびFALLBACK CACHE）セクションであるとみなされます。これは、ブラウザは列挙されたリソースのすべてをアプリケーションキャッシュにキャッシュすべきということを意味します。リソースは絶対、もしくは、相対 URL （例：index.html）のどちらかを用いて指定できます。
上記例での "v1" コメントがあるのには正当な理由があります。ブラウザがアプリケーションキャッシュを更新するのは、マニフェストファイルがバイト単位で更新されたときだからです。キャッシュされたリソースを変更したとき（例えば、header.png 画像を新しい画像に差し替えた場合）、ブラウザにキャッシュの更新が必要であることを知らせるためにマニフェストファイルの内容も変更する必要があります。どんな変更でもマニフェストファイルに対して行うことができますが、バージョン番号を修正することが、おすすめできるベストプラクティスです。
キャッシュマニフェストファイルにおけるセクション: CACHE, NETWORK, and FALLBACK
マニフェストには 3 つの性質が異なるセクションがあります: CACHE、NETWORK、および FALLBACK です。
CACHE:- これはキャッシュマニフェストファイルにおけるエントリーの既定のセクションです。
CACHE:セクションヘッダー下（もしくはCACHE MANIFESTの行の直後）に列挙されたファイルは、それらが初回時にダウンロードされた後に明示的にキャッシュされます。 NETWORK:キャッシュマニフェストファイルにおける NETWORKセクションヘッダー下に列挙されたファイルは、サーバーに接続する必要があるホワイトリスト化されたリソースです。ユーザがオフライン状態であっても、これらのリソースへのリクエストはすべてキャッシュを無視します。ワイルドカードが利用できます。FALLBACK:FALLBACK:セクションは、リソースにアクセス不可能な場合にブラウザが利用すべき代替ページを指定します。このセクションにおける各エントリーには 2 つの URI を列挙します。具体的には、最初はリソースであり、2 番目は代替リソースです。両方の URL は相対で、マニフェストファイルと同一生成元経由でなければなりません。ワイルドカードが利用できます。
CACHE, NETWORK, and FALLBACK セクションはキャッシュマニフェストファイル内でどんな順番でも列挙でき、各セクションは単一のマニフェストにおいて、複数回定義することができます。
例 2: より完全なキャッシュマニフェストファイル
以下は、 www.example.com にある想像上の Web サイト向けのより完全なキャッシュマニフェストファイルです:
CACHE MANIFEST # v1 2011-08-14 # これは別のコメントです index.html cache.html style.css image1.png # 利用可能ならネットワーク経由で利用する NETWORK: network.html # 代替コンテンツ FALLBACK: / fallback.html
この例は NETWORK と セクションを用いて、 FALLBACKnetwork.html ページは常にネットワーク経由で取得し、fallback.html ページは代替リソース (例えば、サーバへの接続ができない場合) として提供されるべきであることを指定しています。
キャッシュマニフェストファイルの構造
キャッシュマニフェストファイルは text/cache-manifest という MIME タイプで提供される必要があります。この MIME タイプを使って提供されるすべてのリソースは、このセクションで定義されている、アプリケーションキャッシュマニフェストのための構文に従う必要があります。
キャッシュマニフェストは UTF-8 形式のテキストファイルで、任意で BOM 文字を含むこともできます。改行文字は、ラインフィード (U+000A)、キャリッジリターン (U+000D)、あるいはその両方で表すことができます。
キャッシュマニフェストの 1 行目は、ゼロあるいはそれ以上のスペースまたはタブ文字に続けて「CACHE MANIFEST」という文字列で構成される必要があります。2 つの単語の間にはひとつのスペース (U+0020) が含まれます。1 行目に書かれたそれ以外の文字列は無視されます。
キャッシュマニフェストの残りの部分は、ゼロあるいはそれ以上の、以下の行によって構成されます:
- 空白行
- ゼロあるいはそれ以上のスペースまたはタブ文字から成る空白行を用いることができます。
- コメント
- コメントは、ひとつの「#」文字に続くゼロあるいはそれ以上のスペースまたはタブ文字と、それに続くゼロあるいはそれ以上のコメント文字列によって構成されます。コメントは単独の行のみで用いることができ、他の行に付加することはできません。これは、フラグメント識別子を指定できないことを意味します。
- セクションヘッダ
- セクションヘッダは、キャッシュマニフェストのどのセクションが操作されるかを示すものです。3 種類のセクションヘッダを用いることができます:
セクションヘッダ 説明 CACHE:キャッシュマニフェストの明示的セクションに切り替えます。これは既定のセクションです。 NETWORK:キャッシュマニフェストのオンラインホワイトリストセクションに切り替えます。 FALLBACK:キャッシュマニフェストの代替セクションに切り替えます。
- セクションヘッダ行には空白を含めることも可能ですが、セクション名には必ずコロンを含める必要があります。
- セクションデータ
- データ行の形式はセクションとごとに異なります。明示的 (
CACHE:) セクションでは、各行は、キャッシュのリソースを参照する妥当な URI または IRI です（このセクションではワイルドカード文字は一切利用できません）。各行の URI または IRI の前後には空白を含めることも可能です。 Fallback セクションでは、各行は、リソースと、それに続いて、サーバとの接続ができないときに提供される代替リソースを参照する妥当な URI または IRI です。ネットワークセクションでは、各行は、ネットワークから取得できるリソースを参照する 妥当な URI または IRI です（このセクションではワイルドカード文字である * が利用できます）。注意: 相対 URI は、マニフェストを参照するドキュメントの URI ではなく、キャッシュマニフェストの URI からの相対となります。
キャッシュマニフェストは、それぞれのセクションを任意で行き来することができます (つまり、各セクションヘッダを複数回用いることができます)。また、セクションを空白にしておくことも許容されています。
Resources in an application cache
An application cache always includes at least one resource, identified by URI. All resources fit into one of the following categories:
- Master entries
- These are resources added to the cache because a browsing context visited by the user included a document that indicated that it was in this cache using its
manifestattribute. - Explicit entries
- These are resources explicitly listed in the application's cache manifest file.
- Network entries
- These are resources listed in the application's cache manifest files as network entries.
- Fallback entries
- These are resources listed in the application's cache manifest files as fallback entries.
Resource categories are described in greater detail below.
Master entries
Master entries are any HTML files that include a manifest attribute in their <html> element. For example, let's say we have the HTML file https://www.example.com/entry.html, which looks like this:
<html manifest="example.appcache"> <h1>Application Cache Example</h1> </html>
If entry.html is not listed in the example.appcache cache manifest file, visiting the entry.html page causes entry.html to be added to the application cache as a master entry.
Explicit entries
Explicit entries are resources that are explicitly listed in the CACHE section of a cache manifest file.
Network entries
The NETWORK section of a cache manifest file specifies resources for which a web application requires online access. Network entries in an application cache are essentially an "online whitelist"—URIs specified in the NETWORK section are loaded from the server instead of the cache. This lets the browser's security model protect the user from potential security breaches by limiting access to approved resources.
As an example, you can use network entries to load and execute scripts and other code from the server instead of the cache:
CACHE MANIFEST NETWORK: /api
The cache manifest section listed above ensures that requests to load resources contained in the https://www.example.com/api/ subtree always go to the network without attempting to access the cache.
manifest attribute set in the html element) from the manifest file would not have the same result, because master entries will be added—and subsequently served from—the application cache. Fallback entries
Fallback entries are used when an attempt to load a resource fails. For example, let's say the cache manifest file https://www.example.com/example.appcache includes the following content:
CACHE MANIFEST FALLBACK: example/bar/ example.html
Any request to https://www.example.com/example/bar/ or any of its subdirectories and their content cause the browser to issue a network request to attempt to load the requested resource. If the attempt fails, due to either a network failure or a server error of some kind, the browser loads the file example.html instead.
Cache states
Each application cache has a state, which indicates the current condition of the cache. Caches that share the same manifest URI share the same cache state, which can be one of the following:
UNCACHED- A special value that indicates that an application cache object is not fully initialized.
IDLE- The application cache is not currently in the process of being updated.
CHECKING- The manifest is being fetched and checked for updates.
DOWNLOADING- Resources are being downloaded to be added to the cache, due to a changed resource manifest.
UPDATEREADY- There is a new version of the application cache available. There is a corresponding
updatereadyevent, which is fired instead of thecachedevent when a new update has been downloaded but not yet activated using theswapCache()method. OBSOLETE- The application cache group is now obsolete.
Testing for updates to the cache manifest
You can programmatically test to see if an application has an updated cache manifest file, using JavaScript. Since a cache manifest file may have been updated before a script attaches event listeners to test for updates, scripts should always test window.applicationCache.status.
function onUpdateReady() {
alert('found new version!');
}
window.applicationCache.addEventListener('updateready', onUpdateReady);
if(window.applicationCache.status === window.applicationCache.UPDATEREADY) {
onUpdateReady();
}
To manually start testing for a new manifest file, you can use window.applicationCache.update().
Gotchas
- Never access cached files by using traditional GET parameters (like
other-cached-page.html?parameterName=value). This will make the browser bypass the cache and attempt to get it from network. To link to cached resources that have parameters parsed in JavaScript use parameters in the hash part of the link, such asother-cached-page.html#whatever?parameterName=value. - When applications are cached, simply updating the resources (files) that are used in a web page is not enough to update the files that have been cached. You must update the cache manifest file itself before the browser retrieves and uses the updated files. You can do this programmatically using
window.applicationCache.swapCache(), though resources that have already been loaded will not be affected. To make sure that resources are loaded from a new version of the application cache, refreshing the page is ideal. - It's a good idea to set expires headers on your web server for
*.appcachefiles to expire immediately. This avoids the risk of caching manifest files. For example, in Apache you can specify such a configuration as follows:
ExpiresByType text/cache-manifest "access plus 0 seconds"
Browser Compatibility
| Feature | Chrome | Firefox (Gecko) | Internet Explorer | Opera | Safari |
|---|---|---|---|---|---|
| Basic support | 4.0 | 3.5 | 10.0 | 10.6 | 4.0 |
| Feature | Android | Firefox Mobile (Gecko) | IE Mobile | Opera Mobile | Safari Mobile |
|---|---|---|---|---|---|
| Basic support | 2.1 | ? | 未サポート | 11.0 | 3.2 |
Note: Versions of Firefox prior to 3.5 ignore the NETWORK and FALLBACK sections of the cache manifest file.
See also
- HTML5Rocks - A Beginner's Guide to Using the Application Cache
- appcachefacts.info - detailed information on AppCache idiosyncrasies
- offline web applications at hacks.mozilla.org - showcases an offline app demo and explains how it works.
- HTML 5 working draft: Offline web applications
- HTML5 Cache Manifest: An Off-label Usage
nsIApplicationCachensIApplicationCacheNamespacensIApplicationCacheContainernsIApplicationCacheChannelnsIApplicationCacheServicensIDOMOfflineResourceList- Get ready for Firefox 3.0 - A Web developer's guide to the many new features in this popular browser, especially the offline application features (IBM developerWorks)