HTML5 离线存储。文件存储?目录和文件系统 API

发布于 2024-09-28 00:59:49 字数 1556 浏览 0 评论 0原文

对于离线存储数据,WebApp 可以使用:

但显然没有文件存储。当然,有一个基于清单的缓存,但它只是一个缓存,不应该用作用户数据存储。

这是否意味着 WebApp 的用户被迫使用某种云文件存储?

有什么方法可以将大文件保存在用户本地计算机上吗?或者也许有某种方法可以选择可以用来存储用户数据的本地文件夹 Web 应用程序?

编辑。安全。 HTML5 已经能够将大部分数据写入用户的本地计算机。如果浏览器提供另一种基于文件的抽象来存储数据,我不会看到任何安全问题。它可以是某种虚拟机、虚拟文件系统等等。

嗯,我认为,可以编写 JS 文件系统并将其存储为 SQL 中的 blob...

类似 问题

更新: 嗯...最近我发现了这个这个。也许这就是我正在寻找的……是的,就是这样!请参阅下面的答案。

For storing data offline WebApp can use:

But apparently there is no File Storage. Of course, there is a manifest-based caching, but it's just a cache and is not supposed to be used as a user data storage.

Does it mean that the user of WebApp is forced to use some sort of a cloud file storage?

Is there any way to save large files on user's local machine? Or maybe some way to select a local folder web application can use to store user data?

Edit. Security. HTML5 already has the ability to write big portions of data to user's local machine. I don't see any security issues if a browser will provide another, file-based abstraction to store data. It can be some virtual machine, virtual filesystem, whatever.

Hm, I think, it is possible to write JS filesystem and store it as a blob in SQL...

Similar questions.

Update:
Hm... recently I've found this and this. Maybe it is what I'm looking for... Yes, it is! See the answer below.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

我乃一代侩神 2024-10-05 00:59:49

终于,我找到了!答案如下:

我将拥有具有读/写访问权限的 DOMFileSystem 写道:

Google 的 Eric Uhrhane 曾
正在制定工作草案
文件 API:目录和系统规范,它定义了一组
用于创建沙盒文件系统的 API
Web 应用程序可以在其中读取和写入
数据到。

哇!我太激动了!

At last, I've found it! Here's the answer:

I’ll have the DOMFileSystem with a side of read/write access please wrote:

Eric Uhrhane of Google has been
working on the working draft of the
File API: Directories and System specification which defines a set of
APIs to create a sandboxed filesystem
where a web app can read and write
data to.

Wow! I'm so excited!

煮茶煮酒煮时光 2024-10-05 00:59:49

为什么不在用户编辑文档时使用 localStorage 以及在想要将文档保存到磁盘时使用 FileWriter API?大多数人习惯于在保存文档时看到弹出的保存对话框。

我能想到的唯一保证无用户访问 FileWriter API 的场景是自动保存功能,但自动保存到 localStorage 也同样好。

Why not use localStorage while the user is editing a document and the FileWriter API when they want to save it to disk? Most people are used to seeing a save dialog pop up when saving a document.

The only scenario I can think of that warrants userless access to the FileWriter API is an autosave feature, but autosaving to localStorage can be just as good.

数理化全能战士 2024-10-05 00:59:49

如果您愿意使用闪存,有一种方法可以将相对较大的文件保存到用户的硬盘上。查看 Downloadify:

http://www.bitrepository.com/downloadify-client -side-file- Generation.html

Downloadify 允许您将数据发送到 SWF 并让该 SWF 在用户计算机上创建文件。我的建议是通过您列出的方法之一(Webstorage、sqlite 数据库等)存储数据。将所有资源(包括 SWF)放入清单文件中,以便将所有内容本地缓存到浏览器中。然后,您可以从数据库或网络存储中提取信息并使用 SWF 创建您需要的文件。

我不确定您是否能够将这些文件读回到您的网络应用程序中。

保存数据的另一个选项是使用具有 数据 URI 方案 的链接标记。但是,我不确定目前所有主要浏览器是否都支持它。

There is a way to save relatively large files to a users hard drive if you are willing to use Flash. Look into Downloadify:

http://www.bitrepository.com/downloadify-client-side-file-generation.html

Downloadify allows you to send data to a SWF and have that SWF create a file on the users machine. My recommendation would be to store the data via one of the methods you listed, Webstorage, sqlite database, etc. Put all your assets, including the SWF in the manifest file so everything is cached locally to the browser. You can then pull information from your db or webstorage and use the SWF to create the files you need.

I'm not sure if you will be able to read these files back into your web application.

Another option to save data is by using link tags with the data URI scheme. However, I'm not sure if it is supported in all the major browsers at the moment.

久而酒知 2024-10-05 00:59:49

出于安全原因,您不能将文件写入用户的本地文件系统,以防它被邪恶的人用于邪恶目的。

这不太可能改变,这是一件好事。

For security reasons you can't write files to a user's local filesystem in case it gets used for nefarious purposes by evil people.

That's not likely to change, and that's a good thing.

假装爱人 2024-10-05 00:59:49

HTML5 FileSystem API 开始登陆 Chrome 8,并且到目前为止已经相当完整(Chrome 11)。

这里有一个很好的教程: http://www.html5rocks.com/tutorials/file/文件系统/

The HTML5 FileSystem API started landing in Chrome 8 and is fairly complete as of now (Chrome 11).

There's a nice tutorial on it here: http://www.html5rocks.com/tutorials/file/filesystem/

老娘不死你永远是小三 2024-10-05 00:59:49

如果您想要一个简单的解决方案,http://fsojs.com 有效地包装了 FileSystem API

http://fsojs.com wraps the FileSystem API effectively, if you want an easy solution

止于盛夏 2024-10-05 00:59:49

正如其他人在这里提到的, FileWriter 和 < a href="https://www.w3.org/TR/2012/WD-file-system-api-20120417/" rel="nofollow">FileSystem API 可用于将文件存储在客户端的从浏览器选项卡/窗口的上下文中的机器。

但是,您应该注意与这些 API 相关的一些事项:

  • 这些 API 的实现目前仅存在于基于 Chromium 的浏览器(Chrome 和 Opera)中
  • 这两个 API 均已于 4 月 24 日从 W3C 标准轨道中删除、 2014 年以及截至目前都是专有的
  • 有可能从实现浏览器中删除(现在专有的)API
  • 将来 用于存储通过 API 创建的文件 使用
  • 虚拟文件系统(一种目录结构,不一定以与从浏览器内访问时相同的形式存在于磁盘上)来表示文件使用 API

IsolatedStorage 创建,到目前为止还没有提到,还允许从选项卡/窗口上下文进行文件 I/O,但它仅通过 Silverlight 提供,并且需要使用 托管代码 进行访问。与文件系统一样,它也存在于沙箱中并使用虚拟文件系统。

鉴于基于 Chromium 的浏览器和 Silverlight 的市场渗透率很高(有趣的是,此类浏览器已经放弃了对其的支持),您可能会发现使用上述第一种方法(在客户端计算机上可用)的解决方案令人满意。

BakedGoods,一个 Javascript 库,它建立了统一的接口,可用于在所有环境中进行常见的存储操作本机(包括 FileSystem)和一些非本机(包括isolatedStorage)存储设施就是此类解决方案的一个示例:

//Write file to first of either FileSystem or IsolatedStorage
bakedGoods.set({
    data: [{key: "testFile", value: "Hello world!", dataFormat: "text/plain"}],
    storageTypes: ["fileSystem", "silverlight"],
    options: {fileSystem:{storageType: Window.PERSISTENT}},
    complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

只是为了完全透明,BakedGoods 就由这个人维护:)。

As mentioned by others here, the FileWriter and FileSystem APIs can be used to store files on a client's machine from the context of a browser tab/window.

However, there are several things pertaining to these APIs which you should be aware of:

  • Implementations of the APIs currently exist only in Chromium-based browsers (Chrome & Opera)
  • Both of the APIs were taken off of the W3C standards track on April 24, 2014, and as of now are proprietary
  • Removal of the (now proprietary) APIs from implementing browsers in the future is a possibility
  • A sandbox (a location on disk outside of which files can produce no effect) is used to store the files created with the APIs
  • A virtual file system (a directory structure which does not necessarily exist on disk in the same form that it does when accessed from within the browser) is used represent the files created with the APIs

IsolatedStorage, which hasn't been mentioned as of yet, also allows for file i/o from a tab/window context, but it is made available through solely through Silverlight and requires the use of managed code to access. It, like FileSystem, also exists in a sandbox and makes use of a virtual file system.

Given the high market penetration of both Chromium-based browsers and Silverlight (support for which, interestingly enough has been dropped by such browsers), you may find a solution which uses the first of the above approaches available on a client machine satisfactory.

BakedGoods, a Javascript library that establishes a uniform interface that can be used to conduct common storage operations in all native (including FileSystem), and some non-native (including IsolatedStorage) storage facilities, is an example of such a solution:

//Write file to first of either FileSystem or IsolatedStorage
bakedGoods.set({
    data: [{key: "testFile", value: "Hello world!", dataFormat: "text/plain"}],
    storageTypes: ["fileSystem", "silverlight"],
    options: {fileSystem:{storageType: Window.PERSISTENT}},
    complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

Just for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文