当前位置：theitroad>Javascript 为离线 Web 应用程序存储图像数据（客户端存储数据库）

Javascript 为离线 Web 应用程序存储图像数据（客户端存储数据库）

声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow 原文地址: http://stackoverflow.com/questions/14113278/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示：将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间：2020-08-24 15:45:35 　来源:igfitidea点击:

Storing Image Data for offline web application (client-side storage database)

javascripthtmlweb-applicationsindexeddbleaflet

提问by Dr.YSG

I have an offline web application using appcaching. I need to provide it about 10MB - 20MB of data that it will save (client-side) consisting mainly of PNG image files. The operation is as follows:

我有一个使用 appcaching 的离线 Web 应用程序。我需要向它提供大约 10MB - 20MB 的数据，它将保存（客户端）主要由 PNG 图像文件组成。操作如下：

  1. Web application downloads and installs in appcache (uses manifest)
  2. Web app requests from server PNG data files (how? - see alternatives below)
  3. Occasionally web app resyncs with server, and does small partial updates/deletes/additions to PNG database
  4. FYI: Server is a JSON REST server, that can place files in wwwroot for pickup
  1. Web 应用程序在 appcache 中下载和安装（使用清单）
  2. 来自服务器 PNG 数据文件的 Web 应用程序请求（如何？ - 请参阅下面的替代方案）
  3. 有时，Web 应用程序会与服务器重新同步，并对 PNG 数据库进行小部分更新/删除/添加
  4. 仅供参考：服务器是一个 JSON REST 服务器，可以将文件放在 wwwroot 中以供提取

Here is my current analysis of client-based "databases" that handle binary blob storage

这是我目前对处理二进制 blob 存储的基于客户端的“数据库”的分析

SEE UPDATE at Bottom

见底部更新

  • AppCache(via manifest add all the PNG and then update on demand)
    • CON: any change of a PNG database item will mean complete download of all items in manifest (Really bad news!)
  • WebStorage
  • PhoneGap & SQLLite
    • CON: Sponsor will reject it as a native app requiring certification
  • ZIP file
    • Server creates a zip file, places it in wwwroot, and notifies client
    • user has to manually unzip (At least that is how I see it) and save to client file system
    • Web app uses FileSystem API to reference files
    • CON: ZIP might be too large (zip64?), long time to create
    • CON: Not sure if FileSystem API can always read out of the sandbox (I think so)
  • USB or SD card(back to the stone age....)
    • The user will be local to the server before going offline
    • So we could have him insert a SD card, let the server fill it with PNG files
    • Then the user will plug it into the laptop, tablet
    • Web app will use FileSystem API to read the files
    • CON: Not sure if FileSystem API can always read out of the sandbox (I think so)
  • WebSQL
    • CON: w3c has abandoned it (pretty bad)
    • I might consider a Javascript wrapper that uses IndexedDB and WebSQL as a fall-back
  • FileSystem API
  • IndexedDB
  • LawnChairJavaScript wrapper http://brian.io/lawnchair/
    • PRO: very clean wrapper for IndexedDB, WebSQL or whatever database you have (think polyfill)
    • CON: cannot store binary blobs, only data:uri (base64 encoding) (probably fatal flaw due to cost of de-encoding)
  • IndexedDB JQUERYpolyFill https://github.com/axemclion/jquery-indexeddb
    • Parashuram has writtent a nice JQUERY wrapper for the raw IndexedDB interface
    • PRO: greatly simplifies using IndexedDB, I was hoping to add a shim/polyfill for Chrome FileSystemAPI
    • CON: It should handle blobs, but I was unable to get it to work
  • idb.filesystem.jshttp://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
    • Eric Bidelman @ Google has written a well tested PolyFill the FileSystem API that uses Indexed DB as a fall back
    • PRO: FileSystem API is well suited for storing blobs
    • PRO: works great on FireFox and Chrome
      • PRO: great for synchronizing with cloud based CouchDB
    • CON: no clear why, but it is not working on IE10
  • PouchDBJavaScript Library http://pouchdb.com/
    • great for syncing a CouchDB with a local DB (uses either WebSQL or IndexedDB (not my problem though)
    • CON: NO CONS, PouchDB now supports binary blobs for all recent browsers (IE, Chrome, Firefox, Chrome on mobile, etc.) as well as many older browsers. That was not the case when I first did this post.
  • AppCache（通过清单添加所有PNG，然后按需更新）
    • 缺点：PNG 数据库项目的任何更改都意味着完整下载清单中的所有项目（真是个坏消息！）
  • 网络存储
  • PhoneGap 和 SQLLite
    • CON：赞助商将拒绝它作为需要认证的本机应用程序
  • 压缩文件
    • 服务器创建一个zip文件，放在wwwroot，并通知客户端
    • 用户必须手动解压缩（至少我是这么看的）并保存到客户端文件系统
    • Web 应用程序使用 FileSystem API 来引用文件
    • 缺点：ZIP 可能太大（zip64？），创建时间很长
    • 缺点：不确定 FileSystem API 是否总是可以从沙箱中读出（我认为是）
  • USB 或 SD 卡（回到石器时代......）
    • 用户在脱机之前将位于服务器本地
    • 所以我们可以让他插入一张 SD 卡，让服务器用 PNG 文件填充它
    • 然后用户将其插入笔记本电脑、平板电脑
    • Web 应用程序将使用 FileSystem API 来读取文件
    • 缺点：不确定 FileSystem API 是否总是可以从沙箱中读出（我认为是）
  • 网络SQL
    • CON：w3c 已经放弃了（非常糟糕）
    • 我可能会考虑使用 IndexedDB 和 WebSQL 作为后备的 Javascript 包装器
  • 文件系统 API
  • 索引数据库
    • 对 IE10、FireFox 的良好支持（保存、读取 blob）
    • 与文件系统（删除、更新）相比，速度快且管理更容易
    • PRO：查看速度测试：http: //jsperf.com/indexeddb-vs-localstorage/15
    • 请参阅有关在 IndexedDB 中存储和显示图像的文章：https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
    • 缺点：我确认 Chrome 尚不支持 blob 写入（当前错误，但不清楚何时修复）
    • 更新：Chrome 开发人员确认他们正在为桌面和安卓系统进行这项工作！还没有时间表。
  • LawnChairJavaScript 包装器http://brian.io/lawnchair/
    • PRO：非常干净的 IndexedDB、WebSQL 或您拥有的任何数据库的包装器（想想 polyfill）
    • CON：不能存储二进制 blob，只能存储 data:uri（base64 编码）（由于解编码成本，可能是致命缺陷）
  • IndexedDB JQUERYpolyFill https://github.com/axemclion/jquery-indexeddb
    • Parashuram 为原始 IndexedDB 接口编写了一个很好的 JQUERY 包装器
    • PRO：大大简化了 IndexedDB 的使用，我希望为 Chrome FileSystemAPI 添加一个 shim/polyfill
    • 缺点：它应该处理斑点，但我无法让它工作
  • idb.filesystem.js http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api
    • Eric Bidelman @ Google 编写了一个经过良好测试的 PolyFill FileSystem API，它使用索引数据库作为后备
    • PRO：FileSystem API 非常适合存储 blob
    • PRO：在 FireFox 和 Chrome 上运行良好
      • PRO：非常适合与基于云的 CouchDB 同步
    • 缺点：不清楚为什么，但它不适用于 IE10
  • PouchDBJavaScript 库http://pouchdb.com/
    • 非常适合将 CouchDB 与本地数据库同步（使用 WebSQL 或 IndexedDB（虽然不是我的问题）
    • 缺点：没有缺点，PouchDB 现在支持所有最新浏览器（IE、Chrome、Firefox、移动版 Chrome 等）以及许多旧浏览器的二进制 blob。当我第一次写这篇文章时，情况并非如此。

NOTE: to see a data:uri encoding of PNG I created an example at: http://jsbin.com/ivefak/1/edit

注意：要查看 PNG 的 data:uri 编码，我在以下位置创建了一个示例：http: //jsbin.com/ivefak/1/edit

Desired/Usefull/Uneeded Features

所需/有用/不需要的功能

  • No native (EXE, PhoneGap, ObjectiveC, etc) app on client (pure web application)
  • Only needs to run on latest Chrome, FireFox, IE10 for laptops
  • Strongly want same solution for Android Tablet (IOS would be nice too) but only need one browser to work (FF, Chrome, etc.)
  • Fast initial DB population
  • REQUIREMENT: Very fast retrieval of images by web application from storage (DB, file)
  • Not meant for consumers. We can restrict browsers, and ask user to do special setup & tasks, but let's minimize that
  • 客户端上没有原生（EXE、PhoneGap、ObjectiveC 等）应用程序（纯 Web 应用程序）
  • 只需要在最新的 Chrome、FireFox、IE10 笔记本电脑上运行
  • 强烈希望为 Android 平板电脑提供相同的解决方案（IOS 也不错）但只需要一个浏览器即可工作（FF、Chrome 等）
  • 快速初始数据库填充
  • 要求：通过 Web 应用程序从存储（数据库、文件）中非常快速地检索图像
  • 不适合消费者。我们可以限制浏览器，并要求用户做特殊的设置和任务，但让我们尽量减少

IndexedDB Implementations

IndexedDB 实现

  • There is an excellent article on how IE,FF,and Chrome internally implement this at: http://www.aaron-powell.com/web/indexeddb-storage
  • In short:
    • IE uses the same database format as Exchange and Active Directory for IndexedDB
    • Firefox is using SQLite so are kind of implementing a NoSQL database in to SQL database
    • Chrome (and WebKit) are using a Key/ Value store which has heritage in BigTable
  • 有一篇关于 IE、FF 和 Chrome 如何在内部实现这一点的优秀文章：http: //www.aaron-powell.com/web/indexeddb-storage
  • 简而言之：
    • IE 对 IndexedDB 使用与 Exchange 和 Active Directory 相同的数据库格式
    • Firefox 正在使用 SQLite，因此在 SQL 数据库中实现了 NoSQL 数据库
    • Chrome（和 WebKit）正在使用在 BigTable 中具有继承性的键/值存储

My Current Results

我目前的成绩

  • I chose to use an IndexedDB approach (and polyfill with FileSystemAPI for Chrome until they ship blob support)
  • For fetching the tiles, I had a dilemna since the JQUERY folks are kvetching about adding this to AJAX
  • I went with XHR2-Lib by Phil Parsons, which is very much like JQUERY .ajax() https://github.com/p-m-p/xhr2-lib
  • Performance for 100MB downloads (IE10 4s, Chrome 6s, FireFox 7s).
  • I could not get any of the IndexedDB wrappers to work for blobs (lawnchair, PouchDB, jquery-indexeddb, etc.)
  • I rolled my own wrapper, and performance is (IE10 2s, Chrome 3s, FireFox 10s)
  • With FF, I assume we are seeing the performance issue of using a relational DB (sqllite) for a non-sql storage
  • NOTE, Chrome has outstanding debug tools (developer tab, resources) for inspecting the state of the IndexedDB.
  • 我选择使用 IndexedDB 方法（并使用 FileSystemAPI for Chrome 进行 polyfill，直到它们提供 blob 支持）
  • 为了获取瓷砖，我遇到了困境，因为 JQUERY 的人正在讨论将其添加到 AJAX
  • 我使用了 Phil Parsons 的 XHR2-Lib，它非常像 JQUERY .ajax() https://github.com/pmp/xhr2-lib
  • 100MB 下载性能（IE10 4s、Chrome 6s、FireFox 7s）。
  • 我无法让任何 IndexedDB 包装器为 blob（草坪椅、PouchDB、jquery-indexeddb 等）工作
  • 我推出了自己的包装器，性能是（IE10 2s、Chrome 3s、FireFox 10s）
  • 使用 FF，我假设我们看到了将关系数据库 (sqllite) 用于非 sql 存储的性能问题
  • 注意，Chrome 具有出色的调试工具（开发人员选项卡、资源）用于检查 IndexedDB 的状态。

FINAL Results posted below as answer

最终结果作为答案发布在下面

Update

更新

PouchDB now supports binary blobs for all recent browsers (IE, Chrome, Firefox, Chrome on mobile, etc.) as well as many older browsers. That was not the case when I first did this post.

PouchDB 现在支持所有最新浏览器（IE、Chrome、Firefox、移动版 Chrome 等）以及许多旧浏览器的二进制 blob。当我第一次写这篇文章时，情况并非如此。

采纳答案by Dr.YSG

Results Offline blob cache for PNG slippy maps

结果 PNG 滑动地图的离线 blob 缓存

Testing

测试

  • 171 PNG files (total of 3.2MB)
  • Platforms tested: Chrome v24, FireFox 18, IE 10
  • Should also work with Chrome & FF for Android
  • 171 个 PNG 文件（共 3.2MB）
  • 测试平台：Chrome v24、FireFox 18、IE 10
  • 还应该与 Chrome 和 FF for Android 一起使用

Fetch from web server

从网络服务器获取

  • using XHR2 (supported on almost all browsers) for blob download from web server
  • I went with XHR2-Lib by Phil Parsons, which is very much like JQUERY .ajax()
  • 使用 XHR2（几乎所有浏览器都支持）从 Web 服务器下载 blob
  • 我使用了 Phil Parsons 的 XHR2-Lib，它非常像 JQUERY .ajax()

Storage

贮存

Display

展示

  • I am using Leaflet http://leafletjs.com/to show the map tiles
  • I used the functional tile layer plugin by Ishmael Smyrnow for fetching the tile layer from the DB
  • I compared the DB-based tiles layer with a purely local (localhost://) storage
  • There is no noticeable difference in performance! between using IndexedDB and local files!

Results

结果

  • Chrome: Fetch (6.551s), Store (8.247s), Total Elapsed Time: (13.714s)
  • FireFox: Fetch (0.422s), Store (31.519s), Total Elapsed Time: (32.836s)
  • IE 10: Fetch (0.668s), Store: (0.896s), Total Elapsed Time: (3.758s)
  • Chrome：获取（6.551s），存储（8.247s），总经过时间：（13.714s）
  • FireFox：获取（0.422s），存储（31.519s），总运行时间：（32.836s）
  • IE 10：获取（0.668s），存储：（0.896s），总运行时间：（3.758s）

回答by Bogdan Kulynych

For your requirements I suggest that developing a new polyfill based on two others: FileSystem API to IndexedDBand IndexedDB to WebSQL— is the best option.

对于您的要求，我建议基于另外两个开发新的 polyfill： FileSystem API 到 IndexedDB和IndexedDB 到 WebSQL— 是最好的选择。

The former one will enable support for storing blobs in Chrome (FileSystem API) and Firefox (IndexedDB), while the latter should provide the support for Android and iOS (WebSQL). What is needed is just making these polyfills work together, and I suppose it's not hard.

前者将支持在 Chrome (FileSystem API) 和 Firefox (IndexedDB) 中存储 blob，而后者应提供对 Android 和 iOS ( WebSQL) 的支持。所需要的只是让这些 polyfill 协同工作，我想这并不难。

NB:Since I couldn't find any information on the web about this, you should test if storing blobs using the WebSQL polyfill will work on iOS and Android. It looks like it should work though:

注意：由于我在网络上找不到任何关于此的信息，您应该测试使用 WebSQL polyfill 存储 blob 是否适用于 iOS 和 Android。看起来它应该可以工作：

var sql = ["CREATE TABLE", idbModules.util.quote(storeName), "(key BLOB", createOptions.autoIncrement ? ", inc INTEGER PRIMARY KEY AUTOINCREMENT" : "PRIMARY KEY", ", value BLOB)"].join(" ")

Source

来源

回答by tbicr

I have map caching examples(open example, discover regions and zooms, switch offline and discovered regions will availaible).

我有地图缓存示例（打开示例，发现区域和缩放，离线切换和发现的区域将可用）。

There are map.js- map layer for offline tiles, storage.js- storage implementation based on IndexedDb and WebSQL (but this just test implementation with poor performance).

有map.js- 离线图块的地图层，storage.js- 基于 IndexedDb 和 WebSQL 的存储实现（但这只是性能不佳的测试实现）。

  • For site files (html, css, js and etc.) I prefer use application cache.
  • For storage I prefer use Indexed DB (support blob), Web SQL (only base64), FileWriter (support blob, but only chrome). Frankly storage is big issue for this. You need the fastest key value solution that will mix them all. I think is good decision to use exist solution.
  • For fetching I used canvas with CORS. But I thinking about WebWorkers and XHR2 and this can be better instead canvas because canvas have some troubles with CORS in different browsers and other (for example this titlewas stored bad in opera).
  • 对于站点文件（html、css、js 等），我更喜欢使用应用程序缓存。
  • 对于存储，我更喜欢使用 Indexed DB（支持 blob）、Web SQL（仅 base64）、FileWriter（支持 blob，但仅支持 chrome）。坦率地说，存储是一个大问题。您需要将它们混合在一起的最快的键值解决方案。我认为使用现有解决方案是个好决定。
  • 为了获取，我使用了带有 CORS 的画布。但是我在考虑 WebWorkers 和 XHR2，这可以更好地代替画布，因为画布在不同浏览器和其他浏览器中的 CORS 存在一些问题（例如，这个标题在 opera中存储不好）。

Additional information about sizes for 2 billion city (Minsk):

关于 20 亿城市（明斯克）规模的附加信息：

  • Zoom - 9, tiles - 2, size - 52 kb, with previous - 52 kb;
  • Zoom - 10, tiles - 3, size - 72 kb, with previous - 124 kb;
  • Zoom - 11, tiles - 7, size - 204 kb, with previous - 328 kb;
  • Zoom - 12, tiles - 17, size - 348 kb, with previous - 676 kb;
  • Zoom - 13, tiles - 48, size - 820 kb, with previous - 1.5 mb;
  • Zoom - 14, tiles - 158, size - 2.2 mb, with previous - 3.7 mb;
  • Zoom - 15, tiles - 586, size - 5.5 mb, with previous - 9.3 mb;
  • Zoom - 16, tiles - 2264, size - 15 mb, with previous - 24.3 mb;
  • 缩放 - 9，图块 - 2，大小 - 52 kb，前一个 - 52 kb；
  • 缩放 - 10，图块 - 3，大小 - 72 kb，前一个 - 124 kb；
  • 缩放 - 11，图块 - 7，大小 - 204 kb，之前 - 328 kb；
  • 缩放 - 12，图块 - 17，大小 - 348 kb，之前 - 676 kb；
  • 缩放 - 13，图块 - 48，大小 - 820 kb，之前 - 1.5 mb；
  • 缩放 - 14，图块 - 158，大小 - 2.2 mb，前一个 - 3.7 mb；
  • 缩放 - 15，图块 - 586，大小 - 5.5 mb，前一个 - 9.3 mb；
  • 缩放 - 16，图块 - 2264，大小 - 15 mb，前一个 - 24.3 mb；

回答by Manidip Sengupta

A few years back (not exactly the stone age), I was using a signed java applet that would query its server for syncing/updating requirements, download appropriate files from the server and save them on the user's filesystem (not a database). That solution might work for you, although you will need someone to write the applet and sign it. For database solutions, such an applet can use the jdbc available for most databases using localhost on a suitable port (e.g., 3306 for MySQL). I believe the applet tag is deprecated in Html5 but it still works. No experience on Android tablets, so can't comment on that part.

几年前（不完全是石器时代），我使用了一个签名的 Java 小程序，它会查询其服务器的同步/更新要求，从服务器下载适当的文件并将它们保存在用户的文件系统（不是数据库）上。该解决方案可能对您有用，尽管您需要有人编写小程序并对其进行签名。对于数据库解决方案，这样的小程序可以使用适用于大多数数据库的 jdbc，在合适的端口上使用 localhost（例如，3306 用于 MySQL）。我相信小程序标签在 Html5 中已被弃用，但它仍然有效。没有Android平板电脑的经验，所以不能评论这部分。

相关推荐

在 Javascript 中返回一个字符串

在 Javascript 中返回一个字符串

Javascript AngularJS 模板中的条件逻辑

Javascript AngularJS 模板中的条件逻辑

Javascript Jquery 在输入中禁用自动完成功能

Javascript Jquery 在输入中禁用自动完成功能

Javascript 如何在asp.net页面加载时调用javascript函数

Javascript 如何在asp.net页面加载时调用javascript函数

相关推荐
最近更新
标签