Prima di elaborare DOCX ed EPUB, imposta un budget per la decompressione ZIP

Quando si ha a che fare con DOCX ed EPUB, molti problemi sorgono già durante la fase di decompressione. DOCX è essenzialmente un insieme di voci ZIP e anche EPUB utilizza un contenitore ZIP, quindi la dimensione ridotta del file non significa che sarà più piccolo dopo la decompressione. Questo articolo è destinato agli sviluppatori e al personale operativo e di manutenzione che necessitano di ricevere documenti Office o e-book ed eseguire successive elaborazioni. Introduce come impostare un budget per la decompressione ZIP all'ingresso.

Dopo aver letto questo, puoi determinare quali restrizioni devono essere poste all'ingresso, come restituire all'utente informazioni di rifiuto utilizzabili e come distinguere i problemi del contenitore dai problemi di traduzione quando la traduzione fallisce. Gli esempi in questo articolo vengono dimostrati utilizzando campioni sintetici e il codice ha superato i controlli di esempio in un ambiente isolato, ma ciò non significa che sia valido per tutti i file reali. Prima di elaborare documenti importanti, conservare gli originali e rivederli rispettando i limiti e gli elementi di accettazione nel testo.

Come impostare un budget per la decompressione ZIP prima dell'elaborazione di DOCX ed EPUB? Conclusione di una frase

Il volume di compressione, il numero di voci, la dimensione del singolo elemento e la quantità di espansione totale devono essere limitati nel punto di ingresso. Non aspettare che la memoria sia esaurita prima di scoprire anomalie nei file.

Perché dobbiamo prima considerare le dimensioni espanse?

Sia DOCX che EPUB utilizzano ZIP come contenitore. Un file di diverse centinaia di KB può occupare molto spazio dopo essere stato decompresso. Se il sistema guardasse solo la dimensione del file caricato, non sarebbe in grado di rilevare questo tipo di rischio.

Pertanto, l’ispezione all’ingresso dovrebbe coprire contemporaneamente i seguenti aspetti:

• Volume di compressione: limita la dimensione del file caricato stesso.
• Numero di voci: limita il numero di file all'interno del contenitore.
• Dimensione articolo singolo: limita la dimensione espansa di qualsiasi articolo.
• Espansione totale: limita il numero totale di byte dopo l'espansione di tutte le voci.

Controlla prima il sommario, ma non prenderlo come una garanzia definitiva

ZipInfo fornisce dimensioni dichiarate e dimensioni compresse, adatte per il pre-screening. Aiuta il sistema a rifiutare rapidamente i file che superano chiaramente il budget prima della decompressione.

Tuttavia, le informazioni nella tabella delle directory vengono dichiarate dal file stesso e non possono essere completamente attendibili. Durante la decompressione effettiva, è comunque necessario accumulare i byte che sono stati letti e impostare il tempo e il budget di memoria. Le tabelle del catalogo possono rifiutare i file in anticipo, ma non possono sostituire le restrizioni di runtime.

Un esempio di pre-screening senza decompressione

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

I budget in questo esempio sono valori piccoli scelti per dimostrare i percorsi di rifiuto e non possono essere replicati direttamente in un ambiente di produzione. L'esempio non chiama extractall, né scrive voci ZIP, quindi non è un decompressore completamente sicuro.

Le voci crittografate, i collegamenti simbolici, gli archivi nidificati e il consumo di risorse del parser stesso richiedono tutti politiche separate.

Riferimenti: Python zipfile.

Fornisci all'utente informazioni utili in caso di rifiuto

Gli utenti devono sapere cosa fare dopo quando un file viene rifiutato; È necessario registrare internamente informazioni sufficienti per la risoluzione dei problemi. La tabella seguente fornisce i metodi di elaborazione corrispondenti per le condizioni di attivazione comuni:

Le spiegazioni agli utenti dovrebbero essere brevi e chiare, evitando un'esposizione eccessiva di dettagli interni; I record interni dovrebbero conservare nomi di limite, osservazioni e tipi di anomalie per facilitare la successiva risoluzione dei problemi.

Non chiudere tutte le restrizioni solo per compatibilità

Documenti ragionevolmente grandi possono anche superare il budget. A questo punto, un approccio prudente è fornire code file grandi indipendenti o punti di ingresso manuali per l'elaborazione, piuttosto che allentare tutte le restrizioni del compito.

Aumentare la quota di business di un inquilino non significa permettere la decompressione illimitata di tutte le attività. Le restrizioni devono essere isolate dall'esecuzione e non possono essere scritte solo accanto al pulsante di caricamento.

Distinguere quale fallimento di traslazione di livello è in

Quando si prepara a inviare documenti a OmniDoc (Voce prodotto), si separi prima la corruzione del contenitore dal fallimento della traduzione. Un DOCX che non riesce nemmeno a leggere XML potrebbe avere problemi durante la fase di preparazione degli input. Un chiaro rapporto pre-ispezione informa gli utenti se riesportare, comprimere immagini o contattare i servizi di traduzione per la risoluzione dei problemi.

📊 Confronto tra i nuclei

🎯 Quale metodo ti si addice?

Se hai bisogno di ricevere DOCX o EPUB caricati dagli utenti,

Al punto di ingresso, verifica contemporaneamente il volume di compressione, il numero di entrate, la dimensione del singolo elemento e l'espansione totale prima di procedere con la successiva elaborazione.

Se ti affidi principalmente all'indice per il controllo,

Usa la tabella delle directory come metodo di rifiuto preventivo e, allo stesso tempo, accumula i byte letti durante l'estrazione effettiva e imposta budget di tempo e memoria.

Se spesso incontri documenti ragionevolmente grandi

Fornire code file grandi e indipendenti o punti di ingresso manuali per questi documenti; non disabilitare tutte le restrizioni solo per compatibilità.

Se sei pronto a inviare i documenti a OmniDoc

Innanzitutto, distinguere tra danni al contenitore e fallimento della traslazione. I problemi riscontrati durante la fase di pre-ispezione possono essere segnalati agli utenti il prima possibile.

❓ Domande Frequenti (FAQ)

1. La dimensione nella tabella delle directory può essere utilizzata direttamente per determinare la sicurezza dei file?

Non puoi contarci completamente. La dimensione dichiarata fornita da ZipInfo è adatta per la pre-screening, ma l'estrazione effettiva richiede comunque l'accumulo di byte di lettura e l'impostazione del budget di tempo e memoria.

2. Perché il pacchetto compresso è così piccolo, ma quando viene svuotato può risultare piuttosto grande?

Sia DOCX che EPUB usano ZIP come contenitore; un piccolo package compresso non significa che la dimensione dopo l'espansione sia anch'essa piccola. Pertanto, è necessario limitare il numero totale di dispiegamento.

3. Come dovrebbero essere gestiti i documenti grandi che superano il budget?

Documenti ragionevolmente grandi possono anche superare il budget, fornendo code file grandi separate o punti di ingresso manuali invece di chiudere tutte le restrizioni.

4. Quando la traduzione fallisce, come si determina dove risiede il problema?

Innanzitutto, distinguere tra danni al contenitore e fallimento della traslazione. Un DOCX che non riesce nemmeno a leggere XML può avere problemi durante la fase di preparazione degli input. Un report pre-check chiaro aiuta gli utenti a decidere se riesportare, comprimere immagini o utilizzare servizi di traduzione di contatti per la risoluzione dei problemi.

📝 Riassunto

Il limite di decompressione ZIP all'ingresso dovrebbe coprire contemporaneamente il volume di compressione, il numero di voci, la dimensione del singolo elemento e l'importo totale di espansione, insieme ai controlli cumulativi durante l'esecuzione. Fornire agli utenti un chiaro indizio per il passo successivo quando si rifiuta rende più facile risolvere il problema.

Esperienza ora: carica il tuo documento per iniziare a tradurre, mantenendo la formattazione originale