Summary

  • Le premier projet public de File API, publié par le W3C le 17 novembre 2009, décrivait les fichiers sélectionnés par l’utilisateur comme des objets lisibles par un script, notamment au moyen de FileReader.
  • Les projets de 2013 et 2015 ont précisé FileList, Blob, la lecture asynchrone et les URL de blob. Examiner une photo dans la page et l’expédier à un serveur restaient deux gestes distincts.

Imaginez un photographe amateur qui apporte un tirage au comptoir. L’employé demande à voir l’image. Il reçoit une photo, pas l’adresse du domicile, l’inventaire des placards et la clef de l’armoire à archives. Le navigateur avait besoin d’une règle du même ordre : une page web devait pouvoir travailler sur le fichier choisi sans transformer cette sélection en visite guidée du disque dur.

Le premier projet public de File API, daté du 17 novembre 2009, partait des fichiers sélectionnés individuellement. FileList en dressait la liste ; un champ <input type="file"> pouvait déclencher le choix. Un objet File apportait le nom et le type du fichier, tandis que Blob représentait ses octets et des portions de ces octets. FileReader permettait à un script de lire le contenu et d’en suivre le déroulement grâce à des événements. L’objet remis à la page avait donc une forme que tous les sites pouvaient comprendre.

Cela changeait l’histoire du bouton « envoyer ». Un formulaire traditionnel pouvait transmettre le fichier au serveur pour qu’on découvre ensuite si c’était le bon. Avec un objet accessible dans la page, on pouvait d’abord montrer la photo choisie, analyser un texte ou préparer une transformation. Le projet de 2009 proposait readAsBinaryString, readAsText et readAsDataURL comme méthodes de lecture asynchrone. Les trois noms racontaient déjà une ambition plus large qu’un colis postal : la page pouvait regarder ce qu’on lui avait remis avant de l’expédier.

Les cas d’usage du texte de 2009 ne s’arrêtaient pas aux photos. Un lecteur de paroles pouvait ouvrir un fichier de liste musicale, le parcourir et le trier dans l’application. Un agenda pouvait lire un calendrier local, rapprocher des rendez-vous et proposer ensuite une synchronisation. Dans ces exemples, le fichier devient une matière de travail. L’envoi au serveur est une possibilité ultérieure, décidée par l’application, et non la définition de l’acte de choisir.

Cette souplesse rendait la sélection précieuse. Le chapitre consacré à la sécurité dans le projet de 2009 supposait que les fichiers lus avaient d’abord été choisis par la personne. Il envisageait un sélecteur qui harcèle l’utilisateur jusqu’à obtenir un choix, des fichiers sensibles du système à tenir hors de portée et un document modifié sur le disque entre la sélection et la lecture. On aperçoit là le monde réel derrière une jolie interface : le fichier local bouge, peut être interdit de lecture et appartient à quelqu’un qui doit pouvoir arrêter l’opération.

Le projet en dernière phase d’appel à commentaires du 12 septembre 2013 répartissait mieux les fonctions. FileList regroupait les objets sélectionnés ; Blob contenait des données brutes immuables et pouvait être découpé ; File ajoutait notamment un nom et une date de modification. FileReader lisait de façon asynchrone et déclenchait des événements de progression, de réussite ou d’erreur. L’exemple du texte montrait un fichier choisi, lu comme du texte, avec une barre de progression. Le navigateur cessait de jouer au guichetier muet pendant la lecture d’un gros document.

Un autre problème attendait au comptoir : le Web aime les URL, mais la photo que l’on vient de choisir est un objet local. Les projets ont décrit des URL de blob pour relier les deux mondes. Dans le projet du 21 avril 2015, URL.createObjectURL() pouvait fournir une référence à une image choisie ; URL.revokeObjectURL() servait à retirer cette référence après usage. Le texte avertissait qu’oublier de la révoquer pouvait laisser traîner des références. Une prévisualisation avait une durée de vie à gérer, comme le tirage posé sur le comptoir qu’il faut reprendre ensuite.

Le même projet précisait un détail presque comique tant il est raisonnable : le nom exposé par File était le nom du fichier, sans le chemin des répertoires. Pour afficher « vacances.jpg » près de l’aperçu, la page n’avait aucune raison de connaître toute l’arborescence qui menait au dossier. Le projet de 2015 liait également les URL de blob à une origine et faisait échouer les demandes d’une autre origine. Ces choix donnaient une portée concrète à l’objet partagé.

La chronologie officielle du W3C situe le premier projet public en 2009, le texte de 2013 en Last Call et celui de 2015 parmi les Working Drafts. Elle ne raconte pas l’avènement soudain d’un Web qui aurait tout compris aux fichiers. Elle montre des règles affinées pour rendre un geste déjà familier plus utile : choisir un élément, le donner au navigateur, puis permettre à une page de travailler dessus.

Au bout du compte, le photographe peut voir son image, constater que ce n’est pas la bonne, et en choisir une autre avant qu’un serveur ne reçoive quoi que ce soit. Un calendrier peut être relu dans la page. Un fichier trop gros peut afficher sa progression plutôt que figer l’écran. Le classeur n’a pas disparu ; c’est le passage d’une seule pièce au comptoir qui a gagné une forme claire. Voilà une innovation moins spectaculaire qu’un grand portail, et beaucoup plus utile à la personne qui tient la photo.