Sebelum memproses DOCX dan EPUB, tetapkan anggaran untuk dekompresi ZIP

Saat menangani DOCX dan EPUB, banyak masalah yang muncul pada tahap dekompresi. DOCX pada dasarnya adalah sekumpulan entri ZIP, dan EPUB juga menggunakan wadah ZIP, jadi ukuran file yang kecil tidak berarti akan menjadi lebih kecil setelah di-unzip. Artikel ini ditujukan bagi pengembang serta personel operasi dan pemeliharaan yang perlu menerima dokumen atau e-book Office dan melakukan pemrosesan selanjutnya. Ini memperkenalkan cara menetapkan anggaran untuk dekompresi ZIP di pintu masuk.

Setelah membaca ini, Anda dapat menentukan batasan mana yang harus diterapkan pada pintu masuk, cara mengembalikan informasi penolakan yang dapat ditindaklanjuti kepada pengguna, dan cara membedakan masalah penampung dari masalah terjemahan saat terjemahan gagal. Contoh dalam artikel ini didemonstrasikan menggunakan sampel sintetis, dan kode tersebut telah lulus pemeriksaan sampel di lingkungan yang terisolasi, namun ini tidak berarti kode tersebut valid untuk semua file sebenarnya. Sebelum memproses dokumen penting, harap simpan dokumen asli dan tinjau sesuai dengan batasan dan item penerimaan dalam teks.

Bagaimana cara menetapkan anggaran untuk dekompresi ZIP sebelum memproses DOCX dan EPUB? Kesimpulan satu kalimat

Volume kompresi, jumlah entri, ukuran masing-masing item, dan jumlah perluasan total harus dibatasi pada titik masuk. Jangan menunggu sampai memori habis sebelum menemukan kelainan file.

Mengapa kita perlu melihat ukuran yang diperluas terlebih dahulu?

Baik DOCX maupun EPUB menggunakan ZIP sebagai wadahnya. File berukuran beberapa ratus KB mungkin memakan banyak ruang setelah dibongkar. Jika sistem hanya melihat ukuran file yang diunggah, sistem tidak akan dapat mendeteksi risiko jenis ini.

Oleh karena itu, pemeriksaan di pintu masuk harus mencakup aspek-aspek berikut secara bersamaan:

• Volume Kompresi: Membatasi ukuran file yang diunggah itu sendiri.
• Jumlah entri: Batasi jumlah file dalam wadah.
• Ukuran item tunggal: Batasi ukuran yang diperluas pada satu item.
• Total perluasan: Batasi jumlah total byte setelah perluasan semua entri.

Periksa daftar isi terlebih dahulu, tapi jangan menganggapnya sebagai jaminan akhir

ZipInfo menyediakan ukuran yang dinyatakan dan ukuran terkompresi, cocok untuk pra-penyaringan. Ini membantu sistem dengan cepat menolak file yang jelas-jelas melebihi anggaran sebelum dekompresi.

Namun, informasi dalam tabel direktori dideklarasikan oleh file itu sendiri dan tidak dapat dipercaya sepenuhnya. Saat benar-benar melakukan dekompresi, Anda masih perlu mengakumulasikan byte yang telah dibaca, serta mengatur waktu dan anggaran memori. Tabel katalog dapat menolak file lebih awal, namun tidak dapat menggantikan batasan waktu proses.

Contoh pra-penyaringan tanpa dekompresi

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")

Anggaran dalam contoh ini adalah nilai kecil yang dipilih untuk menunjukkan jalur penolakan dan tidak dapat direplikasi secara langsung dalam lingkungan produksi. Contoh ini tidak memanggil extractall, juga tidak menulis entri ZIP, sehingga ini bukan dekompresor yang sepenuhnya aman.

Entri terenkripsi, tautan simbolik, arsip bersarang, dan konsumsi sumber daya parser itu sendiri semuanya memerlukan kebijakan terpisah.

Referensi: Python zipfile.

Berikan informasi yang dapat ditindaklanjuti kepada pengguna saat menolak

Pengguna perlu mengetahui apa yang harus dilakukan selanjutnya ketika file ditolak; informasi pemecahan masalah yang memadai perlu dicatat secara internal. Tabel berikut memberikan metode pemrosesan yang sesuai untuk kondisi pemicu umum:

Penjelasan kepada pengguna harus singkat dan jelas, menghindari eksposur detail internal yang berlebihan; Catatan internal harus mempertahankan nama batas, pengamatan, dan jenis anomali untuk memudahkan pemecahan masalah selanjutnya.

Jangan tutup semua pembatasan hanya demi kompatibilitas

Dokumen yang cukup besar juga bisa melebihi anggaran. Pada titik ini, pendekatan yang bijaksana adalah menyediakan antrean file besar yang mandiri atau titik masuk pemrosesan manual, daripada melonggarkan semua pembatasan tugas.

Meningkatkan kuota bisnis penyewa tidak berarti membiarkan dekompresi tanpa batas pada semua tugas. Pembatasan harus diisolasi dari eksekusi dan tidak dapat ditulis hanya di samping tombol unggah.

Membedakan kegagalan translasi lapisan mana yang terjadi

Saat mempersiapkan pengiriman dokumen ke OmniDoc (Entri Produk), pertama-tama pisahkan kerusakan kontainer dari kegagalan terjemahan. DOCX yang bahkan tidak bisa membaca XML mungkin mengalami masalah selama fase persiapan input. Laporan pra-inspeksi yang jelas memberi tahu pengguna apakah harus mengekspor ulang, mengompres gambar, atau menghubungi layanan terjemahan untuk pemecahan masalah.

📊 Perbandingan Inti

🎯 Metode mana yang cocok untukmu?

Jika Anda perlu menerima DOCX atau EPUB yang diunggah pengguna,

Pada titik masuk, periksa secara bersamaan volume kompresi, jumlah entri, ukuran item individual, dan total ekspansi sebelum melanjutkan ke pemrosesan berikutnya.

Jika Anda terutama mengandalkan daftar isi untuk memeriksa,

Gunakan tabel direktori sebagai metode penolakan preemptif, dan pada saat yang sama, akumulasi byte yang dibaca selama ekstraksi aktual, serta atur anggaran waktu dan memori.

Jika Anda sering menemukan dokumen yang cukup besar

Sediakan antrean file besar yang independen atau titik masuk pemrosesan manual untuk dokumen-dokumen ini; jangan nonaktifkan semua pembatasan hanya untuk kompatibilitas.

Jika Anda siap mengirimkan dokumen ke OmniDoc

Pertama, bedakan antara kerusakan kontainer dan kegagalan translasi. Masalah yang ditemukan selama fase pra-inspeksi dapat dilaporkan kepada pengguna sesegera mungkin.

❓ Pertanyaan yang Sering Diajukan (FAQ)

1. Apakah ukuran di tabel direktori dapat langsung digunakan untuk menentukan keamanan file?

Anda tidak bisa sepenuhnya mengandalkannya. Ukuran yang dinyatakan yang disediakan oleh ZipInfo cocok untuk pra-penyaringan, tetapi ekstraksi aktual masih memerlukan akumulasi byte bacaan serta pengaturan waktu dan anggaran memori.

2. Mengapa paket yang dikompresi begitu kecil, tapi saat dibuka, bisa menjadi cukup besar?

Baik DOCX maupun EPUB menggunakan ZIP sebagai wadah mereka; paket kecil yang terkompresi tidak berarti ukuran setelah ekspansi juga kecil. Oleh karena itu, perlu dibatasi jumlah total penempatan.

3. Bagaimana seharusnya dokumen besar yang melebihi anggaran ditangani?

Dokumen yang cukup besar juga dapat melebihi anggaran, menyediakan antrean file besar terpisah atau titik masuk pemrosesan manual daripada menutup semua pembatasan.

4. Ketika terjemahan gagal, bagaimana Anda menentukan di mana letak masalahnya?

Pertama, bedakan antara kerusakan kontainer dan kegagalan translasi. DOCX yang bahkan tidak dapat membaca XML mungkin mengalami masalah selama tahap persiapan input. Laporan pra-pemeriksaan yang jelas membantu pengguna memutuskan apakah akan mengekspor ulang, mengompres gambar, atau menghubungi layanan terjemahan untuk pemecahan masalah.

📝 Ringkasan

Batas dekompresi ZIP pada entri harus mencakup volume kompresi, jumlah entri, ukuran item individual, dan total ekspansi jumlah secara bersamaan, beserta pemeriksaan kumulatif selama runtime. Memberikan petunjuk jelas kepada pengguna untuk langkah selanjutnya saat menolak akan memudahkan penyelesaian masalah.

Rasakan sekarang: Unggah dokumen Anda untuk mulai menerjemahkan, mempertahankan format asli