Com obrir fitxers locals al navegador amb file:///

Usar el navegador com si fos un petit explorador de fitxers és possible i, ben aprofitat, pot ser tremendament útil. Des d'obrir un simple document local amb file:/// fins a treballar amb la potent API de File System Access, avui dia els navegadors moderns ofereixen moltes més possibilitats de les que solem fer servir.

Al llarg d'aquesta guia veurem, pas a pas, com obrir fitxers locals al navegador web usant file:/// a Chrome, Edge i Firefox, com convertir el propi navegador en un explorador bàsic a Windows i Android, i com els desenvolupadors poden anar un pas més enllà gràcies a l'API de File System Access per llegir, escriure i gestionar fitxers i carpetes locals des d'una aplicació web.

Què significa realment obrir fitxers locals amb file:///

Quan escrius una ruta que comença per file:/// a la barra d'adreces del navegador, estàs dient al navegador que en lloc d'anar a Internet accedeixi al sistema de fitxers local. És a dir, que obri alguna cosa que està al teu propi dispositiu: un disc dur, una memòria interna o una targeta SD.

Aquest esquema d'URL especial (file:///) funciona de forma semblant a escriure C: a Windows o / a Linux i macOS, només adaptat a la lògica del navegador. A partir d'aquí, el que veuràs és una mena de llistat de carpetes i fitxers, sense floritures: noms, mides, data de modificació i poca cosa més.

Això sí, cal tenir en compte que els navegadors tracten aquestes rutes locals amb moltes restriccions de seguretat. Per exemple, una pàgina web que visites des d'Internet no pot, per defecte, llegir lliurement els teus fitxers locals només perquè tu obris una URL amb file:///. Sempre s'exigeix ​​un gest o un permís explícit de l'usuari.

Usar el navegador com a explorador de fitxers en Android

En molts mòbils Android el fabricant no inclou un gestor de fitxers decent, o el que ve de sèrie és una mica limitat. En aquests casos, tirar de Chrome, Edge o un altre navegador basat en Chromium com a explorador improvisat pot treure't de la dificultat.

El truc és molt senzill: obre el teu navegador basat en Chromium (Chrome, Edge, Brave, etc.) i escriu a la barra d'adreces file:///sdcard/. Android identifica el emmagatzematge intern principal com sdcard, de manera molt similar a com Windows utilitza C: per a la unitat principal.

En llançar aquesta adreça, el més habitual és que el navegador et demani permís per llegir l'emmagatzematge intern. Quan concedeixes aquest permís, apareixerà un índex amb les carpetes arrel de la teva memòria interna. Des d'aquí podeu anar entrant i sortint de carpetes exactament igual que si estiguessis navegant per una web d'enllaços.

A cada carpeta veuràs tant subcarpetes com fitxers. Els fitxers es mostren amb el nom complet, incloent-hi l'extensió, la mida i l'última data de modificació. També es llisten les carpetes ocultes, que a Android solen començar amb un punt, com .nomedia o altres de similars.

Tot i que el llistat és molt espartà, la majoria de navegadors moderns són capaços d'obrir directament molts tipus de fitxers en tocar-los: imatges, vídeos, àudios, documents de text, etc. No hi ha miniatures ni previsualitzacions, però només cal prémer sobre el nom del fitxer perquè el navegador intenti mostrar-lo o reproduir-lo.

Convertir Chrome i Edge en un petit explorador de fitxers a PC

A ordinadors d'escriptori, tant a Windows com a altres sistemes, també pots fer servir Chrome, Edge i altres navegadors basats en Chromium per navegar pels teus discos locals amb file:///. El principi és el mateix que a Android, però canviant la ruta.

Si utilitzes Windows, el més comú és que la unitat principal sigui C:. En aquest cas, escriu a la barra d'adreces file:///C: i prem Intro. El navegador us mostrarà el contingut de l'arrel d'aquesta unitat: carpetes com Windows, Program Files, Usuarios, Etc

Si tens més unitats o particions, pots substituir la lletra a la URL per la qual correspongui. Per exemple, file:///D: per a un altre disc o file:///E: per a una memòria USB que s'hagi muntat amb aquesta lletra. A partir d'aquí, clic a les carpetes per anar avançant i fes servir el botó d'anar enrere del navegador per retrocedir.

De la mateixa manera que a Android, a cada carpeta veuràs arxius i subcarpetes amb mida, data de modificació i extensió visibles. No es generen vistes en miniatura ni icones boniques, però és suficient per localitzar un fitxer concret o fer una ullada ràpida a l'estructura d'un directori.

La majoria de navegadors Chromium permeten obrir directament fitxers multimèdia i fins i tot alguns formats de documents simplement fent clic sobre ells. Imatges, vídeos, àudios o fitxers de text pla es mostren amb força naturalitat dins de la pestanya.

Obrir fitxers locals a Chrome i Firefox sense escriure file:/// a mà

A més de teclejar rutes amb file:///, els navegadors inclouen dreceres pensades justament per obrir fitxers locals de forma ràpida. A Chrome, per exemple, podeu utilitzar la combinació de tecles Ctrl + O (Control + O) quan la finestra del navegador està activa.

En prémer aquesta drecera, s'obre el típic quadre de diàleg “Obrir fitxer” del sistema operatiu. Només heu de buscar el fitxer que us interessi, seleccionar-lo i confirmar. Chrome el carregarà a la pestanya actual oa una de nova, segons el tipus de fitxer i les preferències.

El Firefox té diverses opcions. D'una banda, pots anar al menú principal i triar l'opció “Obrir fitxer…”, que fa exactament el mateix: mostrar la finestra de selecció de fitxer del sistema. De l'altra, podeu escriure directament a la barra d'adreces una ruta del tipus file:///// perquè el navegador comenci mostrant el contingut de la unitat C: a Windows.

Amb qualsevol daquests mètodes, el resultat pràctic és que el navegador es converteix en un visor de fitxers locals. Pot ajudar-te quan el Explorador de Windows es penja, quan tens problemes amb el gestor de fitxers habitual o simplement quan vols obrir un tipus de document que el navegador maneja particularment bé.

L'API del File System Access: el salt de visor a editor

Tot el que hem vist fins ara es basa en lús “manual” de file:/// i en els quadres de diàleg d'obrir fitxer, és a dir, en coses que fa l'usuari a mà. Però des de fa un temps, els navegadors basats en Chromium incorporen l'API de File System Access, que dóna a les aplicacions web la capacitat de treballar amb fitxers locals d'una forma molt més avançada.

Aquesta API permet que una web, després de demanar el teu permís, llegiu i deseu canvis directament en fitxers i carpetes del dispositiu. Gràcies a això es poden crear des del navegador editors de text seriosos, IDEs de programació, editors de foto i vídeo, gestors de projectes i moltes altres eines que abans només tenia sentit desenvolupar com a aplicacions descriptori.

És important no confondre aquesta API moderna amb altres de més antigues o ja obsoletes. No és el mateix que la interfície FileSystem de l'API de File and Directory Entries ni que l'antiga especificació “File API: Directories and System”, que proposaven altres mecanismes per tractar jerarquies d'arxius i zones d'emmagatzematge a sandbox.

L'API de File System Access actual s'ha dissenyat amb una cura especial en matèria de seguretat, permisos i experiència d'usuari. Sempre requereix accions explícites (com fer clic a un botó) per obrir el selector de fitxers o directoris, i l'usuari té clar en tot moment a quines rutes exactes està donant accés.

Pel que fa a compatibilitat, l'API funciona a la majoria de navegadors basats en Chromium a Windows, macOS, Linux, ChromeOS i Android. Una excepció destacada és Brave, on encara cal activar una marca (flag) per poder utilitzar-la. Altres navegadors no Chromium poden no implementar-la o fer-ho de manera parcial.

Comproveu si el navegador suporta l'API de File System Access

Com a desenvolupador, el primer que us interessa saber és si el navegador de l'usuari suporta aquesta API abans d'intentar utilitzar-la. La manera més senzilla és mirar si hi ha els mètodes de selecció de fitxers corresponents a l'objecte global, per exemple comprovant si showOpenFilePicker està disponible en window (o self en un worker).

El patró típic consisteix en una cosa semblant a: "si 'showOpenFilePicker' està en self, llavors puc utilitzar l'API; si no, he de recórrer a un mètode alternatiu". Això permet implementar solucions híbrides on, si hi ha suport, s'aprofiten els avantatges de l'API, i si no n'hi ha cau a tècniques tradicionals com els formularis de pujada de fitxers.

També és bona idea testejar als navegadors destinació i en diferents sistemes operatius, perquè encara que la base sigui Chromium, alguns fabricants poden activar o desactivar característiques concretes per motius de seguretat, política o rendiment.

Primer exemple: obrir un fitxer local des d'una app web

Un dels exemples canònics per entendre aquesta API és construir un editor de text d'un sol fitxer que permeti obrir, modificar i tornar a desar un document. No cal que sigui espectacular: amb què llegiu i escriviu text pla ja il·lustra bé el funcionament.

El punt d'entrada aquí és el mètode window.showOpenFilePicker(). Aquest mètode, que només es pot anomenar en un context segur (HTTPS) i en resposta a un gest d'usuari, mostra un diàleg nadiu perquè l'usuari esculli un fitxer. Un cop seleccionat, torna un array de manejadors, normalment amb un únic FileSystemFileHandle.

Aquest manejador emmagatzema tota la informació i mètodes necessaris per treballar amb el fitxer escollit. Convé desar una referència al handle, perquè serà el que facis servir més tard per llegir el fitxer, guardar canvis o realitzar qualsevol altra operació. Mentre mantinguis aquest handle i l'usuari no hagi revocat permisos, la teva app podrà interactuar amb el fitxer.

Quan tens el FileSystemFileHandle, pots obtenir l'objecte File real trucant a handle.getFile(). Aquest objecte File conté les dades del fitxer com un blob, i pots accedir al seu contingut amb mètodes com text(), arrayBuffer(), stream() o slice() si necessites accés aleatori.

A la pràctica, per a un editor de text senzill, l'habitual és fer servir file.text() per obtenir el contingut complet com a cadena, i bolcar aquest text en un <textarea> perquè l'usuari ho editi. Cal tenir en compte que lobjecte File deixa de ser vàlid si l'arxiu es modifica en disc per una altra via, cas en què convé tornar a trucar a getFile().

Desar canvis: escriure al sistema de fitxers local

Per desar allò que l'usuari ha editat, l'API ofereix dos camins típics: un desat “simple” que sobreescriu el fitxer original i un “Guardar com” que crea un fitxer nou. La diferència fonamental és si ja tens un handle al fitxer destí o si necessites que l'usuari esculli una nova ruta i nom.

Quan voleu crear un fitxer nou o desar una còpia amb un altre nom, has de fer servir showSaveFilePicker(). Aquest mètode obre el selector de fitxers en mode desat, permetent que l'usuari indiqui nom, carpeta i extensió. Pots passar opcions per suggerir tipus de fitxer, per exemple indicar que es tracta de documents de text i que l'extensió preferida sigui .txt.

Un detall important és que has de trucar a showSaveFilePicker() directament en resposta al gest de l'usuari (per exemple, el clic al botó “Guardar”) i no retardar-lo mentre fas processat pesat. Si fas tota la feina prèvia i després, amb retard, intentes obrir el diàleg, el navegador pot llançar un error de seguretat perquè ja no es considera que estàs “manejant un gest d'usuari”.

Un cop tens un FileSystemFileHandle apuntant a l'arxiu on vols desar, el següent pas és crear un FileSystemWritableFileStream usant fileHandle.createWritable(). Aquest stream és el que utilitzaràs per escriure les dades. Si el navegador detecta que encara no teniu permís d'escriptura, us mostrarà un quadre de permisos; si l'usuari ho denega, la trucada llança una excepció.

Amb el stream a la mà, simplement crides a writable.write(contenido) amb una cadena, un Blob o un BufferSource. Pots canalitzar directament el cos d'una resposta HTTP cap al stream amb response.body.pipeTo(writable). Quan acabeu d'escriure, tanqueu la transmissió amb writable.close(), que és el moment en què els canvis es consoliden en disc.

Mentre la transmissió està oberta, també pots utilitzar mètodes com seek() o truncate() per moure el punter d'escriptura a una posició concreta o canviar la mida del fitxer. Però cal recordar que els canvis no s'apliquen de manera definitiva fins que es tanca el stream.

Suggerir nom de fitxer i carpeta inicial a l'usuari

L'API també té cura de l'experiència d'usuari als quadres de diàleg del sistema. Per exemple, pots indicar un nom de fitxer suggerit quan truques a showSaveFilePicker(). Això permet que, en lloc de mostrar un genèric “Sense títol”, l'usuari vegi una mica més descriptiu com a “Document nou.txt”.

De la mateixa manera, és possible suggerir una carpeta inicial on comenci el selector de fitxers. Això es fa passant una propietat startIn quan crides a showSaveFilePicker(), showOpenFilePicker() o showDirectoryPicker(). Els valors poden ser cadenes com desktop, documents, downloads, music, pictures o videos, que corresponen a ubicacions estàndard del sistema.

A més, tens l'opció de utilitzar com a valor de startIn un manejador de fitxer o de directori que ja tinguis. En aquest cas, el quadre de diàleg s'obre directament a la carpeta on resideixi aquest handle, cosa que és molt còmode per reprendre el context de treball de la darrera sessió.

Si la vostra aplicació maneja diferents tipus de fitxers (per exemple, documents de text i imatges incrustades), pots definir IDs diferents per a cada tipus de quadre de diàleg. D'aquesta manera, el navegador recordarà la darrera carpeta utilitzada de manera independent per a cada ID, i no barrejareu les rutes de documents amb les d'imatges.

Recordar fitxers i carpetes recents amb IndexedDB

Un dels punts forts de File System Access és que els seus manejadors són serialitzables. Això vol dir que pots emmagatzemar FileSystemFileHandle y FileSystemDirectoryHandle a IndexedDB i recuperar-los en sessions posteriors, sempre respectant la política de permisos.

Gràcies a això, les aplicacions web poden oferir funcionalitats típiques descriptori com llistes de fitxers recents, reobertura de l'últim projecte o recuperació de la carpeta de treball anterior. Només cal guardar els handles a la base de dades del navegador i llegir-los en iniciar l'app.

Quan recuperis un handle emmagatzemat, no donis per fet que els permisos es mantenen. El navegador pot decidir que cal tornar a demanar autorització, per exemple perquè ha passat temps o tancat la darrera pestanya d'aquest origen. Per això és recomanable que el vostre codi comprovi la situació.

Per a aquesta comprovació, l'API inclou els mètodes queryPermission() y requestPermission() tant en manejadors de fitxer com de directori. Primer preguntes en quin estat està el permís, i si no és “granted”, pots sol·licitar-ho de nou a l'usuari, indicant a les opcions si necessites només lectura o lectura i escriptura.

Una bona pràctica és combinar tots dos passos en una funció d'ajuda que, donat un handle i una manera (només lectura o lectura/escriptura), verifiqueu si ja hi ha permís i, si no n'hi ha, mostri el prompt corresponent. Així reduïxes el nombre de diàlegs i fas l'experiència més fluida.

Obrir i recórrer directoris complets des del navegador

A més de fitxers solts, l'API permet treballar amb carpetes senceres. Amb showDirectoryPicker() l'usuari pot seleccionar un directori complet, i l'aplicació rep un FileSystemDirectoryHandle que dóna accés a tots els elements.

Per defecte tindràs permís de lectura sobre els fitxers d'aquest directori, encara que si necessites escriure-hi també pots sol·licitar accés de lectura i escriptura passant { mode: 'readwrite' } en trucar a showDirectoryPicker(). Des d'aquest moment, la vostra app pot llistar i manipular el contingut segons el permís concedit.

Per recórrer la carpeta, pots iterar de forma asíncrona sobre dirHandle.values(), que va retornant un a un els elements que conté: fitxers i subdirectoris. Cada entrada té una propietat kind que t'indica si es tracta d'un "file" o un "directory".

Si necessites accedir a informació de cada fitxer, com la seva mida, pots trucar a entry.getFile(). El recomanable en aquests casos és llançar les lectures en paral·lel usant Promise.all() o tècniques similars, en lloc d'anar una per una de manera estrictament seqüencial, que pot resultar més lenta.

Des d'un directori també pots crear noves carpetes o fitxers amb getDirectoryHandle() y getFileHandle(), indicant a les opcions si vols que es creuen si no existeixen. Per exemple, podeu muntar una estructura de projecte tipus “El meu projecte / Codi / Notes.txt” directament des de l'aplicació web.

Gestionar fitxers: esborrar, reanomenar i moure

L'API no es limita a llegir ni escriure. També us permet eliminar fitxers i carpetes d'un directori usant removeEntry() sobre un FileSystemDirectoryHandle. Si es tracta d'una carpeta, podeu fer que l'esborrat sigui recursiu, de manera que inclogui totes les vostres subcarpetes i fitxers.

Si en lloc de passar pel directori vols actuar directament sobre un manejador de fitxer o de carpeta, alguns navegadors ofereixen el mètode remove() en FileSystemFileHandle y FileSystemDirectoryHandle. D'aquesta manera elimineu aquest element sense necessitat de referir-vos al vostre nom dins del directori pare.

Per a operacions d'organització com ara canviar noms o moure elements a una altra carpeta, existeix el mètode move() a la interfície FileSystemHandle. Pots passar-li directament un nou nom, un directori de destinació, o un directori més el nou nom per fer moviment i reanomenat alhora.

Això sí, hi ha matisos de compatibilitat: el suport de move() està més madur per a fitxers dins del sistema de fitxers privat d'origen (OPFS), i encara pot estar darrere de flags o no estar implementat per a tots els escenaris ni per a directoris en certs navegadors.

Arrossegar i deixar anar arxius i carpetes cap a la web

L'API de File System Access s'integra molt bé amb el sistema d'arrossegar i deixar anar HTML. Quan l'usuari arrossega fitxers o carpetes des del sistema operatiu a una pàgina web, el navegador crea elements DataTransferItem associats.

A través del mètode DataTransferItem.getAsFileSystemHandle(), pots obtenir un FileSystemFileHandle si l'element és un fitxer o un FileSystemDirectoryHandle si és un directori. Així, una app pot acceptar que lusuari arrossegui una carpeta completa de fotos i treballar directament sobre el seu contingut.

Has de tenir en compte que, en el context d'arrossegar i deixar anar, DataTransferItem.kind serà sempre «file» tant per a arxius com per a carpetes. La distinció entre fitxer i directori l'obtindràs consultant la propietat kind el compliment del FileSystemHandle que et retorni getAsFileSystemHandle(), que sí que diferenciarà entre "file" y "directory".

Sistema de fitxers privat d'origen (OPFS) i accés optimitzat

A més de l'accés a fitxers i carpetes de l'usuari, els navegadors Chromium ofereixen un sistema de fitxers privat d'origen (origin private file system o OPFS). Es tracta dun espai demmagatzematge dedicat a cada lloc web, no directament accessible per lusuari des del sistema operatiu.

A la pràctica, això significa que encara que internament el navegador emmagatzemi aquestes dades en disc, l'usuari no els trobarà com a fitxers “normals” en una carpeta qualsevol. Pot ser una base de dades, fitxers empaquetats o qualsevol estructura interna que el navegador consideri convenient.

Des de l'API podeu accedir a l'arrel d'aquest sistema privat mitjançant navigator.storage.getDirectory(), que torna un FileSystemDirectoryHandle. A partir d'aquí pots crear fitxers i directoris, llegir-los, escriure'ls, reanomenar-los o esborrar-los igual que si fossin elements del sistema de fitxers local, però sabent que estan aïllats i dedicats exclusivament a la teva aplicació web.

Per a necessitats de rendiment més avançat, Chromium incorpora un tipus especial de fitxer amb accés síncron optimitzat. A través d' fileHandle.createSyncAccessHandle() (disponible en workers), pots obtenir un handle que permet llegir i escriure de forma síncrona i en mode exclusiu, quelcom útil per a casos d'ús molt intensius o sensibles a la latència.

L'obtenció del handle segueix sent asíncrona, però un cop el tens, les operacions de lectura i escriptura es realitzen com a trucades directes, manipulant buffers de bytes. Això s'acosta molt al rendiment d'una aplicació nativa però sense abandonar l'entorn web i mantenint l'aïllament del sistema privat d'origen.

Polyfills i alternatives quan no hi ha suport nadiu

Tot i que l'API de File System Access ofereix moltes possibilitats, no tots els navegadors la suporten encara. No es pot fer un polyfill complet que reprodueixi totes les seves capacitats, principalment perquè no hi ha manera de simular de manera fiable l'accés nadiu al sistema de fitxers sense la cooperació del propi navegador.

Tot i això, es poden aproximar algunes parts. Per emular showOpenFilePicker() sol recórrer a un simple <input type="file">, que mostra el quadre de selecció de fitxers i permet a l'usuari triar un o diversos fitxers.

Una cosa semblant passa amb el desat. Per imitar showSaveFilePicker() s'usa moltes vegades un enllaç <a download="nombre"> que, en prémer-ho, inicia la descàrrega d'un Blob generat des de JavaScript. Això permet “guardar” dades generades per la web, encara que no ofereix l'opció de sobreescriure fitxers ja existents.

Quant a seleccionar directoris complets, s'ha fet servir tradicionalment l'atribut no estàndard webkitdirectory en <input type="file">, que permet triar una carpeta i rebre la llista de fitxers que conté. No és una solució universal ni tan potent com showDirectoryPicker(), però cobreix alguns casos.

Per unificar aquestes aproximacions, hi ha llibreries com browser-fs-access que intenten fer servir l'API moderna sempre que està disponible i, si no, recorren automàticament a aquestes millors alternatives. D'aquesta manera, el desenvolupador escriu un codi relativament uniforme i la biblioteca s'encarrega d'adaptar-se a l'entorn.

Seguretat, permisos i control de l'usuari

Tota aquesta potència comporta responsabilitats, i els equips de navegador en són molt conscients. El disseny de l'API del File System Access gira al voltant de dos principis: control de l'usuari i transparència. Res que una web pugui llegir mig disc dur d'amagat.

Quan l'usuari obre un fitxer mitjançant els quadres de selecció (ja sigui per llegir o per desar-ne un de nou), és aquest gest el que atorga el permís de lectura o escriptura sobre l'arxiu o la carpeta concreta. Si lusuari canvia didea i cancel·la el diàleg, la web no rep res i, per tant, no obté cap tipus daccés.

Per desar un fitxer nou, el quadre de “Guardar” no només permet triar nom i ruta, sinó que també serveix de concessió de permís d'escriptura sobre aquest fitxer acabat de crear. La lògica és la mateixa que s'ha utilitzat durant anys en elements com ara <input type="file">, però estesa amb més capacitats.

Quan una aplicació web vol modificar un fitxer que ja existia, no pot fer-ho sense més ni més; el navegador pot mostrar un avís específic demanant permís per escriure-hi. Aquest diàleg només es pot obrir en resposta a una acció de l'usuari, com ara prémer un botó “Desa els canvis”.

Si l'usuari decideix no concedir aquest permís d'escriptura, la web ha d'oferir alguna alternativa: descarregar una còpia, guardar al núvol, treballar a l'OPFS o un altre mecanisme similar. La idea és que l'usuari tingui sempre l'última paraula sobre què es toca al sistema local.

A nivell de transparència, els navegadors mostren una icona a la barra d'adreces quan una web té accés a fitxers locals. Si l'usuari fa clic en aquesta icona, veureu una llista dels fitxers o carpetes als quals la pàgina té accés en aquell moment i podrà revocar permisos quan vulgui.

Els permisos no són eterns. Generalment, una pàgina conserva la capacitat de continuar guardant fitxers només mentre hi hagi almenys una pestanya d'aquest origen oberta. Un cop es tanquen totes, el navegador pot considerar que s'acaba la sessió i, en el següent ús, caldrà tornar a demanar permís per a aquests fitxers o directoris.

Combinar l'esquema file:/// per obrir recursos puntuals, els dreceres de teclat per carregar fitxers locals i l'API de File System Access per a integracions profundes converteix el navegador en una eina molt més versàtil tant per a usuaris com per a desenvolupadors, permetent des de visualitzar ràpidament un vídeo desat al disc fins a editar projectes complets sense sortir de l'entorn web.