HTML5 автономное хранилище. Файловое хранилище? Каталоги и файловой системы API

Question

Для хранения данных в автономном режиме WebApp можно использовать:

• хранения сессии "продвинутую версию печенья"
• ключ на основе/значение Web Storage (AKA локальное/глобальное хранения/форума/DOM)
• SQL на основе Web SQL Database (устаревшее) и Indexed Database API
• FileReader и FileWriter API (требуется пользователю выбрать файлы каждый раз, когда приложение загружает)

Но, по-видимому, нет хранилища файлов. Конечно, есть manifest-based caching, но это всего лишь кеш и не предполагается использовать в качестве хранилища пользовательских данных.

Означает ли это, что пользователь WebApp вынужден использовать какое-то хранилище облачных файлов?

Можно ли сохранить большие файлы на локальной машине пользователя? Или, может быть, какой-то способ выбрать веб-приложение локальной папки можно использовать для хранения пользовательских данных?

Редактировать. Безопасность. HTML5 уже имеет возможность писать большие части данных на локальную машину пользователя. Я не вижу никаких проблем с безопасностью, если браузер предоставит другую файловую абстракцию для хранения данных. Это может быть какая-то виртуальная машина, виртуальная файловая система.

Хм, я думаю, что можно написать JS файловую систему и сохранить его как двоичный объект в SQL ...

Similarquestions.

Update: Хм ... Недавно я нашел this и this. Возможно, это то, что я ищу ... Да, это так! См. Ответ ниже.

Answer 1

Наконец-то я нашел его! Вот ответ:

I’ll have the DOMFileSystem with a side of read/write access please писал:

Эрик Uhrhane из Google был работает на рабочий проект File API: Directories and System specification, который определяет набор API, чтобы создать песочницы файловую систему , где веб-приложение может читать и писать данные .

Ничего себе! Я так взволнован!

Answer 2

По соображениям безопасности вы не можете записывать файлы в локальную файловую систему пользователя в случае, если злоумышленники будут использовать их в гнусных целях.

Это вряд ли изменится, и это хорошо.

Answer 3

Существует способ сохранения относительно больших файлов на жесткий диск пользователя, если вы хотите использовать Flash. Посмотрите в Downloadify:

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

Downloadify позволяет передавать данные в SWF и есть, что SWF создать файл на компьютере пользователя. Моя рекомендация состояла в том, чтобы хранить данные с помощью одного из перечисленных вами методов, Webstorage, базы данных sqlite и т. Д. Поместите все ваши ресурсы, включая SWF в файл манифеста, чтобы все было кэшировано локально в браузере. Затем вы можете извлекать информацию из своего db или webstorage и использовать SWF для создания необходимых вам файлов.

Я не уверен, что вы сможете прочитать эти файлы в своем веб-приложении.

Другой способ сохранения данных - использовать теги ссылок с помощью data URI scheme. Однако я не уверен, что он поддерживается во всех основных браузерах на данный момент.

Answer 4

Почему бы не использовать localStorage, когда пользователь редактирует документ и API FileWriter, когда он хочет сохранить его на диск? Большинство людей привыкли видеть диалог сохранения при открытии документа.

Единственный сценарий, который я могу придумать, гарантирует беспроблемный доступ к API FileWriter, это функция автосохранения, но автосохранение до localStorage может быть таким же хорошим.

Answer 5

API-интерфейс файловой системы HTML5 начал посадку в Chrome 8 и на данный момент является довольно полным (Chrome 11).

Там хороший учебник по нему здесь: http://www.html5rocks.com/tutorials/file/filesystem/

Answer 6

http://fsojs.com эффективно обертывания FileSystem API, если вы хотите простое решение

Answer 7

Как уже отмечалось другими здесь, то FileWriter и FileSystem API-интерфейсы могут быть использованы для хранения файлов на компьютере клиента из контекста вкладки/окна браузера.

Однако, есть несколько вещей, относящихся к этим API, которые вы должны знать:

• Реализация API, в настоящее время существует только в браузерах на основе хрома (хром & Opera)
• Оба API-интерфейсы были сняты из стандартов W3C трек 24 апреля 2014 года, и на сегодняшний день является собственностью
• удаления (ныне запатентованного) API, от реализации браузеров в будущем возможности
• sandbox (место на диске, за пределами которого файлы не могут произвести никакого эффекта) используется для хранения файлов, созданных с помощью API.
• A виртуальная файловая система (структура каталогов, которая не обязательно существует на диске в том же форма, что она делает, когда доступ из браузера) используется представляют файлы, созданные с помощью API-интерфейсов

IsolatedStorage, которые не были упомянуты как еще, позволяет также файл ввод/вывод из вкладки/окна контекст, но он доступен только через Silverlight и требует использования managed code для доступа. Он, как и FileSystem, также существует в песочнице и использует виртуальную файловую систему.

Учитывая высокую степень проникновения на рынок как браузеров на основе хрома, так и Silverlight (поддержка, которая, как это ни удивительно, была удалена такими браузерами), вы можете найти решение, которое использует первый из вышеперечисленных подходов, доступных на клиентской машине удовлетворительный.

BakedGoods, библиотека Javascript, которая устанавливает единый интерфейс, который может использоваться для проведения общих операций хранения во всех родных (в том числе FileSystem) и некоторых не связанных с носителями (включая Inventory) хранилищах, является примером такого решения :

//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 поддерживается этим парнем прямо здесь :).