Slik virker lokal filbehandling i en nettleser
Hvis ingenting lastes opp, hva er det som faktisk gjør jobben – og hvor?
Hva «lokal» betyr her
En vanlig konverterer på nett er et nettsted med et opplastingsendepunkt. Filen din overføres til en maskin du ikke kontrollerer, behandles der, lagres en periode og tilbys tilbake som en nedlasting. Lokal behandling fjerner midten av den setningen: koden som leser filen din, kjører inne i nettleserfanen du allerede har åpen, på din egen prosessor, og resultatet skrives tilbake til din egen disk.
Nettstedet hentes fortsatt over nettet – HTML, stilark, skript og WebAssembly-moduler kommer alle fra en server, som på en hvilken som helst nettside. Forskjellen ligger i retningen. Programkoden kommer ned; filen din går ikke opp.
Nettleseren inneholder allerede delene
| Funksjon | Hva den gir |
|---|---|
| File- og Blob-API-ene | Leser bytene i en fil brukeren har valgt eller sluppet, uten at et skjema sendes inn |
| Web Workers | Kjører tungt arbeid på en bakgrunnstråd, slik at grensesnittet fortsatt svarer |
| WebAssembly | Kjører kompilerte kodekbiblioteker i C, C++ eller Rust nesten like raskt som maskinkode |
| Canvas og OffscreenCanvas | Dekoder, tegner, skalerer og koder om bilder |
| WebCodecs | Gir tilgang til nettleserens egne maskinvareakselererte videokodere og -dekodere |
| WebGPU | Kjører modellinferens og parallelt pikselarbeid på grafikkprosessoren |
| File System Access | Skriver resultatet rett til et sted brukeren velger, der det støttes |
Ingenting av dette er eksotisk. Det er den samme plattformen som kjører regneark, designverktøy og spill i en fane. Den eneste uvanlige avgjørelsen er å nekte å legge en server til den.
Veien en fil tar
- Du velger en fil. Nettleseren gir siden et håndtak til den – ikke en kopi, en referanse.
- Siden leser de første bytene for å identifisere den virkelige filtypen fra signaturen, i stedet for å stole på filendelsen.
- Den anslår hvor mye minne jobben trenger, og avviser arbeidet eller legger det i kø hvis det overstiger det enheten trygt kan avse.
- Bytene overføres til en Web Worker. Å overføre en ArrayBuffer flytter eierskapet i stedet for å kopiere den, slik at en stor fil ikke finnes to ganger i minnet.
- Inne i workeren gjør en WebAssembly-kodek eller et plattform-API selve dekodingen og kodingen.
- Resultatet kommer tilbake som byte, pakkes inn i en Blob og tilbys deg som en nedlasting eller skrives til et sted du velger.
- Den midlertidige URL-en til den Blob-en trekkes tilbake, og bufferne frigjøres.
Hvorfor WebAssembly er delen som endret alt
Bilde- og videokodeker er flere tiår med nøye optimert C. Å skrive dem om i JavaScript var aldri realistisk. WebAssembly er et portabelt binært instruksjonsformat som nettlesere kjører i en sandkasse med hastighet nær maskinkode, og det betyr at de eksisterende bibliotekene kan kompileres og sendes til nettleseren som de er.
Sandkassen betyr like mye som hastigheten. En WebAssembly-modul har ingen tilgang til filsystemet ditt, nettverket ditt eller de andre fanene dine i utgangspunktet. Den ser minnet siden gir den, og ingenting annet. En ondsinnet – eller bare buggete – kodek kan ikke vandre av gårde og lese noe den ikke har fått.
Hva som fortsatt berører nettet, og hvorfor det ikke er filen din
Tre ting kommer over nettet: selve siden, motoren for verktøyet du åpnet, og – for bakgrunnsfjerning – modellvektene. Alle tre er FileSlimmers egne statiske ressurser, hentet fra FileSlimmers eget opphav før noen av bytene dine leses. Det er nedlastinger, de kan mellomlagres, og etter første gangs bruk kan de leveres fra nettleserens egen cache helt uten nett.
Alt etter det punktet er lokalt. Motorene får filbyte bare gjennom postMessage fra siden; de får aldri en URL å sende noe til, og en innholdssikkerhetspolicy begrenser hvor siden i det hele tatt kunne koblet seg til om noe kode skulle prøve.
Avveiningene, sagt rett ut
| Hensyn | I nettleseren din | På en server |
|---|---|---|
| Hvor filen din havner | Ingen steder | På en maskin du ikke kontrollerer |
| Hastighet | Det enheten din klarer | Det operatøren har betalt for |
| Svært store filer | Begrenset av nettleserens minne | Begrenset av operatørens grenser |
| Virker uten nett | Ja, når motoren er lagt i cache | Nei |
| Eksotiske formater | Bare det som lar seg kompilere til WebAssembly | Alt operatøren installerer |
| En bunke på tusen filer | Begrenset av enheten | Vanligvis bedre egnet |
Lokal behandling er ikke bedre over hele linjen. Den er bedre når filen er privat, når enheten er kraftig nok, og når arbeidet får plass i minnet. En server er bedre når du må behandle langt mer enn én maskin kan romme. Å være tydelig på hvilken situasjon du er i, er mer nyttig enn å insistere på at én tilnærming vinner overalt.
Hva dette ikke påstår
Dette er en påstand om hva denne applikasjonen gjør. Det er ikke en påstand om nettleserutvidelsene dine, som kan lese innholdet på enhver side du åpner, heller ikke om operativsystemet ditt, som kan inspisere enhver fil du er borti, og heller ikke om nettleverandøren din, som kan se at du besøkte et nettsted. Det ligger utenfor rekkevidden til ethvert nettsted, og et verktøy som forteller deg noe annet, overdriver.
Påstanden er smal og etterprøvbar: filene du velger, behandles lokalt i denne nettleseren og lastes ikke opp av FileSlimmer. Den neste guiden forklarer hvordan du kontrollerer det selv i stedet for å tro på det.
Verktøy for dette
Kilder
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs