DOCX 및 EPUB를 처리하기 전에 ZIP 압축 해제에 대한 예산을 설정합니다.

DOCX 및 EPUB를 다룰 때 압축 해제 단계에서 이미 많은 문제가 발생합니다. DOCX는 기본적으로 ZIP 항목 집합이고 EPUB도 ZIP 컨테이너를 사용하므로 파일 크기가 작다고 해서 압축을 푼 후에도 파일 크기가 작아지는 것은 아닙니다. 이 문서는 Office 문서나 전자책을 받아 후속 처리를 수행해야 하는 개발자와 운영 및 유지 관리 담당자를 대상으로 합니다. 입구에서 ZIP 압축해제 예산 설정 방법을 소개합니다.

이 내용을 읽은 후에는 입구에 어떤 제한을 두어야 하는지, 실행 가능한 거부 정보를 사용자에게 반환하는 방법, 번역 실패 시 컨테이너 문제와 번역 문제를 구별하는 방법을 결정할 수 있습니다. 이 문서의 예제는 합성 샘플을 사용하여 시연되었으며 코드는 격리된 환경에서 샘플 검사를 통과했지만 이것이 모든 실제 파일에 유효하다는 의미는 아닙니다. 중요한 서류를 처리하기 전, 원본을 보관하시고, 본문에 기재된 경계 및 허용 항목에 따라 검토하시기 바랍니다.

DOCX 및 EPUB를 처리하기 전에 ZIP 압축 해제 예산을 어떻게 설정하나요? 한 문장 결론

압축량, 항목 수, 개별 항목 크기 및 총 확장량은 진입점에서 제한되어야 합니다. 파일 이상을 발견하기 전에 메모리가 모두 소모될 때까지 기다리지 마십시오.

확장된 크기를 먼저 살펴봐야 하는 이유는 무엇인가요?

DOCX와 EPUB는 모두 ZIP을 컨테이너로 사용합니다. 수백 KB의 파일은 압축을 푼 후 많은 공간을 차지할 수 있습니다. 시스템이 업로드된 파일의 크기만 본다면 이러한 유형의 위험을 감지할 수 없습니다.

따라서 입구 검사에서는 다음 측면을 동시에 다루어야 합니다.

• 압축량: 업로드되는 파일 자체의 크기를 제한합니다.
• 항목 수: 컨테이너 내의 파일 수를 제한합니다.
• 단일 항목 크기: 한 항목의 확장된 크기를 제한합니다.
• 총 확장: 모든 항목을 확장한 후 총 바이트 수를 제한합니다.

목차를 먼저 확인하세요. 하지만 최종 보증으로 받아들이지는 마세요.

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(제품 포털)에 문서 제출을 준비할 때 먼저 번역 실패와 컨테이너 손상을 분리하세요. XML을 읽을 수도 없는 DOCX의 경우 입력 준비 단계에서 문제가 발생할 수 있습니다. 명확한 실행 전 보고서를 통해 사용자는 이미지를 다시 내보내야 하는지, 이미지를 압축해야 하는지, 문제 해결을 위해 번역 서비스에 문의해야 하는지 알 수 있습니다.

📊 핵심 비교

🎯 어떤 방법이 당신에게 적합합니까?

사용자가 업로드한 DOCX 또는 EPUB를 받아야 하는 경우

입구에서는 압축량, 진입횟수, 단품크기, 총팽창량을 동시에 확인 후 후속처리에 진입합니다.

주로 디렉터리 테이블에 의존하여 확인하는 경우

실제 압축 해제 중에 읽은 바이트를 누적하고 시간 및 메모리 예산을 설정하는 동시에 조기 거부 수단으로 디렉터리 테이블을 사용합니다.

상당히 큰 문서를 자주 접하는 경우

이러한 문서에 대해서는 별도의 대용량 파일 대기열이나 수동 처리 입구를 제공하고, 호환성을 위해 모든 제한을 해제하지 마십시오.

OmniDoc에 문서를 제출할 준비가 되었다면

먼저 컨테이너 손상과 번역 실패를 구별하세요. 사전 점검 단계에서 발견될 수 있는 문제는 최대한 빨리 사용자에게 보고될 수 있습니다.

❓ 자주 묻는 질문(FAQ)

1. 디렉터리 테이블의 크기를 직접 사용하여 파일이 안전한지 확인할 수 있나요?

완전히 신뢰할 수는 없습니다. ZipInfo에서 제공하는 선언 크기는 사전 스크리닝에 적합하지만, 실제 압축 해제 중에 읽은 바이트를 누적하고 시간 및 메모리 예산을 설정하는 것이 여전히 필요합니다.

2. 압축된 패키지는 매우 작지만 압축을 푼 후에는 매우 커질 수 있는 이유는 무엇입니까?

DOCX와 EPUB는 모두 ZIP을 컨테이너로 사용합니다. 압축된 패키지의 크기가 작다고 해서 확장된 볼륨도 작다는 의미는 아닙니다. 따라서 총 증설량을 제한할 필요가 있다.

3. 예산을 초과하는 대용량 문서는 어떻게 처리하나요?

합리적으로 큰 문서도 예산을 초과할 수 있으며, 모든 제한을 해제하는 대신 별도의 대용량 파일 대기열 또는 수동 처리 입구를 제공할 수 있습니다.

4. 번역이 실패하면 문제가 있는 레이어를 어떻게 확인할 수 있나요?

먼저 컨테이너 손상과 번역 실패를 구별하세요. XML을 읽을 수도 없는 DOCX의 경우 입력 준비 단계에서 문제가 발생할 수 있습니다. 명확한 사전 확인 보고서는 사용자가 이미지를 다시 내보낼지, 압축할지, 문제 해결을 위해 번역 서비스에 문의할지 결정하는 데 도움이 될 수 있습니다.

📝 요약

항목의 ZIP 압축 해제 제한은 압축된 볼륨, 항목 수, 개별 항목 크기 및 총 확장 양을 모두 포함해야 하며 런타임 시 누적 검사와 협력해야 합니다. 거부 시 사용자에게 명확한 다음 단계 프롬프트를 제공하면 문제를 더 쉽게 해결할 수 있습니다.

지금 사용해 보세요: 원본 레이아웃을 유지하면서 번역을 시작하려면 문서를 업로드하세요.