Så fungerar lokal filbehandling i webbläsaren
Om ingenting laddas upp, vad är det då som gör jobbet — och var?
Vad ”lokalt” betyder här
En vanlig konverterare på nätet är en webbplats med en uppladdningsslutpunkt. Din fil skickas till en maskin du inte kontrollerar, bearbetas där, lagras en tid och erbjuds tillbaka som en nedladdning. Lokal bearbetning tar bort mitten av den meningen: koden som läser din fil körs i webbläsarfliken du redan har öppen, på din egen processor, och resultatet skrivs tillbaka till din egen disk.
Själva webbplatsen hämtas fortfarande över nätverket — HTML, stilmallar, skript och WebAssembly-moduler kommer alla från en server, precis som på vilken webbsida som helst. Skillnaden ligger i riktningen. Programkoden kommer ned; din fil går inte upp.
Webbläsaren innehåller redan delarna
| Funktion | Vad den ger |
|---|---|
| File- och Blob-API:er | Läser byten i en fil som användaren har valt eller släppt, utan att skicka ett formulär |
| Web Workers | Kör tungt arbete på en bakgrundstråd så att gränssnittet fortsätter svara |
| WebAssembly | Kör kompilerade codec-bibliotek i C, C++ eller Rust i nästan inbyggd hastighet |
| Canvas och OffscreenCanvas | Avkodar, ritar, skalar om och kodar om bilder |
| WebCodecs | Når webbläsarens egna hårdvaruaccelererade videokodare och videoavkodare |
| WebGPU | Kör modellinferens och parallellt pixelarbete på grafikprocessorn |
| File System Access | Skriver resultatet direkt till en plats användaren väljer, där det stöds |
Ingenting av det här är exotiskt. Det är samma plattform som kör kalkylblad, designverktyg och spel i en flik. Det enda ovanliga beslutet är att vägra lägga till en server.
Vägen en fil tar
- Du väljer en fil. Webbläsaren ger sidan ett handtag till den — inte en kopia, utan en referens.
- Sidan läser de första byten för att identifiera den verkliga filtypen utifrån dess signatur, i stället för att lita på filändelsen.
- Den uppskattar hur mycket minne jobbet kräver, och avvisar eller köar arbetet om det överstiger vad enheten tryggt kan ge.
- Byten överförs till en Web Worker. Att överföra en ArrayBuffer flyttar ägandet i stället för att kopiera den, så en stor fil finns inte i två exemplar i minnet.
- Inne i workern gör en WebAssembly-codec eller ett plattforms-API själva avkodningen och kodningen.
- Resultatet kommer tillbaka som byte, packas i en Blob och erbjuds dig som en nedladdning eller skrivs till en plats du väljer.
- Den tillfälliga URL:en för den Blob:en återkallas och buffertarna frigörs.
Varför WebAssembly är det som förändrade saken
Bild- och videocodecar är decennier av noggrant optimerad C. Att skriva om dem i JavaScript var aldrig realistiskt. WebAssembly är ett portabelt binärt instruktionsformat som webbläsare kör i en sandlåda i hastigheter nära inbyggd kod, vilket innebär att de befintliga biblioteken kan kompileras och levereras till webbläsaren som de är.
Sandlådan spelar lika stor roll som hastigheten. En WebAssembly-modul har ingen fri tillgång till ditt filsystem, ditt nätverk eller dina andra flikar. Den ser det minne sidan ger den och ingenting annat. En skadlig eller helt enkelt buggig codec kan inte irra iväg och läsa något den inte har fått.
Vad som ändå rör nätverket, och varför det inte är din fil
Tre saker kommer över nätverket: sidan själv, motorn för verktyget du öppnade och — för bakgrundsborttagning — modellvikterna. Alla tre är FileSlimmers egna statiska resurser, hämtade från FileSlimmers eget ursprung innan någon av dina byte läses. De är nedladdningar, de går att cacha, och efter första användningen kan de levereras från webbläsarens egen cache helt utan nätverk.
Allt efter den punkten är lokalt. Motorerna får filbyte enbart via postMessage från sidan; de får aldrig någon URL att skicka något till, och en content security policy begränsar var sidan över huvud taget skulle kunna ansluta även om någon kod försökte.
Avvägningarna, rakt sagt
| Aspekt | I din webbläsare | På en server |
|---|---|---|
| Vart din fil tar vägen | Ingenstans | Till en maskin du inte kontrollerar |
| Hastighet | Vad din enhet klarar | Vad operatören har betalat för |
| Mycket stora filer | Begränsas av webbläsarens minne | Begränsas av operatörens gränser |
| Fungerar offline | Ja, när motorn väl är cachad | Nej |
| Exotiska format | Bara det som går att kompilera till WebAssembly | Allt operatören installerar |
| Batch med tusen filer | Begränsas av enheten | Oftast bättre lämpat |
Lokal bearbetning är inte bättre överallt. Den är bättre när filen är privat, när enheten klarar jobbet och när arbetet får plats i minnet. En server är bättre när du behöver bearbeta långt mer än en maskin rymmer. Att vara tydlig med vilken situation du befinner dig i är mer användbart än att hävda att det ena vinner i alla lägen.
Vad det här inte påstår
Det här är ett påstående om vad den här applikationen gör. Det är inte ett påstående om dina webbläsartillägg, som kan läsa innehållet på varje sida du öppnar, inte heller om ditt operativsystem, som kan granska varje fil du rör, och inte heller om din nätverksoperatör, som kan se att du besökt en webbplats. De ligger utanför räckhåll för vilken webbplats som helst, och ett verktyg som säger något annat överdriver.
Påståendet är smalt och kontrollerbart: dina valda filer bearbetas lokalt i den här webbläsaren och laddas inte upp av FileSlimmer. Nästa guide förklarar hur du verifierar det själv i stället för att tro på det.
Verktyg för det här
Källor
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs