Legen Sie vor der Verarbeitung von DOCX und EPUB ein Budget für die ZIP-Dekomprimierung fest

Beim Umgang mit DOCX und EPUB treten bereits bei der Dekomprimierung viele Probleme auf. DOCX besteht im Wesentlichen aus einer Reihe von ZIP-Einträgen, und EPUB verwendet ebenfalls einen ZIP-Container. Die geringe Dateigröße bedeutet also nicht, dass sie nach dem Entpacken kleiner wird. Dieser Artikel richtet sich an Entwickler sowie Betriebs- und Wartungspersonal, die Office-Dokumente oder E-Books empfangen und anschließend verarbeiten müssen. Es wird erläutert, wie Sie ein Budget für die ZIP-Dekomprimierung am Eingang festlegen.

Nachdem Sie dies gelesen haben, können Sie festlegen, welche Einschränkungen am Eingang angebracht werden sollten, wie umsetzbare Ablehnungsinformationen an den Benutzer zurückgegeben werden und wie Containerprobleme von Übersetzungsproblemen unterschieden werden können, wenn die Übersetzung fehlschlägt. Die Beispiele in diesem Artikel werden anhand synthetischer Beispiele demonstriert, und der Code hat Beispielprüfungen in einer isolierten Umgebung bestanden. Dies bedeutet jedoch nicht, dass er für alle realen Dateien gültig ist. Bevor Sie wichtige Dokumente bearbeiten, bewahren Sie bitte die Originale auf und überprüfen Sie sie anhand der Grenzen und Akzeptanzpunkte im Text.

Wie legt man ein Budget für die ZIP-Dekomprimierung fest, bevor man DOCX und EPUB verarbeitet? Fazit in einem Satz

Das Komprimierungsvolumen, die Anzahl der Einträge, die Größe der einzelnen Elemente und die Gesamterweiterungsmenge sollten am Einstiegspunkt begrenzt sein. Warten Sie nicht, bis der Speicher erschöpft ist, bevor Sie Dateianomalien entdecken.

Warum müssen wir uns zuerst die erweiterte Größe ansehen?

Sowohl DOCX als auch EPUB verwenden ZIP als Container. Eine Datei mit mehreren hundert KB kann nach dem Entpacken viel Platz beanspruchen. Wenn das System nur die Größe der hochgeladenen Datei betrachten würde, wäre es nicht in der Lage, diese Art von Risiko zu erkennen.

Daher sollte die Kontrolle am Eingang gleichzeitig folgende Aspekte umfassen:

• Komprimierungsvolumen: Begrenzen Sie die Größe der hochgeladenen Datei selbst.
• Anzahl der Einträge: Begrenzen Sie die Anzahl der Dateien im Container.
• Einzelelementgröße: Begrenzen Sie die erweiterte Größe eines einzelnen Elements.
• Gesamterweiterung: Begrenzen Sie die Gesamtzahl der Bytes nach der Erweiterung aller Einträge.

Überprüfen Sie zuerst das Inhaltsverzeichnis, betrachten Sie es jedoch nicht als endgültige Garantie

ZipInfo stellt die deklarierte Größe und die komprimierte Größe bereit, die für das Vorscreening geeignet sind. Es hilft dem System, Dateien, die das Budget deutlich überschreiten, vor der Dekomprimierung schnell abzulehnen.

Allerdings werden die Informationen in der Verzeichnistabelle von der Datei selbst deklariert und können nicht vollständig vertrauenswürdig sein. Beim eigentlichen Dekomprimieren müssen Sie noch die gelesenen Bytes akkumulieren und das Zeit- und Speicherbudget festlegen. Katalogtabellen können Dateien vorzeitig ablehnen, sie können jedoch keine Laufzeitbeschränkungen ersetzen.

Ein Beispiel für ein Vorscreening ohne Dekompression

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

Bei den Budgets in diesem Beispiel handelt es sich um kleine Werte, die zur Veranschaulichung von Ablehnungspfaden ausgewählt wurden und nicht direkt in einer Produktionsumgebung repliziert werden können. Das Beispiel ruft weder extractall auf, noch schreibt es ZIP-Einträge, es handelt sich also nicht um einen vollständig sicheren Dekomprimierer.

Verschlüsselte Einträge, symbolische Links, verschachtelte Archive und der Ressourcenverbrauch des Parsers selbst erfordern jeweils separate Richtlinien.

Quellen: Python zipfile.

Geben Sie dem Benutzer beim Ablehnen umsetzbare Informationen

Benutzer müssen wissen, was als nächstes zu tun ist, wenn eine Datei abgelehnt wird. Es müssen ausreichend Informationen zur Fehlerbehebung intern protokolliert werden. In der folgenden Tabelle sind die entsprechenden Verarbeitungsmethoden für häufige Triggerbedingungen aufgeführt:

Anweisungen für Benutzer sollten kurz und klar sein, um zu vermeiden, dass zu viele interne Details preisgegeben werden. Interne Aufzeichnungen sollten eingeschränkte Namen, Beobachtungswerte und Ausnahmetypen enthalten, um spätere Untersuchungen zu erleichtern.

Deaktivieren Sie aus Kompatibilitätsgründen nicht alle Einschränkungen

Auch einigermaßen große Dokumente können Ihr Budget sprengen. Zu diesem Zeitpunkt ist es sicherer, eine unabhängige große Dateiwarteschlange oder einen manuellen Verarbeitungseingang bereitzustellen, anstatt die Einschränkungen für alle Aufgaben zu lockern.

Das Erhöhen des Geschäftskontingents eines bestimmten Mandanten bedeutet nicht, dass eine unbegrenzte Dekomprimierung aller Aufgaben möglich ist. Einschränkungen müssen mit der Ausführungsisolation gepaart werden und nicht nur neben der Schaltfläche zum Hochladen geschrieben werden.

Wenn die Übersetzung fehlschlägt, müssen Sie ermitteln, auf welcher Ebene sie sich befindet.

Wenn Sie die Übermittlung eines Dokuments an OmniDoc (Produktportal) vorbereiten, trennen Sie zunächst die Containerbeschädigung vom Übersetzungsfehler. Bei einem DOCX, das nicht einmal XML lesen kann, kann das Problem in der Eingabevorbereitungsphase auftreten. Ein übersichtlicher Preflight-Bericht informiert Benutzer darüber, ob sie Bilder erneut exportieren, komprimieren oder sich zur Fehlerbehebung an einen Übersetzungsdienst wenden sollten.

📊 Kernvergleich

🎯 Welche Methode ist für Dich geeignet?

Wenn Sie von Benutzern hochgeladenes DOCX oder EPUB empfangen müssen

Überprüfen Sie am Eingang gleichzeitig das Komprimierungsvolumen, die Anzahl der Einträge, die Einzelelementgröße und die Gesamtexpansion, bevor Sie mit der Weiterverarbeitung beginnen.

Wenn Sie sich zur Überprüfung hauptsächlich auf Verzeichnistabellen verlassen

Verwenden Sie die Verzeichnistabelle als Mittel zur frühzeitigen Ablehnung, während Sie gleichzeitig die während der tatsächlichen Dekomprimierung gelesenen Bytes akkumulieren und Zeit- und Speicherbudgets festlegen.

Wenn Sie häufig auf relativ große Dokumente stoßen

Stellen Sie für solche Dokumente eine separate große Dateiwarteschlange oder einen manuellen Verarbeitungseingang bereit und schalten Sie aus Kompatibilitätsgründen nicht alle Einschränkungen aus.

Wenn Sie bereit sind, ein Dokument an OmniDoc zu senden

Unterscheiden Sie zunächst zwischen Containerschaden und Übersetzungsfehler. Probleme, die während der Vorprüfungsphase entdeckt werden können, können den Benutzern so früh wie möglich gemeldet werden.

❓ Häufig gestellte Fragen (FAQ)

1. Kann die Größe in der Verzeichnistabelle direkt verwendet werden, um festzustellen, ob die Datei sicher ist?

Man kann sich nicht vollständig darauf verlassen. Die von ZipInfo bereitgestellte Deklarationsgröße ist für die Vorabprüfung geeignet, es ist jedoch dennoch erforderlich, die gelesenen Bytes zu akkumulieren und das Zeit- und Speicherbudget während der tatsächlichen Dekomprimierung festzulegen.

2. Warum ist das komprimierte Paket sehr klein, kann aber nach der Dekomprimierung sehr groß sein?

Sowohl DOCX als auch EPUB verwenden ZIP als Container. Die geringe Größe des komprimierten Pakets bedeutet nicht, dass auch das erweiterte Volumen klein sein wird. Daher ist es notwendig, den gesamten Expansionsbetrag zu begrenzen.

3. Wie gehe ich mit großen Dokumenten um, die das Budget überschreiten?

Auch relativ große Dokumente können das Budget überschreiten, und statt alle Beschränkungen auszuschalten, kann eine separate Warteschlange für große Dateien oder ein manueller Verarbeitungseingang bereitgestellt werden.

4. Wie lässt sich feststellen, auf welcher Ebene das Problem liegt, wenn die Übersetzung fehlschlägt?

Unterscheiden Sie zunächst zwischen Containerschaden und Übersetzungsfehler. Bei einem DOCX, das nicht einmal XML lesen kann, kann das Problem in der Eingabevorbereitungsphase auftreten. Ein klarer Vorabprüfungsbericht kann Benutzern bei der Entscheidung helfen, ob sie Bilder erneut exportieren, komprimieren oder sich zur Fehlerbehebung an einen Übersetzungsdienst wenden möchten.

📝 Zusammenfassung

Das ZIP-Dekomprimierungslimit am Eintrag sollte sowohl das komprimierte Volumen, die Anzahl der Einträge, die einzelne Elementgröße als auch die gesamte Erweiterungsmenge abdecken und mit der kumulativen Prüfung zur Laufzeit kooperieren. Wenn Sie dem Benutzer beim Ablehnen eine klare Aufforderung zum nächsten Schritt geben, kann das Problem einfacher gelöst werden.

Probieren Sie es jetzt aus: Laden Sie das Dokument hoch, um mit der Übersetzung zu beginnen, und behalten Sie dabei das ursprüngliche Layout bei