Sådan virker lokal filbehandling i en browser
Hvis intet bliver uploadet, hvad er det så, der udfører arbejdet — og hvor?
Hvad "lokal" betyder her
En almindelig onlinekonvertering er et website med et uploadendepunkt. Din fil sendes til en maskine, du ikke har kontrol over, behandles der, gemmes i et stykke tid og tilbydes tilbage som en download. Lokal behandling fjerner midten af den sætning: den kode, der læser din fil, kører inde i den browserfane, du allerede har åben, på din egen processor, og resultatet skrives tilbage til din egen disk.
Selve siden hentes stadig over netværket — HTML, stilark, scripts og WebAssembly-moduler kommer alle fra en server, ligesom på enhver anden webside. Forskellen er retningen. Programkoden kommer ned; din fil går ikke op.
Browseren indeholder allerede delene
| Funktion | Hvad den giver |
|---|---|
| File- og Blob-API'er | Læser bytesene i en fil, brugeren har valgt eller trukket ind, uden at sende en formular |
| Web Workers | Kører det tunge arbejde på en baggrundstråd, så brugerfladen bliver ved med at reagere |
| WebAssembly | Kører kompilerede codec-biblioteker i C, C++ eller Rust med næsten samme hastighed som lokal kode |
| Canvas og OffscreenCanvas | Afkoder, tegner, skalerer og omkoder billeder |
| WebCodecs | Giver adgang til browserens egne hardwareaccelererede videoencodere og -dekodere |
| WebGPU | Kører modelinferens og parallelt pixelarbejde på grafikprocessoren |
| File System Access | Skriver resultatet direkte til et sted, brugeren vælger, hvor det understøttes |
Intet af det er eksotisk. Det er den samme platform, der kører regneark, designværktøjer og spil i en fane. Den eneste usædvanlige beslutning er at nægte at sætte en server til.
Den vej en fil tager
- Du vælger en fil. Browseren giver siden et håndtag til den — ikke en kopi, en reference.
- Siden læser de første bytes for at identificere den reelle filtype ud fra dens signatur frem for at stole på filendelsen.
- Den vurderer, hvor meget hukommelse opgaven kræver, og afviser eller sætter arbejdet i kø, hvis det overstiger, hvad enheden forsvarligt kan levere.
- Bytesene overføres ind i en Web Worker. Overførsel af en ArrayBuffer flytter ejerskabet frem for at kopiere det, så en stor fil ikke findes to gange i hukommelsen.
- Inde i workeren udfører et WebAssembly-codec eller et platforms-API den egentlige afkodning og kodning.
- Resultatet kommer tilbage som bytes, pakkes ind i en Blob og tilbydes dig som en download eller skrives til et sted, du vælger.
- Den midlertidige URL til den Blob tilbagekaldes, og bufferne frigives.
Hvorfor WebAssembly er den del, der ændrede noget
Billed- og videocodecs er årtiers omhyggeligt optimeret C. At skrive dem om i JavaScript var aldrig realistisk. WebAssembly er et bærbart binært instruktionsformat, som browsere afvikler i en sandkasse med en hastighed tæt på lokal kode, og det betyder, at de eksisterende biblioteker kan kompileres og leveres til browseren, som de er.
Sandkassen betyder lige så meget som hastigheden. Et WebAssembly-modul har ingen adgang til dit filsystem, dit netværk eller dine andre faner. Det ser den hukommelse, siden giver det, og intet andet. Et ondsindet eller bare fejlbehæftet codec kan ikke vandre af sted og læse noget, det ikke fik udleveret.
Hvad der stadig rører netværket, og hvorfor det ikke er din fil
Tre ting kommer over netværket: selve siden, motoren til det værktøj, du åbnede, og — til fjernelse af baggrunde — modellens vægte. Alle tre er FileSlimmers egne statiske filer, hentet fra FileSlimmers eget domæne, før nogen af dine bytes bliver læst. De er downloads, de kan caches, og efter første brug kan de leveres fra browserens egen cache helt uden netværk.
Alt efter det punkt er lokalt. Motorerne modtager kun filbytes gennem postMessage fra siden; de får aldrig en URL at sende noget til, og en content security policy begrænser, hvor siden overhovedet kunne forbinde til, selv hvis noget kode prøvede.
Afvejningerne, sagt ligeud
| Forhold | I din browser | På en server |
|---|---|---|
| Hvor din fil havner | Ingen steder | På en maskine du ikke har kontrol over |
| Hastighed | Hvad din enhed nu kan | Hvad udbyderen har betalt for |
| Meget store filer | Begrænset af browserens hukommelse | Begrænset af udbyderens grænser |
| Virker offline | Ja, når motoren er cachet | Nej |
| Eksotiske formater | Kun det der kan kompileres til WebAssembly | Alt hvad udbyderen installerer |
| En bunke på tusind filer | Begrænset af enheden | Normalt bedre egnet |
Lokal behandling er ikke bedre i alle tilfælde. Den er bedre, når filen er privat, når enheden er kraftig nok, og når arbejdet kan være i hukommelsen. En server er bedre, når du skal behandle langt mere, end én maskine kan rumme. At være klar over, hvilken situation du er i, er mere nyttigt end at insistere på, at den ene tilgang vinder overalt.
Hvad dette ikke påstår
Det her er en udtalelse om, hvad denne applikation gør. Det er ikke en påstand om dine browserudvidelser, som kan læse indholdet af enhver side, du åbner, eller om dit styresystem, som kan undersøge enhver fil, du rører ved, eller om din netværksudbyder, som kan se, at du har besøgt et site. De ting ligger uden for ethvert websteds rækkevidde, og et værktøj, der siger andet, overdriver.
Påstanden er snæver og kan efterprøves: de filer, du vælger, behandles lokalt i denne browser og bliver ikke uploadet af FileSlimmer. Den næste guide forklarer, hvordan du selv kontrollerer det i stedet for at tro på det.
Værktøjer til dette
Kilder
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs