Před zpracováním DOCX a EPUB nastavte rozpočet pro dekompresi ZIP

Při práci s DOCX a EPUB se již ve fázi dekomprese objevuje mnoho problémů. DOCX je v podstatě sada položek ZIP a EPUB také používá kontejner ZIP, takže malá velikost souboru neznamená, že bude po rozbalení menší. Tento článek je určen vývojářům a pracovníkům provozu a údržby, kteří potřebují přijímat dokumenty Office nebo e-knihy a provádět následné zpracování. Uvádí, jak nastavit rozpočet pro dekompresi ZIP u vstupu.

Po přečtení tohoto můžete určit, která omezení by měla být umístěna na vstupu, jak vrátit uživateli informace o zamítnutí a jak rozlišit problémy s kontejnery od problémů s překladem, když překlad selže. Příklady v tomto článku jsou demonstrovány pomocí syntetických vzorků a kód prošel kontrolou vzorků v izolovaném prostředí, ale to neznamená, že je platný pro všechny skutečné soubory. Před zpracováním důležitých dokumentů si prosím uschovejte originály a zkontrolujte je podle hranic a přejímacích položek v textu.

Jak nastavit rozpočet pro dekompresi ZIP před zpracováním DOCX a EPUB? Závěr jednou větou

Objem komprese, počet položek, velikost jednotlivých položek a celková částka rozšíření by měly být ve vstupním bodě omezeny. Nečekejte, až se paměť vyčerpá, než zjistíte abnormality souboru.

Proč se nejprve musíme podívat na zvětšenou velikost?

DOCX i EPUB používají ZIP jako kontejner. Soubor o velikosti několika set kB může po rozbalení zabírat hodně místa. Pokud by se systém díval pouze na velikost nahraného souboru, nebyl by schopen tento typ rizika odhalit.

Proto by kontrola u vchodu měla současně zahrnovat následující aspekty:

• Hlasitost komprese: Omezte velikost samotného nahrávaného souboru.
• Počet položek: Omezte počet souborů v kontejneru.
• Velikost jedné položky: Omezte rozbalenou velikost jedné položky.
• Celkové rozšíření: Omezte celkový počet bajtů po rozšíření všech položek.

Nejprve zkontrolujte obsah, ale neberte to jako konečnou záruku

ZipInfo poskytuje deklarovanou velikost a komprimovanou velikost, vhodnou pro předběžné screening. Pomáhá systému rychle odmítnout soubory, které jasně překračují rozpočet před dekompresí.

Informace v tabulce adresáře jsou však deklarovány samotným souborem a nelze jim zcela důvěřovat. Při skutečné dekompresi stále potřebujete nashromáždit přečtené bajty a nastavit rozpočet na čas a paměť. Katalogové tabulky mohou odmítnout soubory předčasně, ale nemohou nahradit omezení běhu.

Příklad předběžného screeningu bez dekomprese

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

Rozpočty v tomto příkladu jsou malé hodnoty zvolené k demonstraci cest zamítnutí a nelze je přímo replikovat v produkčním prostředí. Příklad nevolá extractall, ani nezapisuje položky ZIP, takže se nejedná o plně bezpečný dekompresor.

Šifrované položky, symbolické odkazy, vnořené archivy a spotřeba zdrojů samotného analyzátoru – to vše vyžaduje samostatné zásady.

Zdroje: Python zipfile.

Při odmítnutí poskytněte uživateli informace, které je možné provést

Uživatelé potřebují vědět, co dělat dále, když je soubor odmítnut; je třeba interně zaprotokolovat dostatek informací o odstraňování problémů. Následující tabulka uvádí odpovídající metody zpracování pro běžné spouštěcí podmínky:

Pokyny pro uživatele by měly být stručné a jasné, aby se zabránilo odhalení příliš velkého množství vnitřních detailů; interní záznamy by měly uchovávat omezená jména, hodnoty pozorování a typy výjimek, aby se usnadnilo následné vyšetřování.

Nevypínejte všechna omezení kvůli kompatibilitě

Přiměřeně velké dokumenty mohou také překročit váš rozpočet. V tuto chvíli je bezpečnější poskytnout nezávislou frontu velkých souborů nebo manuální vstup pro zpracování namísto uvolnění omezení u všech úkolů.

Navýšení obchodní kvóty určitého nájemce neznamená umožnění neomezené dekomprese všech úkolů. Omezení je třeba spárovat s izolací provedení, ne jen napsat vedle tlačítka pro nahrávání.

Pokud se překlad nezdaří, musíte určit, ve které vrstvě se nachází.

Při přípravě na odeslání dokumentu do OmniDoc (produktový portál) nejprve oddělte poškození kontejneru od selhání překladu. DOCX, který neumí číst ani XML, problém může nastat ve fázi přípravy vstupu. Přehledná zpráva před výstupem dává uživatelům vědět, zda mají obrázky znovu exportovat, komprimovat nebo kontaktovat překladatelskou službu pro řešení problémů.

📊 Srovnání jádra

🎯 Která metoda je pro vás vhodná?

Pokud potřebujete přijímat DOCX nebo EPUB nahrané uživateli

Na vstupu zkontrolujte objem komprese, počet záznamů, velikost jednotlivé položky a celkovou částku expanze před zadáním dalšího zpracování.

Pokud se při kontrole spoléháte hlavně na tabulky adresářů

Použijte tabulku adresářů jako prostředek pro brzké odmítnutí a zároveň akumulujte bajty přečtené během skutečné dekomprese a nastavujte rozpočty času a paměti.

Pokud se často setkáváte s přiměřeně velkými dokumenty

Poskytněte pro takové dokumenty samostatnou frontu velkých souborů nebo vstup pro ruční zpracování a nevypínejte všechna omezení z důvodu kompatibility.

Pokud jste připraveni odeslat dokument OmniDoc

Nejprve rozlišujte mezi poškozením kontejneru a selháním překladu. Problémy, které lze objevit během fáze předběžné kontroly, mohou být uživatelům hlášeny co nejdříve.

❓ Často kladené otázky (FAQ)

1. Lze velikost v tabulce adresářů použít přímo k určení, zda je soubor bezpečný?

Nedá se na to úplně spolehnout. Velikost deklarace poskytovaná ZipInfo je vhodná pro předběžné prověřování, ale stále je nutné akumulovat přečtené bajty a nastavit rozpočet času a paměti během skutečné dekomprese.

2. Proč je komprimovaný balíček velmi malý, ale po dekomprimaci může být velmi velký?

DOCX i EPUB používají ZIP jako kontejner. Malá velikost komprimovaného obalu neznamená, že rozšířený objem bude také malý. Proto je nutné omezit celkové množství expanze.

3. Jak se vypořádat s velkými dokumenty, které přesahují rozpočet?

Přiměřeně velké dokumenty mohou také překročit rozpočet a namísto vypnutí všech limitů lze poskytnout samostatnou frontu velkých souborů nebo ruční zpracování.

4. Když se překlad nezdaří, jak určit, ve které vrstvě problém spočívá?

Nejprve rozlišujte mezi poškozením kontejneru a selháním překladu. U DOCX, které neumí číst ani XML, může problém nastat ve fázi přípravy vstupu. Přehledná zpráva o předběžné kontrole může uživatelům pomoci rozhodnout se, zda znovu exportovat, komprimovat obrázky nebo kontaktovat překladatelskou službu pro řešení problémů.

📝 Shrnutí

Dekompresní limit ZIP na položce by měl pokrývat jak komprimovaný objem, počet položek, velikost jednotlivé položky, tak celkovou částku expanze a měl by spolupracovat s kumulativní kontrolou za běhu. Pokud uživateli poskytnete jasnou výzvu k dalšímu kroku při odmítnutí, může to usnadnit řešení problému.

Vyzkoušejte to hned: Nahrajte dokument a začněte překládat při zachování původního rozvržení