Cách thức chỉnh sửa PDF trên trình duyệt hoạt động như thế nào (và tại sao quyền riêng tư lại quan trọng)

Mỗi khi bạn tải một tài liệu lên công cụ PDF dựa trên điện toán đám mây, tài liệu đó sẽ tồn tại trên các máy chủ mà bạn không kiểm soát, được xử lý bởi phần mềm mà bạn không thể kiểm tra, và được lưu trữ bởi một công ty có chính sách bảo mật và lưu giữ dữ liệu riêng. Trong một thời gian ngắn, cơ sở hạ tầng của người khác sẽ lưu giữ các hợp đồng, tờ khai thuế, hồ sơ y tế hoặc các tài liệu kinh doanh bí mật của bạn.

LuraPDF hoạt động theo cách khác. Mọi thứ diễn ra trong tab trình duyệt của bạn, trên phần cứng của bạn, với sự quản lý bộ nhớ của hệ điều hành. Bài viết này giải thích kiến ​​trúc kỹ thuật giúp điều này trở nên khả thi và những sự đánh đổi về mặt kỹ thuật liên quan.

Trình duyệt như một nền tảng xử lý tài liệu

Các trình duyệt hiện đại không còn chỉ là công cụ hiển thị HTML nữa. Chúng là môi trường thực thi ứng dụng hoàn chỉnh với:

• Công cụ JavaScript (V8 trong Chrome, SpiderMonkey trong Firefox): thực thi mã với tốc độ gần như mã gốc.
• WebAssembly (WASM): thực thi mã C/C++ đã biên dịch với tốc độ gần như mã gốc trong môi trường hộp cát.
• API Canvas: cho phép thao tác hình ảnh ở cấp độ pixel.
• API truy cập hệ thống tập tin: cho phép đọc các tập tin cục bộ mà không cần tải lên.
• Web Workers: chạy các tác vụ tính toán trên các luồng nền mà không làm đóng băng giao diện người dùng.
• ArrayBuffer / Blob: quản lý dữ liệu nhị phân thô (như byte PDF) trong bộ nhớ

Sự kết hợp các khả năng này cho phép xây dựng một quy trình xử lý tài liệu hoàn chỉnh, điều mà cách đây 5 năm cần đến một máy chủ phụ trợ.

Ba thư viện cốt lõi

LuraPDF được xây dựng dựa trên ba thư viện mã nguồn mở nền tảng:

Thư viện pdf

pdf-lib là một thư viện TypeScript để tạo và chỉnh sửa tài liệu PDF trong bất kỳ môi trường JavaScript nào. Nó triển khai một phần đáng kể của đặc tả PDF (ISO 32000), bao gồm:

• Tạo, chỉnh sửa và xóa trang
• Nhúng phông chữ (cả 14 phông chữ tiêu chuẩn và phông chữ TTF/OTF tùy chỉnh)
• Nhúng hình ảnh (JPEG, PNG)
• Vị trí chú thích văn bản
• Tạo và thao tác trường biểu mẫu
• Siêu dữ liệu tài liệu (tiêu đề, tác giả, ngày tạo, v.v.)
• Mã hóa PDF (AES-128 và AES-256)
• Quản lý bảng tham chiếu chéo

Khi LuraPDF hợp nhất các tệp PDF, nó sử dụng pdf-lib để đọc cấu trúc trang của từng tài liệu, chuẩn hóa các tài nguyên được chia sẻ và tạo ra một tệp PDF mới. Khi nén, nó mã hóa lại các đối tượng hình ảnh với hệ số chất lượng thấp hơn. Khi mã hóa, nó áp dụng AES-256 cho tài liệu bằng cách sử dụng Web Crypto API.

pdf-lib hoạt động hoàn toàn trên các đối tượng ArrayBuffer — dữ liệu nhị phân thô trong bộ nhớ trình duyệt. Không có cuộc gọi mạng nào được thực hiện.

pdfjs-dist

PDF.js là công cụ hiển thị PDF của Mozilla, được phân phối dưới dạng pdfjs-dist trên npm. Đây là công cụ cung cấp sức mạnh cho trình xem PDF tích hợp sẵn của Firefox, đã được kiểm thử với hàng triệu tệp PDF thực tế.

LuraPDF sử dụng pdfjs-dist cho:

• Hiển thị trang: Chuyển đổi các trang PDF thành dữ liệu hình ảnh Canvas để hiển thị.
• Trích xuất văn bản: Đọc các luồng nội dung văn bản từ các trang PDF
• Siêu dữ liệu trang: Lấy kích thước trang, giá trị xoay và loại nội dung

Khi bạn thấy tệp PDF của mình được hiển thị trong giao diện LuraPDF — bản xem trước trực quan của các trang — đó là pdfjs-dist đang hiển thị từng trang lên một phần tử HTML Canvas.

Tesseract.js

Tesseract.js là phiên bản được biên dịch bằng WebAssembly của Tesseract OCR. Tesseract là một công cụ OCR mã nguồn mở được phát triển ban đầu bởi HP Labs (1985) và hiện đang được Google duy trì. Nó sử dụng mô hình mạng thần kinh LSTM (Long Short-Term Memory) để nhận dạng ký tự.

Việc chạy Tesseract thông qua WebAssembly trong trình duyệt có nghĩa là:

• Tệp nhị phân WASM 22 MB được tải một lần và được trình duyệt lưu vào bộ nhớ cache.
• Quá trình xử lý OCR chạy trên CPU thông qua WebAssembly, không phải GPU.
• Quá trình xử lý chậm hơn so với OCR đám mây (sử dụng cụm GPU) nhưng cho ra kết quả có chất lượng tương đương.
• Nội dung tài liệu của bạn không bao giờ rời khỏi thiết bị của bạn.

Đối với bản quét 20 trang: nhận dạng ký tự quang học (OCR) trên trình duyệt mất khoảng 30–120 giây. Dịch vụ đám mây có thể chỉ mất 2–5 giây. Sự đánh đổi nằm ở tính bảo mật so với tốc độ.

Kiến trúc: Từ tệp tin đến đầu ra

Đây là những gì xảy ra khi bạn nén một tệp PDF bằng LuraPDF chẳng hạn:

1. Chọn tập tin: Bạn kéo một tập tin PDF vào vùng thả. API Tập tin của trình duyệt sẽ đọc tập tin vào một ArrayBuffer — các byte thô trong bộ nhớ trình duyệt. Không có quá trình tải lên nào diễn ra.

2. Kiểm tra tính hợp lệ: Kiểm tra nhanh xem các byte đặc biệt %PDF có xuất hiện ở đầu ArrayBuffer hay không.

3. Đang tải: PDFDocument.load() của pdf-lib phân tích bảng tham chiếu chéo, đọc cây đối tượng và xây dựng bản thể hiện tài liệu trong bộ nhớ.

4. Liệt kê hình ảnh: Thư viện sẽ duyệt qua các luồng nội dung trang để tìm các đối tượng hình ảnh XObject (hình ảnh được nhúng). Chiều rộng, chiều cao, loại nén và dữ liệu byte của mỗi hình ảnh sẽ được trích xuất.

5. Mã hóa lại: Đối với mỗi hình ảnh, dữ liệu pixel thô được vẽ lên phần tử HTML Canvas, sau đó được xuất lại ở hệ số chất lượng JPEG thấp hơn bằng cách sử dụng canvas.toBlob('image/jpeg', quality) . Đối tượng hình ảnh gốc được thay thế bằng phiên bản mã hóa nhỏ hơn.

6. Chuyển đổi tài liệu thành chuỗi byte: Phương thức save() của pdf-lib sẽ chuyển đổi tài liệu đã chỉnh sửa trở lại thành chuỗi byte. Luồng đối tượng được nén bằng DEFLATE.

7. Tải xuống: Các byte được gói trong một đối tượng Blob, một URL đối tượng tạm thời được tạo ( URL.createObjectURL(blob) ), và một cú nhấp chuột theo chương trình <a> sẽ kích hoạt cơ chế tải xuống của trình duyệt.

Tổng dung lượng dữ liệu được truyền đến bất kỳ máy chủ bên ngoài nào: 0 byte.

Web Workers: Giữ cho giao diện người dùng luôn phản hồi nhanh

Xử lý PDF tiêu tốn nhiều tài nguyên CPU. Chạy nó trên luồng JavaScript chính sẽ làm đóng băng tab trình duyệt — bạn không thể cuộn, nhấp chuột hoặc xem các cập nhật tiến độ trong khi tệp đang được xử lý.

LuraPDF thực hiện tất cả các tác vụ tính toán nặng (nhận dạng ký tự quang học, phân tích PDF dung lượng lớn, mã hóa lại hình ảnh) trong Web Workers — các luồng JavaScript riêng biệt chạy ngầm. Luồng chính xử lý giao diện người dùng, hiển thị thanh tiến trình và giao tiếp với worker thông qua truyền thông điệp (postMessage / onmessage).

Khi quá trình nhận dạng ký tự quang học (OCR) đang chạy, một sự kiện tiến độ sẽ được kích hoạt sau mỗi trang được xử lý. Trình xử lý sẽ gửi { page: 5, total: 20, confidence: 94 } đến luồng chính, luồng chính sẽ cập nhật thanh tiến độ. Giao diện người dùng của bạn vẫn tương tác được trong suốt quá trình.

Quản lý bộ nhớ

Bộ nhớ trình duyệt là có hạn. Một tệp PDF 200 MB được tải vào bộ nhớ, xử lý và lưu lại có thể yêu cầu 400–600 MB RAM (dữ liệu gốc + dữ liệu trung gian trên Canvas + dữ liệu đầu ra). Trên các hệ thống có RAM hạn chế, điều này có thể gây ra áp lực lên bộ nhớ.

Các chiến lược đã sử dụng:

• Xử lý trang theo luồng: Đối với các thao tác nhiều trang, các trang được xử lý và các phần tử Canvas trung gian sẽ bị loại bỏ sau khi sử dụng.
• URL.revokeObjectURL(): Các URL blob tạm thời sẽ bị thu hồi sau khi tải xuống để cho phép GC thực thi.
• Chấm dứt tiến trình Web Worker: Web Worker sẽ bị chấm dứt sau khi hoàn thành nhiệm vụ để giải phóng bộ nhớ đã sử dụng.

Đối với các tập tin rất lớn (>100 MB), các trình duyệt hiện đại xử lý chúng mà không gặp vấn đề gì trên các hệ thống có RAM từ 8 GB trở lên. Các hệ thống cũ hơn hoặc có bộ nhớ hạn chế có thể gặp khó khăn với các tập tin nguồn có dung lượng trên 100 MB.

Kiến trúc bảo mật

Mô hình bảo mật được thực thi bởi chính sách cùng nguồn gốc và kiến ​​trúc cách ly của trình duyệt:

• Không có yêu cầu HTTP: Không có cuộc gọi API bên ngoài, không có dữ liệu đo lường, không có cuộc gọi phân tích trong quá trình xử lý tài liệu.
• Thực thi trong môi trường biệt lập: Web Workers không thể thực hiện các cuộc gọi mạng đến các nguồn bên ngoài.
• Không lưu trữ dữ liệu lâu dài: Các tệp đã xử lý không được ghi vào bộ nhớ trình duyệt (localStorage, IndexedDB hoặc truy cập hệ thống tệp).
• Bộ nhớ phạm vi tab: Khi bạn đóng tab, tất cả các đối tượng ArrayBuffer và Blob liên kết với tab đó sẽ được thu gom rác.

Kiến trúc này có thể kiểm chứng được: hãy mở tab Mạng trong DevTools của trình duyệt trong khi xử lý một tập tin. Bạn sẽ thấy không có yêu cầu nào được gửi trong suốt quá trình xử lý.

Thư viện mã nguồn mở: Có thể kiểm tra, không phải hộp đen

Cả ba thư viện cốt lõi — pdf-lib, pdfjs-dist và Tesseract.js — đều là mã nguồn mở với các kho lưu trữ công khai trên GitHub. Bất kỳ ai cũng có thể kiểm tra mã nguồn của chúng. Mã xử lý PDF chạy trong LuraPDF không phải là một hộp đen độc quyền; đó là mã nguồn công khai với người dùng thực, các vấn đề và đóng góp thực tế.

Điều này rất quan trọng đối với sự tin tưởng. Khi một dịch vụ đám mây nói "chúng tôi xử lý và xóa các tệp của bạn", bạn đang tin tưởng vào lời nói của họ. Khi LuraPDF sử dụng các thư viện mã nguồn mở trong môi trường trình duyệt biệt lập mà không cần thực hiện bất kỳ cuộc gọi mạng nào, bạn có thể xác minh tuyên bố đó bằng cách theo dõi tab mạng.

Sự đánh đổi so với xử lý trên đám mây

Mô hình dựa trên trình duyệt có những sự đánh đổi thực tế cần được thừa nhận một cách thẳng thắn:

Tốc độ: Các dịch vụ đám mây có cụm GPU và cơ sở hạ tầng chuyên dụng. Nhận dạng ký tự quang học (OCR) trên trình duyệt đối với tài liệu lớn mất thời gian gấp 2-10 lần so với giải pháp đám mây tương đương. Quá trình nén nhanh vì sử dụng trực tiếp API của Canvas.

Giới hạn kích thước tập tin: Bộ nhớ trình duyệt là yếu tố hạn chế. Các tập tin rất lớn (>300 MB) có thể vượt quá giới hạn bộ nhớ trên một số hệ thống. Các dịch vụ đám mây không có giới hạn như vậy.

Sức mạnh xử lý: WASM hoạt động với tốc độ bằng 40–80% tốc độ của ngôn ngữ C++ gốc. Các dịch vụ đám mây chạy mã gốc được tối ưu hóa. Đối với hầu hết các tài liệu, sự khác biệt này là không đáng kể; nhưng đối với các tác vụ OCR trên 100 trang, sự khác biệt sẽ rõ rệt.

Tính năng: Một số tính năng PDF nâng cao (kiểm tra tuân thủ PDF/X, quản lý màu chuyên nghiệp, quy trình CMYK) yêu cầu các công cụ chuyên dụng phía máy chủ. Xử lý dựa trên trình duyệt xử lý được 95% trường hợp.

Đối với các tác vụ xử lý tài liệu hàng ngày — nén, hợp nhất, ký tên, chuyển đổi, biên tập — mô hình dựa trên trình duyệt đủ nhanh, bảo mật theo thiết kế và không yêu cầu tài khoản hoặc đăng ký.

Câu hỏi thường gặp

LuraPDF có thu thập bất kỳ dữ liệu đo từ xa hoặc dữ liệu sử dụng nào không? LuraPDF sử dụng Google Analytics để thu thập số liệu thống kê tổng hợp lượt xem trang. Các thao tác xử lý tài liệu không tạo ra bất kỳ sự kiện phân tích nào. Nội dung tệp của bạn không bao giờ được truyền đi.

Tôi có thể xác nhận rằng không có quá trình tải lên nào diễn ra không? Vâng. Mở Công cụ dành cho nhà phát triển (F12), nhấp vào tab Mạng, lọc theo "XHR" hoặc "Fetch". Xử lý một tập tin. Quan sát xem có yêu cầu mạng nào liên quan đến tài liệu trong quá trình xử lý hay không.

Tại sao quá trình nhận dạng ký tự quang học (OCR) lại mất nhiều thời gian hơn so với các dịch vụ khác? Tesseract.js chạy trên trình duyệt bằng CPU thông qua WebAssembly. Các dịch vụ OCR trên đám mây chạy trên các cụm GPU, xử lý ký tự nhanh hơn nhiều lần. Nhược điểm là tài liệu của bạn không bao giờ rời khỏi trình duyệt.

Điều gì sẽ xảy ra nếu tôi đóng tab trong khi đang xử lý? Quá trình xử lý dừng ngay lập tức. Bộ nhớ của tab trình duyệt được thu gom rác. Tệp gốc của bạn trên ổ đĩa không bị thay đổi.

Mã nguồn có phải là mã nguồn mở không? Các thư viện xử lý cốt lõi (pdf-lib, pdfjs-dist, Tesseract.js) là mã nguồn mở. Mã giao diện của LuraPDF hiện chưa phải là mã nguồn mở, nhưng quy trình xử lý chỉ sử dụng các thành phần mã nguồn mở.

Việc chuyển sang xử lý tài liệu dựa trên trình duyệt không phải là một chiêu trò. Đó là một lựa chọn kiến ​​trúc thực sự với những lợi thế có thể đo lường được về quyền riêng tư và sự tin cậy — với cái giá là tốc độ xử lý chậm hơn đối với các tác vụ nặng. Đối với những tài liệu mà bạn không muốn lưu trữ trên máy chủ của người khác, đây là sự đánh đổi hợp lý.