Jak działa lokalne przetwarzanie plików w przeglądarce
Skoro nic nie jest wysyłane, to co właściwie wykonuje pracę — i gdzie?
Co znaczy tu „lokalnie”
Typowy konwerter online to witryna z punktem odbioru plików. Twój plik zostaje przesłany na maszynę, nad którą nie masz kontroli, tam przetworzony, przez jakiś czas przechowywany i oddany z powrotem jako plik do pobrania. Przetwarzanie lokalne wycina środek tego zdania: kod, który czyta twój plik, działa w karcie przeglądarki, którą już masz otwartą, na twoim własnym procesorze, a wynik trafia z powrotem na twój własny dysk.
Sama witryna nadal jest pobierana przez sieć — HTML, arkusze stylów, skrypty i moduły WebAssembly przychodzą z serwera, jak w każdej stronie internetowej. Różnica polega na kierunku. Kod programu schodzi w dół, twój plik nie idzie w górę.
Przeglądarka ma już wszystkie części
| Funkcja | Co daje |
|---|---|
| API File i Blob | Odczyt bajtów pliku wybranego lub upuszczonego przez użytkownika, bez wysyłania formularza |
| Web Workers | Wykonanie ciężkiej pracy w wątku w tle, dzięki czemu interfejs pozostaje responsywny |
| WebAssembly | Uruchamianie skompilowanych bibliotek kodeków w C, C++ lub Rust z szybkością bliską natywnej |
| Canvas i OffscreenCanvas | Dekodowanie, rysowanie, skalowanie i ponowne kodowanie obrazów |
| WebCodecs | Dostęp do sprzętowo przyspieszanych koderów i dekoderów wideo samej przeglądarki |
| WebGPU | Uruchamianie inferencji modeli i równoległych operacji na pikselach na procesorze graficznym |
| File System Access | Zapis wyniku prosto w miejscu wskazanym przez użytkownika, tam gdzie jest obsługiwany |
Nic z tego nie jest egzotyczne. To ta sama platforma, na której w karcie przeglądarki działają arkusze kalkulacyjne, narzędzia projektowe i gry. Jedyną nietypową decyzją jest odmowa dołożenia do tego serwera.
Droga, którą przebywa plik
- Wybierasz plik. Przeglądarka przekazuje stronie uchwyt do niego — nie kopię, tylko referencję.
- Strona czyta pierwsze bajty, żeby rozpoznać prawdziwy typ pliku po jego sygnaturze, zamiast wierzyć rozszerzeniu.
- Szacuje, ile pamięci wymaga zadanie, i odmawia go albo kolejkuje, jeśli przekracza to, co urządzenie może bezpiecznie dać.
- Bajty zostają przekazane do wątku Web Worker. Przekazanie obiektu ArrayBuffer przenosi własność, zamiast kopiować dane, więc duży plik nie istnieje w pamięci dwa razy.
- Wewnątrz tego wątku właściwym dekodowaniem i kodowaniem zajmuje się kodek w WebAssembly albo API platformy.
- Wynik wraca jako bajty, zostaje opakowany w obiekt Blob i albo jest oferowany do pobrania, albo zapisany w miejscu, które wskażesz.
- Tymczasowy adres URL tego obiektu Blob zostaje unieważniony, a bufory zwolnione.
Dlaczego to WebAssembly wszystko zmieniło
Kodeki obrazu i wideo to dekady starannie optymalizowanego kodu w C. Przepisanie ich w JavaScripcie nigdy nie było realne. WebAssembly to przenośny binarny format instrukcji, który przeglądarki wykonują w piaskownicy z szybkością bliską kodowi natywnemu — dzięki temu istniejące biblioteki można skompilować i dostarczyć do przeglądarki w niezmienionej postaci.
Piaskownica ma tu takie samo znaczenie jak szybkość. Moduł WebAssembly nie ma domyślnego dostępu do twojego systemu plików, twojej sieci ani twoich pozostałych kart. Widzi pamięć, którą przekaże mu strona, i nic więcej. Złośliwy albo po prostu wadliwy kodek nie może pójść na wycieczkę i odczytać czegoś, czego mu nie dano.
Co nadal korzysta z sieci i dlaczego to nie twój plik
Przez sieć przychodzą trzy rzeczy: sama strona, silnik narzędzia, które otworzyłeś, oraz — przy usuwaniu tła — wagi modelu. Wszystkie trzy to statyczne zasoby serwisu FileSlimmer, pobierane z jego własnej domeny, zanim ktokolwiek odczyta choć jeden bajt twojego pliku. To zwykłe pobrania, które można zapisać w pamięci podręcznej, a po pierwszym użyciu przeglądarka serwuje je z niej całkowicie bez udziału sieci.
Wszystko po tym momencie dzieje się lokalnie. Silniki dostają bajty pliku wyłącznie przez postMessage ze strony; nigdy nie dostają adresu URL, pod który miałyby cokolwiek wysłać, a polityka Content-Security-Policy ogranicza to, dokąd strona mogłaby się połączyć, gdyby jakiś kod jednak spróbował.
Kompromisy, powiedziane wprost
| Kryterium | W twojej przeglądarce | Na serwerze |
|---|---|---|
| Dokąd trafia twój plik | Donikąd | Na maszynę, nad którą nie masz kontroli |
| Szybkość | Tyle, ile potrafi twoje urządzenie | Tyle, za ile zapłacił operator |
| Bardzo duże pliki | Ograniczone pamięcią przeglądarki | Ograniczone limitami operatora |
| Działa offline | Tak, gdy silnik jest już w pamięci podręcznej | Nie |
| Egzotyczne formaty | Tylko to, co kompiluje się do WebAssembly | Wszystko, co zainstaluje operator |
| Partia tysiąca plików | Ograniczona możliwościami urządzenia | Zwykle lepiej się nadaje |
Przetwarzanie lokalne nie jest lepsze zawsze i wszędzie. Jest lepsze, gdy plik jest prywatny, gdy urządzenie ma moc i gdy praca mieści się w pamięci. Serwer jest lepszy, gdy trzeba przetworzyć znacznie więcej, niż pomieści jedna maszyna. Jasność co do tego, w której sytuacji jesteś, przydaje się bardziej niż upieranie się, że jedno podejście wygrywa wszędzie.
Czego ten tekst nie twierdzi
To jest stwierdzenie o tym, co robi ta aplikacja. Nie jest to twierdzenie o twoich rozszerzeniach przeglądarki, które mogą czytać zawartość każdej otwartej strony, ani o twoim systemie operacyjnym, który może zajrzeć do każdego pliku, jakiego dotkniesz, ani o twoim operatorze sieci, który widzi, że odwiedziłeś daną witrynę. To rzeczy poza zasięgiem jakiejkolwiek strony internetowej, a narzędzie, które mówi ci inaczej, przesadza.
Twierdzenie jest wąskie i sprawdzalne: wybrane przez ciebie pliki są przetwarzane lokalnie w tej przeglądarce i FileSlimmer ich nigdzie nie wysyła. Następny poradnik pokazuje, jak sprawdzić to samodzielnie, zamiast brać na wiarę.
Narzędzia do tego zadania
Źródła
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs