Как расширение Chrome может сохранить многие файлы в указанном пользователем каталоге?

Я работаю над расширением Chrome, которое будет использоваться в качестве внутреннего инструмента. Его требуемое поведение:

  • В качестве действия страницы активируйте значок адресной строки при просмотре определенных страниц интрасети.
  • когда пользователь нажимает значок, идентифицирует все файлы определенного типа носителя (например,.jpg) на странице и
  • молча сохранить их все в каталог на локальном диске пользователя.

Этот вопрос задан до, но тогда ответ был "использовать NPAPI" и NPAPI теперь заброшен.

Итак, каков доступный в настоящее время способ достичь этого? Я смотрел:

  • API chrome.FileSystem --- но это не сохраняет файлы в любом доступном для пользователя месте. Вместо этого хранящиеся файлы скрыты за обфускации имен в недокументированном каталоге. Пользователь требует, чтобы файлы были сохранены под их исходными именами в доступном каталоге.
  • атрибут загрузки HTML5, создав URL-адрес данных и программно нажав на него. Появится диалоговое окно "Сохранить как..." для каждого файла, что неприемлемо, если на одной странице есть сто ресурсов. Пользователь требует, чтобы файлы загружались без дальнейшего взаимодействия, кроме одного значка.
  • Chrome Download API, но доступен только в бета-версиях и dev-каналах. Пользователь требует, чтобы эта работа расширилась с основным браузером Chrome.
  • Используйте Native Messaging API, создав небольшой файл .exe, который просто сохраняет файл на диск, а затем передает .jpg как blob к нему. Это кажется очень громоздким, и я даже не уверен, как надежно передать большие капли в EXE, как это.

Есть ли другой подход, который я могу попробовать?

ОТВЕТЫ

Ответ 1

Вы провели довольно много исследований. Действительно, обычные веб-страницы не могут записываться в файловую систему пользователя без каких-либо плагинов или расширений. Кроме того, API файловой системы HTML5 обеспечивает доступ к виртуальной файловой системе, как вы заметили.

Однако вы путаете API chrome.fileSystem с API-интерфейсом HTML5 FileSystem. В отличие от API HTML FileSystem, API fileSystem (app) Chrome может напрямую писать в пользовательскую файловую систему (например, ~/Documents или %USERPROFILE%\Documents), указанную пользователем.

Этот API доступен только для Chrome приложений, а не для расширений. Это не проблема, тем более, что вы разрабатываете внутренний инструмент, потому что вы можете установить приложение и расширение и использовать сообщение между расширением (действие страницы) и приложением (доступ к файловой системе) (пример).

О chrome.downloads: Поскольку ваше внутреннее расширение является внутренним, вы, вероятно, можете заставить пользователей попасть на бета-канал, чтобы использовать этот API. Единственным ограничением этого API является то, что файлы будут сохранены в (подкаталоге) пользовательской папки Downloads.

EDIT: API chrome.downloads теперь доступен во всех каналах, включая стабильную ветку (начиная с Chrome 31).

Ответ 2

Я боюсь, что вы сделали домашнее задание, а это значит, что вы посмотрели на все возможные альтернативы.

Лучший способ достичь именно того, что вы хотите, будет (как вы упомянули), используя поддерживающее родное приложение и обмениваясь данными через Native Messaging. Кстати, поскольку пропускная способность редко возникает в интрасетях, вам может быть проще пропустить URL-адреса ресурсов (например, изображения) и загрузить приложение и сохранить их.
(Да, это будет более громоздко, чем просто разработка расширения, но нужно делать то, что им нужно делать, не так ли?)

С другой стороны, если вы готовы пожертвовать небольшим количеством пользовательского опыта по простоте разработки, я предлагаю комбинировать товарные знаки HTML5 (которые позволяют создавать и загружать файлы локально) с помощью JS-zipping-библиотеки (например, JSZip), поэтому пользователю нужно загрузить только один ZIP файл (и он запрашивается только один раз). BTW, если пользователь пожелает, он может выбрать всегда загружать файлы без подсказки (но вы уже это знали).

Ответ 3

Используйте идею приложения Native Messaging.

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

Но вы будете счастливее, когда это будет сделано, потому что вы можете использовать стандартные инструменты (например, проводник Windows, шестнадцатеричный редактор, TeamViewer...) для просмотра, перемещения и удаления файлов и в противном случае посмотреть, что происходит, Хромовая файловая система с песочницей работает, но, похоже, теперь она тупиковая (другие браузеры ее не выбрали). Никто не может разработать для него сторонние инструменты. Конечно, вам, вероятно, не нужны инструменты, когда все работает, но до тех пор отладка - это кошмар, потому что вам нужно написать код (и довольно много кода), чтобы отслеживать, какие файлы находятся в каких каталогах, версиях файлов, остатках дисковое пространство...