Xử lý tệp cục bộ trong trình duyệt hoạt động ra sao
Nếu không có gì được tải lên thì cái gì đang làm việc, và làm ở đâu?
“Cục bộ” ở đây nghĩa là gì
Một trình chuyển đổi trực tuyến thông thường là một trang web có điểm tiếp nhận tải lên. Tệp của bạn được truyền tới một cỗ máy bạn không kiểm soát, được xử lý ở đó, được lưu lại trong một khoảng thời gian nào đó, rồi được trả về cho bạn tải xuống. Xử lý cục bộ cắt bỏ khúc giữa của câu đó: đoạn mã đọc tệp của bạn chạy ngay trong tab trình duyệt bạn đang mở, trên chính bộ xử lý của bạn, và kết quả được ghi trở lại vào ổ đĩa của chính bạn.
Trang web vẫn được tải về qua mạng — HTML, biểu định kiểu, script và các mô-đun WebAssembly đều đến từ một máy chủ, như mọi trang web khác. Khác biệt nằm ở chiều đi. Mã chương trình đi xuống; tệp của bạn không đi lên.
Trình duyệt vốn đã chứa sẵn các bộ phận
| Thành phần | Nó cung cấp gì |
|---|---|
| File API và Blob API | Đọc các byte của tệp mà người dùng chọn hoặc thả vào, không cần gửi biểu mẫu |
| Web Workers | Chạy phần việc nặng trên một luồng nền để giao diện vẫn phản hồi |
| WebAssembly | Chạy các thư viện codec viết bằng C, C++ hay Rust đã biên dịch, ở tốc độ gần với mã máy |
| Canvas và OffscreenCanvas | Giải mã, vẽ, thay đổi kích thước và mã hoá lại ảnh |
| WebCodecs | Chạm tới chính các bộ mã hoá và giải mã video tăng tốc phần cứng của trình duyệt |
| WebGPU | Chạy suy luận mô hình và xử lý pixel song song trên bộ xử lý đồ hoạ |
| File System Access | Ghi thẳng kết quả vào nơi người dùng chọn, ở những chỗ có hỗ trợ |
Chẳng có gì trong đây là kỳ lạ cả. Vẫn là nền tảng đang chạy bảng tính, công cụ thiết kế và trò chơi trong một tab. Quyết định khác thường duy nhất là từ chối gắn thêm một máy chủ vào đó.
Đường đi của một tệp
- Bạn chọn một tệp. Trình duyệt trao cho trang web một tham chiếu tới nó — không phải một bản sao, mà là một tham chiếu.
- Trang web đọc những byte đầu tiên để nhận diện loại tệp thật từ chữ ký của nó, thay vì tin vào phần mở rộng.
- Nó ước lượng tác vụ cần bao nhiêu bộ nhớ, và từ chối hoặc xếp hàng phần việc đó nếu con số vượt quá mức thiết bị có thể cấp một cách an toàn.
- Các byte được chuyển vào một Web Worker. Chuyển một ArrayBuffer là chuyển quyền sở hữu chứ không phải sao chép nó, nên một tệp lớn không tồn tại hai lần trong bộ nhớ.
- Bên trong worker, một codec WebAssembly hoặc một API của nền tảng thực hiện việc giải mã và mã hoá thật sự.
- Kết quả trở về dưới dạng byte, được bọc trong một Blob, và được đưa cho bạn tải xuống hoặc ghi vào nơi bạn chọn.
- URL tạm thời của Blob đó bị thu hồi và các vùng đệm được giải phóng.
Vì sao WebAssembly là phần đã thay đổi cuộc chơi
Codec ảnh và video là hàng chục năm mã C được tối ưu tỉ mỉ. Viết lại chúng bằng JavaScript chưa bao giờ là chuyện thực tế. WebAssembly là một định dạng lệnh nhị phân khả chuyển mà trình duyệt thực thi trong một hộp cát ở tốc độ gần với mã máy, nghĩa là những thư viện sẵn có ấy có thể được biên dịch và gửi tới trình duyệt gần như nguyên trạng.
Hộp cát quan trọng không kém tốc độ. Một mô-đun WebAssembly không có quyền truy cập mặc nhiên vào hệ thống tệp, vào mạng hay vào các tab khác của bạn. Nó chỉ thấy vùng nhớ mà trang web đưa cho và không thấy gì khác. Một codec độc hại, hay đơn giản là có lỗi, không thể lang thang đi đọc thứ mà nó không được trao.
Cái gì vẫn chạm tới mạng, và vì sao đó không phải tệp của bạn
Có ba thứ đến qua mạng: bản thân trang web, bộ máy xử lý của công cụ bạn mở, và — với chức năng xoá nền — các trọng số của mô hình. Cả ba đều là tài nguyên tĩnh của chính FileSlimmer, được tải về từ chính origin của FileSlimmer trước khi bất kỳ byte nào của bạn được đọc. Chúng là những lượt tải xuống, chúng lưu đệm được, và sau lần dùng đầu tiên chúng có thể được phục vụ từ chính bộ đệm của trình duyệt mà không cần mạng chút nào.
Mọi thứ sau điểm đó đều diễn ra cục bộ. Các bộ máy xử lý chỉ nhận byte của tệp qua postMessage từ trang web; chúng không bao giờ được trao một URL để gửi bất cứ thứ gì đi, và một chính sách bảo mật nội dung giới hạn nơi trang web có thể kết nối tới, ngay cả khi có đoạn mã nào đó thử làm vậy.
Những đánh đổi, nói thẳng ra
| Khía cạnh | Trong trình duyệt của bạn | Trên một máy chủ |
|---|---|---|
| Tệp của bạn đi đâu | Không đi đâu cả | Tới một cỗ máy bạn không kiểm soát |
| Tốc độ | Tuỳ vào khả năng thiết bị của bạn | Tuỳ vào số tiền bên vận hành bỏ ra |
| Tệp rất lớn | Bị giới hạn bởi bộ nhớ của trình duyệt | Bị giới hạn bởi hạn mức của bên vận hành |
| Hoạt động ngoại tuyến | Có, một khi bộ máy xử lý đã được lưu đệm | Không |
| Định dạng hiếm gặp | Chỉ những gì biên dịch được sang WebAssembly | Bất cứ thứ gì bên vận hành cài đặt |
| Lô một nghìn tệp | Bị bó buộc bởi thiết bị | Thường là phù hợp hơn |
Xử lý cục bộ không phải lúc nào cũng tốt hơn. Nó tốt hơn khi tệp là riêng tư, khi thiết bị đủ mạnh, và khi công việc nằm vừa trong bộ nhớ. Máy chủ tốt hơn khi bạn cần xử lý nhiều hơn nhiều so với sức chứa của một cỗ máy. Nhìn rõ mình đang ở tình huống nào thì hữu ích hơn là khăng khăng rằng một cách tiếp cận thắng ở mọi nơi.
Điều bài này không khẳng định
Đây là một tuyên bố về những gì ứng dụng này làm. Nó không phải tuyên bố về các tiện ích mở rộng trình duyệt của bạn, vốn có thể đọc nội dung mọi trang bạn mở, cũng không phải về hệ điều hành của bạn, vốn có thể soi mọi tệp bạn chạm tới, cũng không phải về nhà mạng của bạn, vốn thấy được rằng bạn đã ghé thăm một trang web. Những thứ đó nằm ngoài tầm với của mọi trang web, và một công cụ nói với bạn khác đi là đang thổi phồng.
Tuyên bố ở đây hẹp và kiểm chứng được: các tệp bạn chọn được xử lý cục bộ trong trình duyệt này và không được FileSlimmer tải lên đâu cả. Bài hướng dẫn tiếp theo chỉ cho bạn cách tự kiểm chứng điều đó thay vì tin lời.
Công cụ cho việc này
Nguồn tham khảo
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs