Comment une extension Chrome Chrome peut-elle enregistrer de nombreux fichiers dans un répertoire spécifié par l'utilisateur?
Je travaille sur une extension Chrome à utiliser comme outil interne. Son comportement requis est:
- En tant qu'action de page, activez une icône de barre d'adresse lorsque vous consultez certaines pages intranet.
- lorsque l'utilisateur clique sur l'icône, identifiez tous les fichiers d'un certain type de support (par exemple, .jpg) sur la page, et
- enregistrez-les en silence dans un répertoire sur le disque local de l'utilisateur.
Cette question a déjà été posée , mais la réponse était alors " tiliser NPAPI ", et NPAPI est maintenant abandonné .
Alors, quel est le moyen actuellement disponible pour y parvenir? Ceux que j'ai examinés sont:
- chrome.FileSystem API --- mais cela n'enregistre pas les fichiers dans un emplacement accessible à l'utilisateur. Au lieu de cela, les fichiers stockés sont cachés derrière les noms obscurcis dans un répertoire non documenté. L'utilisateur exige que les fichiers soient stockés sous leurs noms d'origine dans un répertoire accessible.
- L'attribut de téléchargement HTML5 , en créant une URL de données: et en cliquant par programme dessus. Cela ouvre une boîte de dialogue "Enregistrer sous ..." pour chaque fichier, ce qui est inacceptable lorsqu'il y a une centaine de ressources sur une seule page. L'utilisateur exige que les fichiers soient téléchargés sans autre interaction au-delà du simple clic sur l'icône.
- Chrome Download API , mais qui n'est disponible que dans les canaux bêta et dev. L'utilisateur a besoin de cette extension avec Chrome classique.
- Utilisez Native Messaging API en créant un petit fichier .exe qui enregistre simplement un fichier sur le disque, puis passez le .jpg en tant qu'objet blob. Cela semble très lourd et je ne sais même pas comment transmettre de manière fiable de gros objets blob à des EXE comme ça.
Y a-t-il une autre approche que je peux essayer?
Vous avez fait pas mal de recherches. En effet, les pages Web ordinaires ne peuvent pas écrire dans le système de fichiers de l'utilisateur sans plugins ni extensions. De plus, API du système de fichiers HTML5 ne donne accès qu'à un système de fichiers virtuel, comme vous l'avez observé.
Cependant, vous confondez le chrome.fileSystem API avec l'API HTML5 FileSystem. Contrairement à l'API HTML FileSystem, l'API fileSystem (app) de Chrome peut écrire directement dans le système de fichiers de l'utilisateur (par exemple ~/Documents ou %USERPROFILE%\Documents), spécifié par l'utilisateur.
Cette API n'est disponible que pour les applications Chrome , pas pour les extensions. Ce n'est pas un problème, d'autant plus que vous êtes développer un outil interne, car vous pouvez installer l'application et l'extension, et utiliser passage de message pour communiquer entre l'extension (action de la page) et l'application (accès au système de fichiers) ( exemple ).
À propos de chrome.downloads : Étant donné que votre extension est interne, vous pouvez probablement forcer les utilisateurs à accéder au canal bêta/dev afin d'utiliser cette API. La seule limitation de cette API est que les fichiers seront enregistrés dans (un sous-répertoire de) le dossier Téléchargements défini par l'utilisateur.
EDIT: le chrome.downloads L'API est désormais disponible sur tous les canaux, y compris la branche stable (depuis Chrome 31).
Je crains que vous n'ayez fait vos devoirs, ce qui signifie que vous avez examiné toutes les alternatives possibles.
La meilleure façon de réaliser exactement ce que vous voulez serait (comme vous l'avez mentionné) d'utiliser une application native prise en charge et de communiquer via la messagerie native. BTW, puisque la bande passante est rarement un problème sur les intranets, vous trouverez peut-être plus simple de transmettre les URL des ressources (par exemple des images) et de faire télécharger et enregistrer l'application.
(Oui, ce sera plus compliqué que de simplement développer une extension, mais il faut faire ce qu'ils ont à faire, non?)
D'un autre côté, si vous êtes prêt à sacrifier un peu d'expérience utilisateur sur la simplicité de développement, je suggère de combiner les goodies HTML5 (qui vous permettent de créer et de télécharger un fichier localement) avec une bibliothèque de zips JS (par exemple JSZip), donc l'utilisateur n'a qu'à télécharger un seul fichier Zip (et n'est invité qu'une seule fois). BTW, si l'utilisateur le souhaite, il/elle peut choisir de toujours télécharger les fichiers sans invite (mais vous le saviez déjà).
Utilisez l'idée de l'application de messagerie native.
L'application native est lourde et difficile à écrire car la documentation est médiocre, et à moins que vous obteniez le formatage JSON exactement correct aux deux extrémités, vous ne verrez rien dans une console car stdin et stdout sont pris en charge.
Mais vous serez plus heureux quand cela sera fait, car vous pouvez utiliser des outils standard (par exemple, l'Explorateur Windows, un éditeur hexadécimal, TeamViewer ...) pour afficher, déplacer et supprimer des fichiers, et sinon voir ce qui se passe. Le système de fichiers en bac à sable de Chrome fonctionne, mais semble maintenant être une impasse (aucun autre navigateur ne l'a détecté). Personne n'est susceptible de développer des outils tiers pour cela. Bien sûr, vous n'avez probablement pas besoin d'outils une fois que tout fonctionne, mais jusque-là, le débogage est un cauchemar car vous devez écrire du code (et pas mal de code) juste pour suivre quels fichiers se trouvent dans quels répertoires, versions de fichiers, restants espace disque...