Jak funguje lokální zpracování souborů v prohlížeči
Když se nic nenahrává, co tu práci vlastně dělá — a kde?
Co tady znamená „lokální“
Běžný online konvertor je web s koncovým bodem pro nahrávání. Váš soubor se přenese na stroj, který neovládáte, tam se zpracuje, nějakou dobu se uloží a nabídne se vám zpátky ke stažení. Lokální zpracování z té věty odstraní prostřední část: kód, který čte váš soubor, běží uvnitř karty prohlížeče, kterou už máte otevřenou, na vašem vlastním procesoru, a výsledek se zapíše zpátky na váš vlastní disk.
Web se pořád stahuje po síti — HTML, styly, skripty i moduly WebAssembly přicházejí ze serveru jako u každé jiné stránky. Rozdíl je ve směru. Programový kód jde dolů; váš soubor nejde nahoru.
Prohlížeč už ty součástky obsahuje
| Funkce | Co poskytuje |
|---|---|
| File a Blob API | Čtení bajtů souboru, který uživatel vybral nebo přetáhl, bez odesílání formuláře |
| Web Workers | Běh náročné práce ve vlákně na pozadí, aby rozhraní zůstalo responzivní |
| WebAssembly | Běh zkompilovaných kodekových knihoven v C, C++ nebo Rustu skoro nativní rychlostí |
| Canvas a OffscreenCanvas | Dekódování, kreslení, změna velikosti a nové zakódování obrázků |
| WebCodecs | Přístup k hardwarově akcelerovaným video kodérům a dekodérům samotného prohlížeče |
| WebGPU | Běh inference modelů a paralelní práce s pixely na grafickém procesoru |
| File System Access | Zápis výsledku rovnou do místa, které uživatel zvolí, kde je to podporováno |
Nic z toho není exotické. Je to tatáž platforma, na které v kartě běží tabulkové procesory, návrhářské nástroje i hry. Jediné neobvyklé rozhodnutí je odmítnout k tomu přidat server.
Cesta, kterou soubor urazí
- Vyberete soubor. Prohlížeč stránce předá odkaz na něj — ne kopii, ale referenci.
- Stránka přečte první bajty a podle signatury určí skutečný typ souboru, místo aby věřila příponě.
- Odhadne, kolik paměti úloha potřebuje, a pokud to překračuje to, co zařízení bezpečně zvládne, práci odmítne nebo zařadí do fronty.
- Bajty se předají do Web Workeru. Předání ArrayBufferu přesouvá vlastnictví místo kopírování, takže velký soubor neexistuje v paměti dvakrát.
- Uvnitř workeru provede vlastní dekódování a kódování kodek ve WebAssembly nebo API platformy.
- Výsledek se vrátí jako bajty, zabalí se do Blobu a nabídne se vám ke stažení nebo se zapíše do místa, které zvolíte.
- Dočasné URL toho Blobu se zruší a vyrovnávací paměti se uvolní.
Proč je WebAssembly tou částí, která to změnila
Obrazové a video kodeky jsou desetiletí pečlivě optimalizovaného céčka. Přepsat je do JavaScriptu nikdy nebylo reálné. WebAssembly je přenositelný binární instrukční formát, který prohlížeče vykonávají v sandboxu rychlostí blízkou nativnímu kódu, což znamená, že ty existující knihovny se dají zkompilovat a poslat do prohlížeče tak, jak jsou.
Sandbox je stejně důležitý jako rychlost. Modul WebAssembly nemá žádný samozřejmý přístup k vašemu souborovému systému, k vaší síti ani k vašim ostatním kartám. Vidí jen paměť, kterou mu stránka předá, a nic jiného. Škodlivý nebo prostě chybný kodek se nemůže zatoulat jinam a přečíst něco, co mu dáno nebylo.
Co se sítě ještě dotýká a proč to není váš soubor
Po síti přicházejí tři věci: samotná stránka, engine nástroje, který jste otevřeli, a — u odstraňování pozadí — váhy modelu. Všechny tři jsou vlastní statické soubory FileSlimmeru, stahované z vlastního originu FileSlimmeru dřív, než se přečte jediný váš bajt. Jsou to stahování, dají se ukládat do mezipaměti a po prvním použití je může prohlížeč obsloužit z vlastní cache úplně bez sítě.
Všechno od toho okamžiku dál je lokální. Enginy dostávají bajty souboru výhradně přes postMessage ze stránky; nikdy nedostanou URL, kam by cokoli poslaly, a content security policy omezuje, kam by se stránka vůbec mohla připojit, i kdyby se o to nějaký kód pokusil.
Kompromisy, řečeno na rovinu
| Hledisko | Ve vašem prohlížeči | Na serveru |
|---|---|---|
| Kam se váš soubor dostane | Nikam | Na stroj, který neovládáte |
| Rychlost | Taková, jakou zvládne vaše zařízení | Taková, jakou si provozovatel zaplatil |
| Velmi velké soubory | Omezeny pamětí prohlížeče | Omezeny limity provozovatele |
| Funguje offline | Jakmile je engine v mezipaměti, ano | Ne |
| Exotické formáty | Jen to, co se dá zkompilovat do WebAssembly | Cokoli, co si provozovatel nainstaluje |
| Dávka tisíce souborů | Omezená zařízením | Obvykle vhodnější |
Lokální zpracování není lepší vždycky a všude. Je lepší, když je soubor soukromý, když zařízení stačí a když se práce vejde do paměti. Server je lepší, když potřebujete zpracovat mnohem víc, než jeden stroj unese. Mít jasno v tom, ve které z těch situací jste, je užitečnější než trvat na tom, že jeden přístup vítězí všude.
Co se tady netvrdí
Tohle je výrok o tom, co dělá tato aplikace. Není to tvrzení o vašich rozšířeních prohlížeče, která umějí číst obsah libovolné stránky, kterou otevřete, ani o vašem operačním systému, který si může prohlédnout každý soubor, jehož se dotknete, ani o vašem poskytovateli připojení, který vidí, že jste web navštívili. To všechno leží mimo dosah jakéhokoli webu a nástroj, který vám tvrdí něco jiného, přehání.
To tvrzení je úzké a ověřitelné: vaše vybrané soubory se zpracovávají lokálně v tomto prohlížeči a FileSlimmer je nikam nenahrává. Následující průvodce vysvětluje, jak si to místo věření sami ověřit.
Nástroje k tomuto tématu
Zdroje
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs