From 87a91f47dfef661302e655dcbbdd76ed937a74dd Mon Sep 17 00:00:00 2001 From: Masahiro FUJIMOTO Date: Wed, 18 Aug 2021 12:53:33 +0900 Subject: Web/API/IndexedDB_API を更新 (#2003) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 2021/08/09 時点の英語版に同期 - 「期限の確認」については新規翻訳 --- .../index.html | 70 ++--- .../checking_when_a_deadline_is_due/index.html | 213 +++++++++++++++ files/ja/web/api/indexeddb_api/index.html | 139 +++++----- .../api/indexeddb_api/using_indexeddb/index.html | 304 +++++++++++---------- 4 files changed, 471 insertions(+), 255 deletions(-) create mode 100644 files/ja/web/api/indexeddb_api/checking_when_a_deadline_is_due/index.html (limited to 'files/ja/web/api') diff --git a/files/ja/web/api/indexeddb_api/browser_storage_limits_and_eviction_criteria/index.html b/files/ja/web/api/indexeddb_api/browser_storage_limits_and_eviction_criteria/index.html index 47c47bad45..0db54a15b6 100644 --- a/files/ja/web/api/indexeddb_api/browser_storage_limits_and_eviction_criteria/index.html +++ b/files/ja/web/api/indexeddb_api/browser_storage_limits_and_eviction_criteria/index.html @@ -16,12 +16,12 @@ translation_of: Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criter

クライアント側 (すなわちローカルディスク) に何らかのデータを保存するウェブ技術は何種類かがあります。ブラウザーがどれだけの容量をウェブデータストレージに割り当てるかや、容量の上限に達したときにどのデータを削除するかのプロセスは単純ではなく、またブラウザーにより異なります。この記事では、必要なローカルストレージの容量を確保するために、いつどのローカルコンテンツを破棄するのかをどうやって特定するのかを説明します。

-

メモ: 以下の情報はほとんどの最新ブラウザーでおおむね正確ですが、既知の詳細情報も記載しています。 Opera および Chrome は、すべての場合において同じ動作になるでしょう。 Opera Mini (Presto ベースで、サーバー側でレンダリングする) は、クライアントにデータを保存しません。

+

メモ: 以下の情報はほとんどの最新ブラウザーではおおむね正確ですが、ブラウザー固有の注意事項も知られています。 Opera と Chrome は、すべての場合において同じ動作になるでしょう。 Opera Mini (Presto ベースで、サーバー側でレンダリングする) は、クライアントにデータを保存しません。

-

ブラウザーのデータストレージを使用する技術は何か?

+

ブラウザーのデータストレージを使用する技術は何か?

-

Firefox では以下の技術が、必要なデータを保存するためにブラウザーのデータストレージを使用します。ここではそれらの技術を "クォータクライアント" と呼びます。

+

Firefox では以下の技術が、必要なデータを保存するためにブラウザーのデータストレージを使用します。ここではこれらの技術を「クォータクライアント」と呼びます。

-

メモ: Firefox では、 Web Storage もすぐに同じストレージ管理ツールとして使えるようになり、それはこの文書で記述します。

+

メモ: Firefox では、ウェブストレージもまもなく同じストレージ管理ツールを使い始めます。それはこの文書で記述します。

メモ: プライベートブラウジングモードは、大半のデータストレージに対応していません。ローカルストレージのデータと Cookie は保存されますが、短命です。 — 最後のプライベートブラウジングウィンドウを閉じた時にデータは消去されます。

-

生成元の "最終アクセス日時" は、これらのいずれかによってアクティブ化/非アクティブ化される origin eviction によって、すべてのクォータクライアントでデータ削除が行われたときに更新されます。

+

オリジンの「最終アクセス日時」はこれらのうちの何れかがアクティブ化/非アクティブ化されたときに更新されます。オリジン立ち退き (origin eviction) によって、すべてのクォータクライアントでデータ削除が行われたときに更新されます。

-

Chrome/Opera では、 Quota Management API が AppCache, IndexedDB, WebSQL, File System API のクォータ管理を制御しています。

+

Chrome/Opera では、 Quota Management API が AppCache, IndexedDB, WebSQL, File System API のクォータ管理を制御しています。

-

さまざまな種類のデータストレージ

+

さまざまな種類のデータストレージ

同じブラウザー内で同じ保存方法を使用していても、解釈されるデータストレージの種類はさまざまです。この章では、さまざまなブラウザーで見つけられる多様なストレージについて説明します。

ストレージは 2 種類に分けられます。

Firefox では、永続的なストレージが使用されると、ユーザーにはデータが永続的になることを警告するポップアップが表示され、それが良いかどうかを尋ねます。一時的データストレージは明示的にユーザーにプロンプトを表示しません。

-

既定では、一時的なストレージがほとんどの使用環境 (例えば、標準的な Web アプリ) で使用され、永続的なストレージはインストールされたアプリ (例えば、Firefox OS やデスクトップ版 Firefox にインストールした Firefox アプリ、および Chrome アプリ) で使用されます。

+

ストレージは既定では一時的です。開発者は Storage API で利用できる {{domxref("StorageManager.persist()")}} メソッドを使用して永続的なストレージにすることができます。

-

データの保存先は?

+

データの保存先は?

-

それぞれのストレージタイプが別々のリポジトリに相当しており、ユーザーの Firefox プロファイル内のディレクトリーとは以下のように対応づけられます (ほかのブラウザーでは、若干異なるでしょう):

+

それぞれのストレージ種別は、個別のリポジトリーーを表します。以下は、ユーザーの Firefox プロファイル下のディレクトリにおける実際のマッピングです (他のブラウザーでは若干異なる場合があります)。

-

メモ: Storage API の導入後は、"permanent" フォルダーは廃止されると考えられます。"permanent" フォルダーは IndexedDB の永続的なタイプのデータベースのみ保存します。ボックスモードが "best-effort" や "persistent" であっても、データは <profile>/storage/default 以下に保存されます。

+

メモ: Storage API の導入後は、"permanent" フォルダーは廃止されると考えられます。"permanent" フォルダーは IndexedDB の永続的な種類のデータベースのみ保存します。ボックスモードが "best-effort" や "persistent" であっても、データは <profile>/storage/default 以下に保存されます。

@@ -81,52 +81,52 @@ translation_of: Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criter
-

メモ: ユーザーが <profile>/storage の配下に、独自のディレクトリーやファイルを作成すべきではありません。このようなことを行うと、ストレージの初期化が失敗します。例えば、{{domxref("IDBFactory.open()", "open()")}} でエラーイベントが発生します。

+

メモ: ユーザーが <profile>/storage の配下に、独自のディレクトリーやファイルを作成すべきではありません。このようなことを行うと、ストレージの初期化に失敗します。例えば、{{domxref("IDBFactory.open()", "open()")}} でエラーイベントが発生します。

-

ストレージの制限

+

ストレージの制限

-

ブラウザーのストレージの最大容量は動的であり、ハードディスクドライブのサイズに応じて変わります。グローバルリミットはディスクの空き量量の 50% に決められます。Firefox では、クォータマネージャと飛ばれる内部のブラウザーツールが生成元ごとにどれだけディスク容量を使用しているかを絶えず注視しており、必要に応じてデータを削除します。

+

ブラウザーのストレージの最大容量は動的であり、ハードディスクドライブのサイズに応じて変わります。グローバルリミットはディスクの空き量量の 50% に決められます。Firefox では、クォータマネージャーと飛ばれる内部のブラウザーツールがオリジンごとにどれだけディスク容量を使用しているかを絶えず注視しており、必要に応じてデータを削除します。

-

従ってハードディスクドライブが 500GB であれば、ブラウザーの合計ストレージサイズは 250GB になります。上限に達すると origin eviction と呼ばれる処理を実行して、ストレージの総量が再び上限を下回るまで、生成元全体に相当するデータを削除します。生成元内の一部分を削除するような縮小法はありません。生成元内のひとつのデータベースだけ削除すると、矛盾の問題が発生するおそれがあります。

+

従ってハードディスクドライブの空き容量が 500GB であれば、ブラウザーの合計ストレージサイズは 250GB になります。上限に達するとオリジン立ち退き (origin eviction) と呼ばれる処理を実行して、ストレージの総量が再び上限を下回るまで、オリジン全体に相当するデータを削除します。オリジン内の一部分を削除するような縮小法はありません。オリジン内のデータベースをひとつだけ削除すると、矛盾が発生するおそれがあります。

-

また、グループリミットというもうひとつの制限もあります。これは、グローバルリミットの 20% として定義されます。それぞれの生成元は、グループ (生成元のグループ) の一部です。グループは、eTLD+1 ドメインごとに 1 つ作られます。例えば次の通り:

+

また、グループリミットというもうひとつの制限もあります。これは、グローバルリミットの 20% として定義されます。それぞれのオリジンは、グループ (オリジンのグループ) の一部です。グループは、eTLD+1 ドメインごとに 1 つ作られます。例えば次の通りです。

このグループでは mozilla.org、www.mozilla.org、joe.blogs.mozilla.org が、合わせてグローバルリミットの 20% を上限としてストレージを使用できます。firefox.com は、別に 20% の上限を持ちます。

-

これら 2 種類の制限は、制限に達したときの動作が異なります:

+

これら 2 種類の制限は、制限に達したときの動作が異なります。

-

メモ: グループリミットは、上記で触れた最小のグループリミットにかかわらず、グローバルリミットより大きくすることはできません。グローバルリミットが 8MB といった本当に低メモリな状況では、グループリミットも 8MB となります。

+

メモ: グループリミットは、上記で触れた最小のグループリミットにかかわらず、グローバルリミットより大きくすることはできません。グローバルリミットが 8MB といった本当にメモリーが少ない状況では、グループリミットも 8MB となります。

-

メモ: グループリミットに達したとき、あるいは origin eviction で十分な空き容量を確保できないときは、ブラウザーで QuotaExceededError が発生します。

+

メモ: グループリミットに達したとき、あるいはオリジン立ち退きで十分な空き容量を確保できないときは、ブラウザーで QuotaExceededError が発生します。

メモ: Chrome では、ソフトおよびハードのストレージのクォータの限界が M66 から変更されました。詳しい情報はこちらにあります。

-

LRU ポリシー

+

LRU ポリシー

-

使用可能なディスク領域がすべて埋まったときは、クォータマネージャーが LRU ポリシーに基づいてデータの削除処理を始めます。もっとも過去に使用された生成元のデータが始めに削除され、上限に達しなくなるなるまで削除を繰り返します。

+

使用可能なディスク領域がすべて埋まったときは、クォータマネージャーーが LRU ポリシーに基づいてデータの削除処理を始めます。もっとも過去に使用されたオリジンのデータが始めに削除され、上限に達しなくなるなるまで削除を繰り返します。

-

一時的なストレージを使用して、生成元ごとに "最終アクセス日時" を記録しています。一時的なストレージがグローバルリミットに達する (後に上限をさらに超える) と、現在使用していない (すなわち、データストアを開き続けているタブやアプリがない) 生成元をすべて発見しようとします。これらは、"最終アクセス日時" によって整列されます。 origin eviction を発生させたリクエストを満たすのに十分な領域を確保するまで、もっとも過去に使用された生成元を削除し続けます。

+

一時的なストレージを使用して、オリジンごとに「最終アクセス日時」を記録しています。一時的なストレージがグローバルリミットに達する (後に上限をさらに超える) と、現在使用していない (すなわち、データストアを開き続けているタブやアプリがない) オリジンをすべて発見しようとします。これらは、「最終アクセス日時」によって整列されます。オリジン立ち退きを発生させたリクエストを満たすのに十分な領域を確保するまで、もっとも過去に使用されたオリジンを削除し続けます。

-

関連情報

+

関連情報