Trước khi xử lý DOCX và EPUB, hãy đặt ngân sách cho việc giải nén ZIP

Khi xử lý DOCX và EPUB, nhiều vấn đề đã nảy sinh trong giai đoạn giải nén. DOCX về cơ bản là một tập hợp các mục ZIP và EPUB cũng sử dụng bộ chứa ZIP nên kích thước tệp nhỏ không có nghĩa là sau khi giải nén sẽ nhỏ hơn. Bài viết này dành cho các nhà phát triển cũng như nhân viên vận hành và bảo trì, những người cần nhận tài liệu Office hoặc sách điện tử và thực hiện quá trình xử lý tiếp theo. Nó giới thiệu cách đặt ngân sách cho việc giải nén ZIP ở đầu vào.

Sau khi đọc phần này, bạn có thể xác định những hạn chế nào sẽ được đặt ở lối vào, cách trả lại thông tin từ chối có thể xử lý cho người dùng và cách phân biệt các vấn đề về vùng chứa với các vấn đề dịch thuật khi dịch không thành công. Các ví dụ trong bài viết này được minh họa bằng cách sử dụng các mẫu tổng hợp và mã đã vượt qua quá trình kiểm tra mẫu trong môi trường biệt lập nhưng điều này không có nghĩa là nó hợp lệ cho tất cả các tệp thực. Trước khi xử lý các văn bản quan trọng, vui lòng giữ lại bản chính và xem xét theo ranh giới và các mục chấp nhận trong văn bản.

Làm cách nào để đặt ngân sách cho việc giải nén ZIP trước khi xử lý DOCX và EPUB? Một câu kết luận

Khối lượng nén, số lượng mục nhập, kích thước mục riêng lẻ và tổng lượng mở rộng phải được giới hạn tại điểm nhập. Đừng đợi đến khi hết bộ nhớ mới phát hiện ra những bất thường của tập tin.

Tại sao chúng ta cần xem kích thước mở rộng trước?

Cả DOCX và EPUB đều sử dụng ZIP làm vùng chứa. Một file vài trăm KB có thể chiếm nhiều dung lượng sau khi được giải nén. Nếu hệ thống chỉ nhìn vào kích thước của tệp được tải lên thì sẽ không thể phát hiện được loại rủi ro này.

Vì vậy, việc kiểm tra tại lối vào phải bao gồm đồng thời các khía cạnh sau:

• Khối lượng nén: Giới hạn kích thước của chính tệp được tải lên.
• Số lượng mục: Giới hạn số lượng tệp trong vùng chứa.
• Kích thước một mục: Giới hạn kích thước mở rộng của bất kỳ một mục nào.
• Mở rộng toàn bộ: Giới hạn tổng số byte sau khi mở rộng tất cả các mục.

Hãy kiểm tra mục lục trước nhưng đừng coi đó là sự đảm bảo cuối cùng

ZipInfo cung cấp kích thước khai báo và kích thước nén, phù hợp cho việc sàng lọc trước. Nó giúp hệ thống nhanh chóng loại bỏ các tệp vượt quá ngân sách trước khi giải nén.

Tuy nhiên, thông tin trong bảng thư mục được chính file khai báo và không thể tin cậy hoàn toàn. Khi thực sự giải nén, bạn vẫn cần tích lũy số byte đã đọc và đặt thời gian cũng như mức sử dụng bộ nhớ. Bảng danh mục có thể từ chối tệp sớm nhưng chúng không thể thay thế các hạn chế về thời gian chạy.

Ví dụ về sàng lọc trước không cần giải nén

from io import BytesIO
from pathlib import PurePosixPath
from zipfile import ZipFile, ZIP_DEFLATED

def inspect(raw, max_entries=10, max_total=4096):
    if len(raw) > 4096:
        raise ValueError("compressed input budget")
    with ZipFile(BytesIO(raw)) as z:
        items = z.infolist()
        if len(items) > max_entries:
            raise ValueError("entry count budget")
        total, seen = 0, set()
        for item in items:
            name = item.filename
            path = PurePosixPath(name)
            if (path.is_absolute() or ".." in path.parts or
                    "\\" in name or ":" in name or name in seen):
                raise ValueError("unsafe or duplicate name")
            seen.add(name)
            total += item.file_size
            if total > max_total:
                raise ValueError("expanded budget")
        return len(items), total

def sample(name, data):
    out = BytesIO()
    with ZipFile(out, "w", ZIP_DEFLATED) as z:
        z.writestr(name, data)
    return out.getvalue()
assert inspect(sample("word/document.xml", b"<doc/>")) == (1, 6)
for raw in [sample("../escape", b"x"), sample("large", b"x" * 5000)]:
    try:
        inspect(raw)
    except ValueError:
        pass
    else:
        raise AssertionError("unsafe archive accepted")

Ngân sách trong ví dụ này là các giá trị nhỏ được chọn để thể hiện đường dẫn loại bỏ và không thể sao chép trực tiếp trong môi trường sản xuất. Ví dụ này không gọi extractall, cũng không ghi các mục ZIP, vì vậy nó không phải là một công cụ giải nén hoàn toàn an toàn.

Các mục được mã hóa, liên kết tượng trưng, các kho lưu trữ lồng nhau và mức tiêu thụ tài nguyên của chính trình phân tích cú pháp đều yêu cầu các chính sách riêng biệt.

Tham khảo: Python zipfile.

Cung cấp cho người dùng thông tin hữu ích khi từ chối

Người dùng cần biết phải làm gì tiếp theo khi tệp bị từ chối; thông tin khắc phục sự cố đầy đủ cần phải được ghi lại nội bộ. Bảng sau đây cung cấp các phương pháp xử lý tương ứng cho các điều kiện kích hoạt phổ biến:

Giải thích cho người dùng nên ngắn gọn và rõ ràng, tránh tiết lộ quá nhiều chi tiết nội bộ; Các bản ghi nội bộ nên lưu lại tên giới hạn, quan sát và loại bất thường để hỗ trợ việc khắc phục sự cố sau này.

Đừng đóng tất cả các hạn chế chỉ vì tương thích

Các tài liệu khá lớn cũng có thể vượt quá ngân sách. Ở giai đoạn này, cách tiếp cận khôn ngoan là cung cấp các hàng đợi tệp lớn độc lập hoặc các điểm vào xử lý thủ công, thay vì nới lỏng tất cả các hạn chế tác vụ.

Tăng hạn ngạch kinh doanh của người thuê không có nghĩa là cho phép giải nén không giới hạn tất cả các nhiệm vụ. Các hạn chế cần được tách biệt khỏi việc thực thi và không thể chỉ ghi bên cạnh nút tải lên.

Phân biệt lỗi dịch lớp nào đang xảy ra tại

Khi chuẩn bị gửi tài liệu đến OmniDoc (Mục sản phẩm), trước tiên hãy phân biệt sự hỏng container với lỗi dịch thuật. Một DOCX thậm chí không đọc được XML có thể gặp vấn đề trong giai đoạn chuẩn bị đầu vào. Báo cáo kiểm tra trước rõ ràng giúp người dùng biết có nên xuất lại, nén hình ảnh hay liên hệ dịch vụ dịch thuật để khắc phục sự cố.

📊 So sánh cốt lõi

🎯 Phương pháp nào phù hợp với bạn?

Nếu bạn cần nhận DOCX hoặc EPUB do người dùng tải lên,

Tại điểm nhập, đồng thời kiểm tra thể tích nén, số lượng mục, kích thước từng mục và tổng thể mở rộng trước khi tiến hành xử lý tiếp theo.

Nếu bạn chủ yếu dựa vào mục lục để kiểm tra,

Sử dụng bảng thư mục như một phương pháp từ chối trước, đồng thời tích lũy số byte đã đọc trong quá trình trích xuất thực tế, đồng thời thiết lập ngân sách thời gian và bộ nhớ.

Nếu bạn thường xuyên gặp các tài liệu khá lớn

Cung cấp hàng đợi tệp lớn độc lập hoặc các điểm vào xử lý thủ công cho các tài liệu này; không tắt tất cả các hạn chế chỉ để đảm bảo tương thích.

Nếu bạn đã sẵn sàng gửi tài liệu đến OmniDoc

Đầu tiên, phân biệt giữa hư hỏng container và lỗi dịch thuật. Các vấn đề phát hiện trong giai đoạn kiểm tra trước có thể được báo cáo cho người dùng càng sớm càng tốt.

❓ Câu hỏi thường gặp (FAQ)

1. Kích thước trong bảng thư mục có thể được sử dụng trực tiếp để xác định bảo mật tệp không?

Bạn không thể hoàn toàn dựa vào nó. Kích thước khai báo do ZipInfo cung cấp phù hợp để sàng lọc trước, nhưng việc trích xuất thực tế vẫn đòi hỏi tích lũy byte đọc và thiết lập thời gian cũng như ngân sách bộ nhớ.

2. Tại sao gói nén lại nhỏ như vậy, nhưng khi mở ra thì có thể khá lớn?

Cả DOCX và EPUB đều sử dụng ZIP làm chứa; một gói nén nhỏ không có nghĩa là kích thước sau khi mở rộng cũng nhỏ. Do đó, cần phải giới hạn tổng lượng triển khai.

3. Các tài liệu lớn vượt ngân sách nên được xử lý như thế nào?

Tài liệu có kích thước hợp lý cũng có thể vượt quá ngân sách, cung cấp các hàng đợi hồ sơ lớn riêng biệt hoặc các điểm vào xử lý thủ công thay vì đóng tất cả các hạn chế.

4. Khi dịch thuật thất bại, làm sao bạn xác định được vấn đề nằm ở đâu?

Đầu tiên, phân biệt giữa hư hỏng container và lỗi dịch thuật. Một DOCX thậm chí không đọc được XML có thể gặp sự cố trong giai đoạn chuẩn bị đầu vào. Báo cáo kiểm tra trước rõ ràng giúp người dùng quyết định có xuất lại, nén hình ảnh hay liên hệ dịch vụ dịch thuật để khắc phục sự cố.

📝 Tóm tắt

Giới hạn giải nén ZIP tại mục nhập nên đồng thời bao gồm thể tích nén, số lượng mục, kích thước mục riêng lẻ và tổng lượng mở rộng, cùng với các kiểm tra tích lũy trong quá trình chạy. Việc cung cấp cho người dùng một gợi ý rõ ràng về bước tiếp theo khi từ chối giúp việc giải quyết vấn đề trở nên dễ dàng hơn.

Trải nghiệm ngay: Tải lên tài liệu của bạn để bắt đầu dịch, giữ nguyên định dạng gốc