Summary

  • Am 17. November 2009 veröffentlichte das W3C den ersten öffentlichen Arbeitsentwurf der File API. Er beschrieb einzeln ausgewählte Dateien, FileList und das ereignisgesteuerte Lesen mit FileReader.
  • Die Entwürfe von 2013 und 2015 schärften Blob, asynchrones Lesen und Blob-URLs. Eine Vorschau im Browser und eine Übertragung zum Server waren zwei verschiedene Schritte.

Im Fotoladen legt eine Kundin einen Abzug auf den Tresen. Der Verkäufer betrachtet das Bild. Würde er stattdessen alle Schubladen ihrer Wohnung öffnen wollen, wäre das Gespräch rasch beendet. Webseiten standen vor einer ähnlichen Aufgabe. Sie sollten mit einer lokalen Datei arbeiten können, ohne selbst die Rolle des Suchtrupps im Dateisystem zu übernehmen. Der Browser musste aus der sichtbaren Entscheidung der Person ein brauchbares Stück Software machen.

Der erste öffentliche File-API-Entwurf vom 17. November 2009 setzte bei individuell ausgewählten Dateien an. Ein <input type="file"> konnte den Auswahldialog aufrufen. FileList repräsentierte das Ergebnis. File trug Angaben wie Name und Medientyp, Blob stand für rohe Daten und Ausschnitte daraus. FileReader las den Inhalt und meldete seinen Fortgang über Ereignisse. Die Seite erhielt ein benanntes Arbeitsobjekt, keinen Schlüssel zum restlichen Schrank.

Damit bekam der alte Upload-Knopf einen Vorraum. Ein Formular konnte eine Datei schon lange an einen Server schicken. Ob die Kundin das richtige Foto erwischt hatte, zeigte sich womöglich erst danach. Die File API erlaubte es der Seite, den gewählten Inhalt vorher zu lesen. Im Entwurf von 2009 standen dafür readAsBinaryString, readAsText und readAsDataURL als asynchrone Methoden. Ein Bild ließ sich vorzeigen, ein Text prüfen. Die Entscheidung zum Versand konnte warten, bis der Mensch den Gegenstand auf dem Tresen erkannt hatte.

Die Anwendungsfälle des Entwurfs waren bewusst alltäglich. Ein Liedtextprogramm konnte eine gewählte Wiedergabeliste öffnen und sortierbar machen. Ein Kalender konnte eine lokale Kalenderdatei lesen, Termine zusammenführen und erst anschließend eine Synchronisierung anbieten. Die Datei war mehr als Post für den Server. Sie wurde Material, mit dem eine Webanwendung am Gerät des Nutzers arbeiten konnte.

Der Auswahldialog war dabei kein kleines Dekorationsfenster. Der Sicherheitsabschnitt von 2009 ging davon aus, dass der Mensch die von FileReader gelesenen Dateien zuvor ausgewählt hatte. Er sprach von einer Webseite, die den Dialog in einer Endlosschleife öffnet, von sensiblen Systemdateien und von Änderungen an einer Datei zwischen Auswahl und Lesevorgang. Eine lokale Datei lebt außerhalb der Webseite. Sie kann verschwinden, sich ändern oder vom Browser zurückgehalten werden. Der Entwurf nahm diese Unordnung ernst.

Im Last-Call-Arbeitsentwurf vom 12. September 2013 wurden die Zuständigkeiten genauer. FileList enthielt die ausgewählten Objekte. Blob repräsentierte unveränderliche Rohdaten, aus denen sich Abschnitte schneiden ließen. File ergänzte unter anderem Namen und Änderungsdatum. FileReader lieferte asynchron Fortschritts-, Abschluss- und Fehlerereignisse. Das Beispiel las eine gewählte Datei als Text und aktualisierte einen Fortschrittsbalken. Bei einer langsamen Festplatte musste die Seite nicht mehr so tun, als sei sie plötzlich zum Mittagessen verschwunden.

Eine zweite Brücke führte zur URL, der Lieblingsform des Webs. Ein ausgewähltes Foto lag als lokales Objekt vor; ein Bildelement erwartete eine referenzierbare Adresse. Blob-URLs verbanden beides. Der Entwurf vom 21. April 2015 zeigte, wie URL.createObjectURL() eine Vorschau versorgen und URL.revokeObjectURL() die Referenz später wieder entfernen konnte. Er warnte davor, solche Referenzen liegenzulassen. Eine Abholmarke am Tresen ist nützlich, solange das Bild dort bearbeitet wird. Niemand sollte sie für eine dauerhafte öffentliche Anschrift halten.

Auch beim Dateinamen blieb der Entwurf maßvoll. File.name gab 2015 den Namen ohne den Pfad durch die übergeordneten Ordner zurück. Eine Seite kann „urlaub.jpg“ neben das Vorschaubild schreiben, ohne die Ordnerstruktur des Menschen zu erfahren. Der Text band Blob-URLs außerdem an ihren Ursprung und ließ Anfragen aus einem anderen Ursprung fehlschlagen. Die Anwendung sollte mit dem übergebenen Gegenstand arbeiten, nicht aus Nebeninformationen einen Grundriss des Rechners zeichnen.

Die Veröffentlichungsgeschichte des W3C verzeichnet den ersten öffentlichen File-API-Entwurf 2009, einen Last-Call-Entwurf 2013 und einen weiteren Arbeitsentwurf 2015. Es gab hier keinen Tag, an dem eine fertige Empfehlung das Web mit einem Schlag neu ordnete. Die praktische Vereinbarung wurde über Jahre präzisiert: Eine Person wählt eine Datei; der Browser gibt ihr eine gemeinsame Form; die Seite kann sie lesen.

Nach dem Lesen bleibt die Seite am Zug. Sie kann die Bytes lokal verarbeiten, eine Vorschau anzeigen oder sie über einen weiteren Webmechanismus an einen Server schicken. Die Vorschau allein beweist keine Übertragung, und die Auswahl beantwortet noch nicht, wo spätere Kopien landen. Gerade deshalb war die saubere erste Übergabe wertvoll. Sie machte den nächsten Schritt als Entscheidung der Anwendung erkennbar.

Eine falsche Fotodatei konnte noch vor dem Upload auffallen. Eine Kalenderdatei ließ sich prüfen, bevor jemand sie synchronisierte. Bei einem großen Dokument konnte die Seite ihren Fortschritt zeigen. Das sind keine Trompetenstöße der Technikgeschichte, sondern Verbesserungen an Millionen kleinen Übergaben. Der Verkäufer bekam das Foto auf den Tresen. Der Aktenschrank blieb bei seiner Besitzerin.