Przed przetwarzaniem plików DOCX i EPUB ustal budżet na dekompresję ZIP

— Wartość liczbowa przykładu w tym artykule jest bardzo mała i służy jedynie do zademonstrowania ścieżki odrzucenia i nie można jej bezpośrednio wykorzystać w środowisku produkcyjnym.

• Rozsądnie duże dokumenty powinny być przetwarzane w osobnej kolejce lub ręcznie, a wszelkie ograniczenia nie powinny być wyłączane w celu zapewnienia kompatybilności.

W przypadku formatów DOCX i EPUB wiele problemów pojawia się już na etapie dekompresji. DOCX to zasadniczo zbiór wpisów ZIP, a EPUB również korzysta z kontenera ZIP, więc mały rozmiar pliku nie oznacza, że będzie mniejszy po rozpakowaniu. Ten artykuł jest przeznaczony dla programistów oraz personelu operacyjnego i konserwacyjnego, który musi otrzymać dokumenty pakietu Office lub e-booki i przeprowadzić ich późniejsze przetwarzanie. Przedstawia sposób ustalenia budżetu na dekompresję ZIP przy wejściu.

Po przeczytaniu tego możesz określić, jakie ograniczenia powinny zostać nałożone na wejście, jak zwrócić użytkownikowi informacje o odmowie umożliwiającej podjęcie działań i jak odróżnić problemy z kontenerami od problemów z tłumaczeniem, gdy tłumaczenie się nie powiedzie. Przykłady w tym artykule zademonstrowano przy użyciu próbek syntetycznych, a kod przeszedł przykładowe kontrole w izolowanym środowisku, ale nie oznacza to, że jest ważny dla wszystkich rzeczywistych plików. Przed przystąpieniem do przetwarzania ważnych dokumentów prosimy o zachowanie oryginałów i zapoznanie się z nimi zgodnie z granicami i pozycjami akceptacji w tekście.

Jak ustawić budżet na dekompresję ZIP przed przetwarzaniem DOCX i EPUB? Wniosek w jednym zdaniu

Objętość kompresji, liczba wpisów, rozmiar pojedynczego elementu i całkowita wielkość rozszerzenia powinny być ograniczone w punkcie wejścia. Nie czekaj, aż pamięć się wyczerpie, zanim wykryjesz nieprawidłowości w plikach.

Dlaczego musimy najpierw sprawdzić rozmiar po rozwinięciu?

Zarówno DOCX, jak i EPUB używają ZIP jako kontenera. Plik o wielkości kilkuset KB może po rozpakowaniu zająć dużo miejsca. Gdyby system patrzył jedynie na rozmiar przesyłanego pliku, nie byłby w stanie wykryć tego typu zagrożenia.

Dlatego też kontrola na wejściu powinna obejmować jednocześnie następujące aspekty:

• Wolumen kompresji: Ogranicz rozmiar samego przesyłanego pliku.
• Liczba wpisów: Ogranicz liczbę plików w kontenerze.
• Rozmiar pojedynczego elementu: Ogranicz rozmiar rozwiniętego dowolnego elementu.
• Całkowite rozwinięcie: Ogranicz całkowitą liczbę bajtów po rozwinięciu wszystkich wpisów.

Najpierw sprawdź spis treści, ale nie traktuj go jako ostatecznej gwarancji

ZipInfo zapewnia deklarowany rozmiar i skompresowany rozmiar, odpowiedni do wstępnego przesiewania. Pomaga systemowi szybko odrzucać pliki, które wyraźnie przekraczają budżet przed dekompresją.

Jednak informacje zawarte w tabeli katalogów są deklarowane przez sam plik i nie można im całkowicie ufać. Podczas faktycznej dekompresji nadal musisz zgromadzić odczytane bajty i ustawić budżet czasu i pamięci. Tabele katalogów mogą wcześniej odrzucić pliki, ale nie mogą zastąpić ograniczeń czasu wykonywania.

Przykład wstępnego przeglądu bez dekompresji

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

Budżety w tym przykładzie to małe wartości wybrane w celu zademonstrowania ścieżek odrzucenia i nie można ich bezpośrednio odtworzyć w środowisku produkcyjnym. Przykład nie wywołuje extractall ani nie zapisuje wpisów ZIP, więc nie jest to w pełni bezpieczny dekompresor.

Zaszyfrowane wpisy, dowiązania symboliczne, zagnieżdżone archiwa i zużycie zasobów przez sam parser wymagają odrębnych zasad.

Źródła: Python zipfile.

Podczas odrzucania podaj użytkownikowi przydatne informacje

Użytkownicy muszą wiedzieć, co robić dalej, gdy plik zostanie odrzucony; wystarczające informacje dotyczące rozwiązywania problemów muszą być rejestrowane wewnętrznie. W poniższej tabeli przedstawiono odpowiednie metody przetwarzania typowych warunków wyzwalania:

Wyjaśnienia dla użytkowników powinny być krótkie i jasne, unikając nadmiernego ujawniania szczegółów wewnętrznych; Wewnętrzne rekordy powinny zachowywać nazwy limitów, obserwacje i typy anomalii, aby ułatwić dalsze rozwiązywanie problemów.

Nie zamykaj wszystkich ograniczeń tylko dla kompatybilności

Stosunkowo duże dokumenty również mogą przekroczyć budżet. W tym momencie rozsądnym podejściem jest zapewnienie niezależnych dużych kolejek plików lub ręcznych punktów wejścia do przetwarzania, zamiast łagodzenia wszystkich ograniczeń zadań.

Zwiększenie limitu biznesowego najemcy nie oznacza nieograniczonego odprężenia wszystkich zadań. Ograniczenia muszą być odizolowane od wykonania i nie mogą być zapisane tylko obok przycisku upload.

Rozróżnij, która warstwa translacji występuje w

Przygotowując się do przesłania dokumentów do OmniDoc (wpis produktu), najpierw oddziel uszkodzenie kontenera od niepowodzenia tłumaczenia. DOCX, który nawet nie potrafi odczytać XML, może mieć problemy podczas przygotowania do wejścia. Jasny raport z inspekcji wstępnej informuje użytkowników, czy warto ponownie wyeksportować, kompresować obrazy, czy skontaktować się z usługami tłumaczeniowymi w celu rozwiązania problemu.

📊 Porównanie rdzenia

🎯 Która metoda ci odpowiada?

Jeśli potrzebujesz otrzymać DOCX lub EPUB przesłane przez użytkownika,

W punkcie wejścia jednocześnie sprawdź objętość kompresji, liczbę wpisów, rozmiar pojedynczego elementu oraz całkowite rozwinięcie, zanim przejdziesz do kolejnego przetwarzania.

Jeśli głównie polegasz na spisie treści do sprawdzania,

Używaj tabeli katalogowej jako metody prewencyjnego odrzucania, a jednocześnie gromadzić bajty odczytywane podczas faktycznego wyodrębniania i ustalać budżety czasowe i pamięciowe.

Jeśli często spotykasz się z dość dużymi dokumentami

Zapewnij niezależne kolejki dużych plików lub punkty wejścia do ręcznego przetwarzania dla tych dokumentów; nie wyłączaj wszystkich ograniczeń tylko ze względu na kompatybilność.

Jeśli jesteś gotowy, by przesłać dokumenty do OmniDoc

Po pierwsze, rozróżnij uszkodzenia kontenera od niepowodzenia tłumaczenia. Problemy wykryte podczas fazy wstępnej inspekcji można zgłaszać użytkownikom jak najwcześniej.

❓ Najczęściej zadawane pytania (FAQ)

1. Czy rozmiar w tabeli katalogów może być bezpośrednio użyty do określenia bezpieczeństwa plików?

Nie można na nim całkowicie polegać. Zadeklarowany rozmiar podany przez ZipInfo jest odpowiedni do wstępnego przesiewania, ale faktyczna ekstrakcja nadal wymaga zgromadzenia bajtów odczytu oraz ustawienia czasu i budżetu pamięci.

2. Dlaczego skompresowane opakowanie jest tak małe, a po rozpakowaniu może być całkiem duże?

Zarówno DOCX, jak i EPUB używają ZIP jako swojego kontenera; mały skompresowany pakiet nie oznacza, że rozmiar po rozszerzeniu jest również mały. Dlatego konieczne jest ograniczenie całkowitej liczby rozmieszczeń.

3. Jak należy postępować z dużymi dokumentami, które przekraczają budżet?

Rozsądnie duże dokumenty mogą również przekraczać budżet, zapewniając oddzielne kolejki dużych plików lub punkty wejścia do ręcznego przetwarzania zamiast zamykania wszystkich ograniczeń.

4. Gdy tłumaczenie zawodzi, jak określić, gdzie leży problem?

Po pierwsze, rozróżnij uszkodzenia kontenera od niepowodzenia tłumaczenia. DOCX, który nie potrafi nawet odczytać XML, może mieć problemy podczas przygotowania danych wejściowych. Jasny raport wstępnej kontroli pomaga użytkownikom zdecydować, czy ponownie eksportować, kompresować obrazy, czy skontaktować się z usługami tłumaczeniowymi w celu rozwiązania problemu.

📝 Podsumowanie

Limit dekompresji ZIP w wpisie powinien jednocześnie pokrywać objętość kompresji, liczbę wpisów, rozmiar pojedynczego przedmiotu oraz całkowitą ilość rozbudowy, wraz z łącznymi kontrolami w trakcie działania. Dawanie użytkownikom jasnej wskazówki dotyczącej kolejnego kroku podczas odmowy ułatwia rozwiązanie problemu.

Doświadczenie teraz: Prześlij dokument, aby zacząć tłumaczyć, zachowując oryginalne formatowanie