Перед обработкой DOCX и EPUB установите бюджет на распаковку ZIP.

— Заявленный размер таблицы каталогов подходит только для предварительной фильтрации, а фактические прочитанные байты все равно необходимо накапливать и устанавливать бюджет во время выполнения. — Числовое значение примера в этой статье очень мало и используется только для демонстрации пути отклонения и не может быть напрямую использовано в производственной среде.

• Достаточно большие документы следует обрабатывать в отдельной очереди или вручную, при этом все ограничения не следует отключать для совместимости.

При работе с DOCX и EPUB многие проблемы возникают уже на этапе распаковки. DOCX — это, по сути, набор ZIP-записей, а EPUB также использует ZIP-контейнер, поэтому небольшой размер файла не означает, что он станет меньше после разархивирования. Эта статья предназначена для разработчиков, а также персонала по эксплуатации и техническому обслуживанию, которому необходимо получать документы Office или электронные книги и выполнять последующую обработку. В нем рассказывается, как установить бюджет на распаковку ZIP на входе.

Прочитав это, вы сможете определить, какие ограничения следует установить на входе, как вернуть пользователю действенную информацию об отказе и как отличить проблемы с контейнером от проблем с переводом в случае сбоя перевода. Примеры в этой статье продемонстрированы на синтетических образцах, а код прошел выборочные проверки в изолированной среде, но это не означает, что он справедлив для всех реальных файлов. Перед обработкой важных документов, пожалуйста, сохраните оригиналы и просмотрите их по границам и пунктам приема в тексте.

Как установить бюджет на распаковку ZIP перед обработкой DOCX и EPUB? Вывод в одно предложение

Объем сжатия, количество записей, размер отдельного элемента и общая сумма расширения должны быть ограничены в точке входа. Не ждите, пока память исчерпается, прежде чем обнаружить аномалии файлов.

Почему стоит сначала смотреть на размер после того, как разворачиваешь

И DOCX, и EPUB используют ZIP в качестве контейнера. Файл в несколько сотен КБ может занять много места после распаковки. Если система смотрит только на размер загруженного файла, она не обнаружит такой риск.

Поэтому инспекция входа должна одновременно охватывать следующие аспекты:

• Объем сжатия: Ограничьте размер самого загружаемого файла.
• Количество записей: Ограничьте количество файлов в контейнере.
• Размер одного элемента: Ограничьте расширенный размер любого одного элемента.
• Общее расширение: Ограничьте общее количество байтов после расширения всех записей.

Сначала проверьте оглавление, но не воспринимайте это как окончательную гарантию

ZipInfo предлагает заявленный размер и размер сжатия, подходящие для предварительного отбора. Это помогает системе быстро отклонять файлы, явно превышающие бюджет, до распаковки.

Однако информация в таблице каталогов объявлена самим файлом, и ей нельзя полностью доверять. При фактической распаковке вам все равно необходимо накопить прочитанные байты и установить бюджет времени и памяти. Таблицы каталога могут досрочно отклонять файлы, но не могут заменить ограничения времени выполнения.

Пример предварительного скрининга без декомпрессии

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

Бюджеты в этом примере представляют собой небольшие значения, выбранные для демонстрации путей отклонения, и их нельзя напрямую воспроизвести в производственной среде. В примере не вызывается extractall и не записываются ZIP-записи, поэтому он не является полностью безопасным декомпрессором.

Зашифрованные записи, символические ссылки, вложенные архивы и потребление ресурсов самим парсером требуют отдельных политик.

Источники: Python zipfile.

Предоставляйте пользователю полезную информацию при отклонении

Пользователям необходимо знать, что делать дальше, если файл отклонен; достаточная информация по устранению неполадок должна регистрироваться во внутренней системе. В следующей таблице приведены соответствующие методы обработки для распространенных условий триггера:

Объяснения пользователям должны быть краткими и ясными, избегая чрезмерного раскрытия внутренних деталей; Внутренние записи должны сохранять лимитные имена, наблюдения и типы аномалий для облегчения последующего устранения неполадок.

Не закрывайте все ограничения ради совместимости

Достаточно крупные документы также могут превысить бюджет. На данном этапе разумным подходом является создание независимых больших очередей для файлов или точок ручной обработки, а не ослабление всех ограничений по задачам.

Увеличение бизнес-квоты арендатора не означает разрешение на неограниченную декомпрессию всех задач. Ограничения должны быть изолированы от выполнения и нельзя записывать только рядом с кнопкой загрузки.

Различайте, в каком положении неудача переноса слоя

При подготовке отправки документов в OmniDoc (запись продукта) сначала отделите повреждение контейнера от неудачи перевода. DOCX, который даже не может читать XML, может столкнуться с проблемами на этапе подготовки ввода. Чёткий отчёт о предварительной инспекции позволяет пользователям узнать, стоит ли повторно экспортировать, сжимать изображения или обращаться в переводческие службы для устранения неполадок.

📊 Сравнение ядра

🎯 Какой способ тебе подходит?

Если вам нужно получить пользовательский DOCX или EPUB,

В точке входа одновременно проверяйте объём сжатия, количество записей, размер отдельных элементов и общее расширение перед последующей обработкой.

Если вы в основном полагаетесь на оглавление для проверки,

Используйте таблицу каталогов как метод предварительного отклонения, одновременно собирайте байты, прочитанные при фактической извлечении, устанавливая бюджеты времени и памяти.

Если вы часто сталкиваетесь с достаточно крупными документами

Предоставляйте независимые большие очереди файлов или точки ручной обработки для этих документов; не отключайте все ограничения ради совместимости.

Если вы готовы отправить документы в OmniDoc

Во-первых, различайте повреждение контейнера от неудачи трансляции. Проблемы, выявленные на этапе предварительной инспекции, могут быть сообщены пользователям как можно раньше.

❓ Часто задаваемые вопросы (FAQ)

1. Можно ли напрямую использовать размер таблицы каталогов для определения безопасности файлов?

Нельзя полностью на него полагаться. Заявленный размер, предоставляемый ZipInfo, подходит для предварительного отбора, но фактическое извлечение всё равно требует накопления байтов чтения и настройки времени и бюджета памяти.

2. Почему сжатый пакет такой маленький, но после распаковки он может быть довольно большим?

И DOCX, и EPUB используют ZIP в качестве контейнера; маленький сжатый пакет не означает, что размер после расширения тоже мал. Поэтому необходимо ограничить общий объём развертывания.

3. Как следует обращаться с крупными документами, которые превышают бюджет?

Достаточно крупные документы также могут превышать бюджет, предоставляя отдельные большие очереди файлов или точки ручной обработки вместо закрытия всех ограничений.

4. Когда перевод не удаётся, как определить, где кроется проблема?

Во-первых, различайте повреждение контейнера от неудачи трансляции. DOCX, который даже не может читать XML, может столкнуться с проблемами на этапе подготовки вводных данных. Чёткий отчёт о предварительной проверке помогает пользователям решить, экспортировать ли их повторно, сжать изображения или обращаться в службу перевода для устранения неполадок.

📝 Краткое содержание

Лимит декомпрессии ZIP на записи должен одновременно охватывать объем сжатия, количество записей, размер отдельных элементов и общую величину расширения, а также накопленные проверки во время выполнения. Чёткая подсказка пользователям по следующему шагу при отказе облегчает решение проблемы.

Опыт сейчас: загрузите документ, чтобы начать перевод, сохраняя оригинальное форматирование