Як працює локальна обробка файлів у браузері
Якщо нічого не надсилається на сервер, то що і де тоді виконує роботу?
Що тут означає «локально»
Звичайний онлайн-конвертер — це сайт із точкою прийому файлів. Ваш файл передається на машину, яку ви не контролюєте, обробляється там, певний час зберігається і повертається як завантаження. Локальна обробка викидає середину цього речення: код, який читає ваш файл, працює у вже відкритій вкладці браузера, на вашому власному процесорі, а результат записується назад на ваш власний диск.
Сам сайт усе одно приходить із мережі — HTML, стилі, скрипти та модулі WebAssembly надходять із сервера, як і в будь-якої вебсторінки. Різниця в напрямку. Програмний код спускається вниз; ваш файл нагору не йде.
У браузері вже є всі потрібні деталі
| Можливість | Що вона дає |
|---|---|
| File і Blob API | Читання байтів файлу, який користувач вибрав або перетягнув, без надсилання форми |
| Web Workers | Виконання важкої роботи у фоновому потоці, щоб інтерфейс лишався чутливим |
| WebAssembly | Запуск скомпільованих кодекових бібліотек на C, C++ чи Rust зі швидкістю, близькою до нативної |
| Canvas і OffscreenCanvas | Декодування, малювання, зміна розміру та перекодування зображень |
| WebCodecs | Доступ до власних апаратно прискорених відеокодерів і декодерів браузера |
| WebGPU | Виконання інференсу моделей і паралельної роботи з пікселями на графічному процесорі |
| File System Access | Запис результату одразу в місце, яке вибрав користувач, там, де це підтримується |
Нічого екзотичного тут немає. Це та сама платформа, що крутить у вкладці таблиці, дизайнерські редактори та ігри. Незвичне тут одне рішення — відмова додавати до неї сервер.
Шлях, який проходить файл
- Ви вибираєте файл. Браузер передає сторінці дескриптор — не копію, а посилання.
- Сторінка читає перші байти, щоб визначити справжній тип файлу за його сигнатурою, а не довіряти розширенню.
- Вона оцінює, скільки пам'яті потребує завдання, і відмовляє або ставить роботу в чергу, якщо цього більше, ніж пристрій може безпечно дати.
- Байти передаються у Web Worker. Передача ArrayBuffer переносить володіння, а не копіює його, тож великий файл не існує в пам'яті двічі.
- Усередині воркера кодек на WebAssembly або платформний API виконує саме декодування та кодування.
- Результат повертається байтами, загортається в Blob і пропонується вам як завантаження або записується в обране вами місце.
- Тимчасовий URL цього Blob відкликається, а буфери звільняються.
Чому саме WebAssembly усе змінив
Кодеки зображень і відео — це десятиліття ретельно оптимізованого коду на C. Переписати їх на JavaScript ніколи не було реалістично. WebAssembly — це переносний двійковий формат інструкцій, який браузери виконують у пісочниці зі швидкістю, близькою до нативного коду, а отже, наявні бібліотеки можна скомпілювати й доставити в браузер такими, як вони є.
Пісочниця тут важить не менше за швидкість. Модуль WebAssembly не має жодного стороннього доступу до вашої файлової системи, вашої мережі чи ваших інших вкладок. Він бачить лише ту пам'ять, яку йому передала сторінка, і нічого більше. Шкідливий чи просто дірявий кодек не зможе піти кудись убік і прочитати те, чого йому не давали.
Що все ж торкається мережі і чому це не ваш файл
Мережею приходять три речі: сама сторінка, рушій для інструмента, який ви відкрили, і — для видалення фону — ваги моделі. Усі три є власними статичними ресурсами FileSlimmer, які завантажуються з власного джерела FileSlimmer ще до того, як буде прочитано хоч байт ваших даних. Це завантаження, вони кешуються, і після першого використання їх можна віддавати з кешу самого браузера взагалі без мережі.
Усе після цієї межі відбувається локально. Рушії отримують байти файлів лише через postMessage від сторінки; їм ніколи не передають URL, куди щось надсилати, а політика безпеки вмісту обмежує, куди сторінка взагалі могла б підключитися, навіть якби якийсь код спробував.
Компроміси, названі прямо
| Критерій | У вашому браузері | На сервері |
|---|---|---|
| Куди потрапляє ваш файл | Нікуди | На машину, яку ви не контролюєте |
| Швидкість | Така, яку витягне ваш пристрій | Така, за яку заплатив оператор |
| Дуже великі файли | Обмежені пам'яттю браузера | Обмежені лімітами оператора |
| Працює офлайн | Так, коли рушій уже в кеші | Ні |
| Екзотичні формати | Лише те, що компілюється у WebAssembly | Усе, що встановить оператор |
| Пакет із тисячі файлів | Обмежений можливостями пристрою | Зазвичай підходить краще |
Локальна обробка не краща в усьому. Вона краща тоді, коли файл приватний, коли пристрій достатньо потужний і коли робота вміщується в пам'ять. Сервер кращий тоді, коли треба обробити значно більше, ніж здатна вмістити одна машина. Розуміти, у якій із цих ситуацій ви перебуваєте, корисніше, ніж наполягати, що один підхід перемагає скрізь.
Про що тут не йдеться
Це твердження про те, що робить цей застосунок. Це не твердження про ваші розширення браузера, які можуть читати вміст будь-якої відкритої вами сторінки, ні про вашу операційну систему, яка може оглянути будь-який файл, до якого ви торкаєтеся, ні про вашого оператора зв'язку, який бачить, що ви відвідали сайт. Усе це поза досяжністю будь-якого сайту, і інструмент, який стверджує інакше, перебільшує.
Твердження вузьке і перевірюване: вибрані вами файли обробляються локально в цьому браузері, і FileSlimmer нікуди їх не надсилає. Наступний посібник пояснює, як перевірити це самостійно, замість того щоб просто вірити.
Інструменти для цього
Джерела
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs