Movatterモバイル変換


[0]ホーム

URL:


  1. Web
  2. Web-APIs
  3. Web Storage API

Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten.Erfahre mehr über dieses Experiment.

View in EnglishAlways switch to English

Web Storage API

DieWeb Storage API bietet Mechanismen, mit denen Browser Schlüssel/Wert-Paare speichern können, auf eine viel intuitivere Weise als mitCookies.

Konzepte und Nutzung

Die beiden Mechanismen innerhalb von Web Storage sind wie folgt:

  • sessionStorage ist nach Browser-Tabs und nachOrigin partitioniert. Das Hauptdokument und alle eingebettetenBrowsing-Kontexte (iframes) werden nach ihrer Origin gruppiert, und jede Origin hat Zugriff auf ihren eigenen separaten Speicherbereich. Das Schließen des Browser-Tabs löscht alle mit diesem Tab verknüpftensessionStorage-Daten.
  • localStorage ist nur nachOrigin partitioniert. Alle Dokumente mit derselben Origin haben Zugriff auf denselbenlocalStorage-Bereich, der auch dann bestehen bleibt, wenn der Browser geschlossen und erneut geöffnet wird.

Diese Mechanismen sind über die EigenschaftenWindow.sessionStorage undWindow.localStorage verfügbar. Der Zugriff auf eine dieser Eigenschaften gibt eine Instanz einesStorage-Objekts zurück, über das Daten gesetzt, abgerufen und entfernt werden können. Für jede Origin wird ein anderes Speicherobjekt fürsessionStorage undlocalStorage verwendet — sie funktionieren und werden separat gesteuert.

Um mehr über die verfügbare Speichermenge mithilfe der APIs zu erfahren und was passiert, wenn Speicherlimits überschritten werden, sieheSpeicherquoten und Ausweisungskriterien.

SowohlsessionStorage als auchlocalStorage in Web Storage sind von Natur aus synchron. Das bedeutet, dass beim Setzen, Abrufen oder Entfernen von Daten aus diesen Speichermethoden die Operationen synchron ausgeführt werden, was die Ausführung anderer JavaScript-Codes blockiert, bis die Operation abgeschlossen ist. Dieses synchrone Verhalten kann potenziell die Leistung der Webanwendung beeinträchtigen, insbesondere wenn eine große Menge an Daten gespeichert oder abgerufen wird.

Entwickler sollten vorsichtig sein, wenn sie Operationen aufsessionStorage oderlocalStorage ausführen, die eine beträchtliche Menge an Daten oder rechnerisch intensive Aufgaben betreffen. Es ist wichtig, den Code zu optimieren und synchrone Operationen zu minimieren, um eine Blockierung der Benutzeroberfläche und Verzögerungen in der Reaktionsfähigkeit der Anwendung zu vermeiden.

Asynchrone Alternativen wieIndexedDB können besser geeignet sein für Szenarien, bei denen die Leistung eine Rolle spielt oder wenn mit größeren Datenmengen gearbeitet wird. Diese Alternativen ermöglichen nicht-blockierende Operationen, wodurch reibungslosere Benutzererfahrungen und eine bessere Leistung in Webanwendungen erreicht werden.

Hinweis:Der Zugriff auf Web Storage von Drittanbieter-IFrames wird verweigert, wenn der BenutzerDrittanbieter-Cookies deaktiviert hat.

Bestimmen des Speicherzugriffs durch Drittanbieter

Jede Origin hat ihren eigenen Speicher — dies gilt sowohl für Web Storage als auch fürShared Storage. Der Zugriff von Drittanbieter- (d.h. eingebettetem) Code auf Shared Storage hängt von seinemBrowsing-Kontext ab. Der Kontext, in dem ein Drittanbieter-Code einer anderen Origin läuft, bestimmt den Speicherzugriff des Drittanbieter-Codes.

Ein Box-Diagramm, das einen Top-Level-Browsing-Kontext namens publisher.com zeigt, mit Drittanbieter-Inhalten, die darin eingebettet sind

Drittanbieter-Code kann einer anderen Seite hinzugefügt werden, indem er mit einem<script>-Element eingefügt wird oder indem die Quelle eines<iframe> auf eine Seite gesetzt wird, die Drittanbieter-Code enthält. Die Methode, die zur Integration von Drittanbieter-Code verwendet wird, bestimmt den Browsing-Kontext des Codes.

  • Wenn Ihr Drittanbieter-Code mit einem<script>-Element zu einer anderen Seite hinzugefügt wird, wird Ihr Code im Browsing-Kontext des Embedders ausgeführt. Daher wird beim Aufruf vonStorage.setItem() oderSharedStorage.set() das Schlüssel/Wert-Paar in den Speicher des Embedders geschrieben. Aus Sicht des Browsers gibt es keinen Unterschied zwischen erstem und Drittanbieter-Code, wenn ein<script>-Tag verwendet wird.
  • Wenn Ihr Drittanbieter-Code innerhalb eines<iframe> zu einer anderen Seite hinzugefügt wird, wird der Code innerhalb des<iframe> mit der Origin des Browsing-Kontexts des<iframe> ausgeführt. Wenn der Code innerhalb des<iframe>Storage.setItem() aufruft, werden Daten in den lokalen oder Session-Speicher der Origin des<iframe> geschrieben. Wenn der<iframe>-CodeSharedStorage.set() aufruft, werden die Daten in den Shared Storage der Origin des<iframe> geschrieben.

Web Storage-Schnittstellen

Storage

Ermöglicht es Ihnen, Daten für eine bestimmte Domain und einen bestimmten Speicherart (Session oder lokal) zu setzen, abzurufen und zu entfernen.

Window

Die Web Storage API erweitert dasWindow-Objekt um zwei neue Eigenschaften —Window.sessionStorage undWindow.localStorage — die Zugriff auf die Session und lokalenStorage-Objekte der aktuellen Domain bieten, sowie einenstorage-Ereignis-Handler, der ausgelöst wird, wenn sich ein Speicherbereich ändert (z. B. wenn ein neuer Artikel gespeichert wird).

StorageEvent

Dasstorage-Ereignis wird auf einem Dokument-Window-Objekt ausgelöst, wenn sich ein Speicherbereich ändert.

Beispiele

Um einige typische Verwendungen von Web Storage zu veranschaulichen, haben wir ein Beispiel erstellt, das fantasievollWeb Storage Demo genannt wird. DieLanding Page bietet Steuerelemente, mit denen Sie die Farbe, Schriftart und das dekorative Bild anpassen können. Wenn Sie verschiedene Optionen wählen, wird die Seite sofort aktualisiert; zusätzlich werden Ihre Auswahlmöglichkeiten inlocalStorage gespeichert, sodass sie bei erneutem Laden der Seite nach Verlassen wiedererkannt werden.

Zudem haben wir eineEreignisausgabeseite bereitgestellt. Wenn Sie diese Seite in einem anderen Tab laden und dann Ihre Auswahl auf der Landing Page ändern, sehen Sie die aktualisierten Speicherinformationen alsStorageEvent ausgelöst wird.

Spezifikationen

Specification
HTML
# dom-localstorage-dev
HTML
# dom-sessionstorage-dev

Browser-Kompatibilität

api.Window.localStorage

api.Window.sessionStorage

Privates Surfen / Inkognito-Modi

Private Fenster, Inkognito-Modus und ähnlich benannte Datenschutzoptionen speichern keine Daten wie Verlauf und Cookies. Im privaten Modus wirdlocalStorage wiesessionStorage behandelt. Die Speicher-APIs sind immer noch verfügbar und voll funktionsfähig, aber alle im privaten Fenster gespeicherten Daten werden gelöscht, wenn der Browser oder der Browsertab geschlossen wird.

Siehe auch

Help improve MDN

Learn how to contribute Diese Seite wurde automatisch aus dem Englischen übersetzt.

[8]ページ先頭

©2009-2026 Movatter.jp