Wie lokale Dateiverarbeitung im Browser funktioniert
Wenn nichts hochgeladen wird: Was macht dann die Arbeit, und wo?
Was „lokal“ hier bedeutet
Ein herkömmlicher Online-Konverter ist eine Website mit einem Upload-Endpunkt. Ihre Datei wird an einen Rechner übertragen, über den Sie keine Kontrolle haben, dort verarbeitet, eine Zeit lang gespeichert und Ihnen als Download zurückgereicht. Lokale Verarbeitung streicht die Mitte dieses Satzes: Der Code, der Ihre Datei liest, läuft in dem Browser-Tab, den Sie ohnehin schon geöffnet haben, auf Ihrem eigenen Prozessor, und das Ergebnis wird zurück auf Ihre eigene Festplatte geschrieben.
Die Website selbst wird weiterhin über das Netzwerk geladen – HTML, Stylesheets, Skripte und WebAssembly-Module kommen alle von einem Server, wie bei jeder Webseite. Der Unterschied liegt in der Richtung. Programmcode kommt herunter; Ihre Datei geht nicht hinauf.
Der Browser bringt die Bausteine schon mit
| Funktion | Was sie beisteuert |
|---|---|
| File- und Blob-APIs | Die Bytes einer Datei lesen, die jemand ausgewählt oder hineingezogen hat, ohne Formularübertragung |
| Web Worker | Schwere Arbeit in einem Hintergrund-Thread ausführen, damit die Oberfläche bedienbar bleibt |
| WebAssembly | Kompilierte Codec-Bibliotheken in C, C++ oder Rust nahezu mit nativer Geschwindigkeit ausführen |
| Canvas und OffscreenCanvas | Bilder decodieren, zeichnen, skalieren und neu codieren |
| WebCodecs | Auf die hardwarebeschleunigten Video-Encoder und -Decoder des Browsers zugreifen |
| WebGPU | Modellinferenz und parallele Pixelarbeit auf dem Grafikprozessor ausführen |
| File System Access | Das Ergebnis direkt an einen selbst gewählten Ort schreiben, wo das unterstützt wird |
Nichts davon ist exotisch. Es ist dieselbe Plattform, auf der Tabellenkalkulationen, Designwerkzeuge und Spiele in einem Tab laufen. Die einzige ungewöhnliche Entscheidung besteht darin, keinen Server hinzuzufügen.
Der Weg, den eine Datei nimmt
- Sie wählen eine Datei aus. Der Browser übergibt der Seite ein Handle darauf – keine Kopie, eine Referenz.
- Die Seite liest die ersten Bytes, um den tatsächlichen Dateityp anhand der Signatur zu bestimmen, statt der Endung zu vertrauen.
- Sie schätzt, wie viel Arbeitsspeicher die Aufgabe braucht, und lehnt die Arbeit ab oder stellt sie in eine Warteschlange, wenn das über dem liegt, was das Gerät gefahrlos bereitstellen kann.
- Die Bytes werden in einen Web Worker übertragen. Beim Übertragen eines ArrayBuffer wechselt der Besitz, statt dass kopiert wird – eine große Datei liegt also nicht zweimal im Arbeitsspeicher.
- Im Worker erledigt ein WebAssembly-Codec oder eine Plattform-API das eigentliche Decodieren und Codieren.
- Das Ergebnis kommt als Bytes zurück, wird in einen Blob verpackt und Ihnen als Download angeboten oder an einen Ort geschrieben, den Sie wählen.
- Die temporäre URL für diesen Blob wird zurückgezogen und die Puffer werden freigegeben.
Warum WebAssembly der Teil ist, der alles verändert hat
Bild- und Videocodecs sind Jahrzehnte sorgfältig optimierten C-Codes. Sie in JavaScript neu zu schreiben war nie realistisch. WebAssembly ist ein portables binäres Befehlsformat, das Browser in einer Sandbox nahezu mit der Geschwindigkeit nativen Codes ausführen – diese vorhandenen Bibliotheken lassen sich also so, wie sie sind, kompilieren und an den Browser ausliefern.
Die Sandbox zählt genauso viel wie die Geschwindigkeit. Ein WebAssembly-Modul hat keinen beiläufigen Zugriff auf Ihr Dateisystem, Ihr Netzwerk oder Ihre anderen Tabs. Es sieht den Speicher, den die Seite ihm übergibt, und sonst nichts. Ein bösartiger oder schlicht fehlerhafter Codec kann nicht davonspazieren und etwas lesen, was ihm nicht übergeben wurde.
Was noch das Netzwerk berührt, und warum es nicht Ihre Datei ist
Drei Dinge kommen über das Netzwerk: die Seite selbst, die Engine für das Werkzeug, das Sie geöffnet haben, und – beim Freistellen von Hintergründen – die Modellgewichte. Alle drei sind statische Dateien von FileSlimmer selbst, abgerufen vom eigenen Origin von FileSlimmer, bevor auch nur ein Byte von Ihnen gelesen wird. Es sind Downloads, sie sind zwischenspeicherbar, und ab der zweiten Nutzung können sie ganz ohne Netzwerk aus dem Cache des Browsers kommen.
Alles ab diesem Punkt ist lokal. Die Engines erhalten Dateibytes ausschließlich per postMessage von der Seite; sie bekommen nie eine URL, an die sie etwas schicken könnten, und eine Content Security Policy schränkt ein, wohin die Seite überhaupt eine Verbindung aufbauen dürfte, selbst wenn irgendein Code es versuchen würde.
Die Abwägungen, klar benannt
| Gesichtspunkt | In Ihrem Browser | Auf einem Server |
|---|---|---|
| Wohin Ihre Datei geht | Nirgendwohin | Auf einen Rechner, über den Sie keine Kontrolle haben |
| Geschwindigkeit | Was Ihr Gerät hergibt | Was der Betreiber bezahlt hat |
| Sehr große Dateien | Begrenzt durch den Speicher des Browsers | Begrenzt durch die Limits des Betreibers |
| Funktioniert offline | Sobald die Engine im Cache liegt, ja | Nein |
| Exotische Formate | Nur, was sich nach WebAssembly kompilieren lässt | Alles, was der Betreiber installiert |
| Stapel von tausend Dateien | Vom Gerät eingeschränkt | Meist besser geeignet |
Lokale Verarbeitung ist nicht pauschal besser. Sie ist besser, wenn die Datei privat ist, wenn das Gerät leistungsfähig genug ist und wenn die Arbeit in den Speicher passt. Ein Server ist besser, wenn Sie weit mehr verarbeiten müssen, als ein einzelner Rechner fassen kann. Sich klarzumachen, in welcher Lage man gerade ist, hilft mehr, als darauf zu beharren, dass ein Ansatz überall gewinnt.
Was hier nicht behauptet wird
Das ist eine Aussage darüber, was diese Anwendung tut. Es ist keine Aussage über Ihre Browser-Erweiterungen, die den Inhalt jeder Seite lesen können, die Sie öffnen, auch keine über Ihr Betriebssystem, das jede Datei einsehen kann, die Sie anfassen, und keine über Ihren Netzbetreiber, der sehen kann, dass Sie eine Website besucht haben. Das alles liegt außerhalb der Reichweite jeder Website, und ein Werkzeug, das Ihnen etwas anderes erzählt, übertreibt.
Die Behauptung ist eng und überprüfbar: Ihre ausgewählten Dateien werden lokal in diesem Browser verarbeitet und von FileSlimmer nicht hochgeladen. Der nächste Ratgeber erklärt, wie Sie das selbst nachprüfen, statt es zu glauben.
Passende Tools
Quellen
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs