window.localStorage vs chrome.storage.local [英] window.localStorage vs chrome.storage.local

问题描述

我正在开发一个Chrome扩展程序，我需要存储一些数据，然后在某些时候获取它。我对 available storage s进行了调查，并发现了以下几个问题： window.localStorage 和 chrome.storage.local 。

所以我的问题是，哪一个是在Chrome扩展中使用的正确选择：

窗口。 localStorage 或 chrome.storage.local ？

$ b $我使用浏览器操作来加载本地 HTML 中的 IFRAME 。所以我没有使用 popup.js 。

解决方案

完全取决于您的Chrome扩展程序将在做什么。 window.localStorage是HTML5存储。除非您在后台页面中运行它，否则它只能让您获取和设置数据到特定域的存储中。注入DOM的代码也是如此，因为它会在网页上使用localStorage。

换句话说，您将无法共享数据除非您在后台页面中使用localStorage，因为它的域名是chrome：// URI，所以它独立于网页运行。

$ b另一方面，$ b

chrome.storage.local专为Chrome扩展程序和Chrome应用程序将数据存储在更集中的位置而设计。由于这是普通网页无法访问的，每个扩展都有自己的存储空间。一种可能性是您的后台页面处理数据的设置和获取，而您的内容脚本则处理修改和与网页交互。然而，这些API在内容脚本中的工作，以及我编写的两个扩展都使用从内容脚本中调用的chrome.storage.local。

>

作为一个例子，我构建了一个Stack应用程序，用于保存Stack Exchange中的收件箱项目，直到您实际阅读它们，称为 StackInbox 。由于Stack Exchange站点跨越数百个域，因此我选择了chrome.storage.local，因为我可以保存用户的accountId并在所有站点之间重复使用，确保收件箱数据同步，同时直接在内容脚本中使用它。

作为一个简单的测试，将一些数据放在一个域的localStorage中，放在一个内容脚本中，然后尝试从另一个域中取出数据，您会看到数据将不会在那里。使用chrome.storage.local，这不是问题。

最后，由于用户选择安装Chrome扩展程序和Chrome应用程序，因此它们通常会被列入白名单可以做比正常网站更多的事情。例如，通过在清单中指定unlimitedStorage权限，您可以将数据存储在远超过HTML5 localStorage的5MB限制的位置。

有关更多信息，请参阅谷歌关于Chrome存储的文档。

I'm developing a Chrome extension and I need to store some data and then get it in some point. I did investigation on available storages and came across to the following ones: window.localStorage and chrome.storage.local.

So my question is, which one is the right choice to use in Chrome extensions:
window.localStorage or chrome.storage.local?

P.S. I'm using browser action to load a local HTML in IFRAME. So I'm not using popup.js.

解决方案

It depends entirely on what your Chrome Extension will be doing. window.localStorage is HTML5 storage. Unless you're running it in the background page, it can only allow you to get and set data into storage for a specific domain. This is also true for code injected into the DOM, since it would use the localStorage on the web page.

In other words, you won't be able to share data across different web pages unless you use localStorage in the background page, which operates independently of web pages, since it has a chrome:// URI as its domain.

chrome.storage.local, on the other hand, is designed for Chrome Extensions and Chrome Apps to store data in a more central location. Since this isn't accessible to normal web pages, each Extension gets its own storage. One possibility is for your background page to handle dealing with the setting and getting of the data, while your content scripts deal with modifying and interacting with the web page.

However, these API's work in content scripts as well, and both of the extensions I've written use chrome.storage.local called from the content scripts.

As an example, I built a Stack App that preserves inbox items in Stack Exchange until you've actually read them, called StackInbox. Since Stack Exchange sites span across hundreds of domains, I chose chrome.storage.local because I could save the user's accountId and reuse it across all the sites, ensuring that the inbox data is synchronized, while also using this directly in the content script.

As a simple test, put some data in localStorage on one domain, in a content script, and try to pull it from another, and you'll see that the data won't be there. With chrome.storage.local, this isn't a problem.

Lastly, Chrome Extensions and Chrome Apps are whitelisted, since the user chose to install it, so they typically can do more things than a normal website. For instance, by specifying the "unlimitedStorage" permission in your manifest, you can store data well beyond the 5MB limit placed upon HTML5 localStorage.

For more information, see Google's documentation on Chrome Storage.

这篇关于window.localStorage vs chrome.storage.local的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！