Antes de processar DOCX e EPUB, defina um orçamento para descompressão ZIP

Ao lidar com DOCX e EPUB, muitos problemas já surgem durante a fase de descompressão. DOCX é essencialmente um conjunto de entradas ZIP, e o EPUB também usa um contêiner ZIP, portanto, o tamanho pequeno do arquivo não significa que ele será menor após a descompactação. Este artigo é destinado a desenvolvedores e pessoal de operação e manutenção que precisam receber documentos ou e-books do Office e realizar o processamento posterior. Apresenta como definir um orçamento para descompressão ZIP na entrada.

Depois de ler isto, você poderá determinar quais restrições devem ser colocadas na entrada, como retornar informações de negação acionáveis ao usuário e como distinguir problemas de contêiner de problemas de tradução quando a tradução falha. Os exemplos neste artigo são demonstrados usando amostras sintéticas e o código passou nas verificações de amostra em um ambiente isolado, mas isso não significa que seja válido para todos os arquivos reais. Antes de processar documentos importantes, guarde os originais e revise-os de acordo com os limites e itens de aceitação do texto.

Como definir um orçamento para descompressão ZIP antes de processar DOCX e EPUB? Conclusão de uma frase

O volume de compactação, o número de entradas, o tamanho do item individual e a quantidade total de expansão devem ser limitados no ponto de entrada. Não espere até que a memória se esgote antes de descobrir anormalidades nos arquivos.

Por que precisamos analisar primeiro o tamanho expandido?

Tanto DOCX quanto EPUB usam ZIP como contêiner. Um arquivo de várias centenas de KB pode ocupar muito espaço após ser descompactado. Se o sistema olhasse apenas o tamanho do arquivo carregado, não seria capaz de detectar esse tipo de risco.

Portanto, a fiscalização na entrada deve abranger ao mesmo tempo os seguintes aspectos:

• Volume de compactação: Limite o tamanho do próprio arquivo enviado.
• Número de entradas: Limite o número de arquivos dentro do contêiner.
• Tamanho de item único: limite o tamanho expandido de qualquer item.
• Expansão total: Limita o número total de bytes após a expansão de todas as entradas.

Verifique o índice primeiro, mas não tome isso como garantia final

ZipInfo fornece tamanho declarado e tamanho compactado, adequado para pré-triagem. Ajuda o sistema a rejeitar rapidamente arquivos que claramente excedem o orçamento antes da descompactação.

No entanto, as informações na tabela de diretórios são declaradas pelo próprio arquivo e não podem ser totalmente confiáveis. Ao descompactar, você ainda precisa acumular os bytes que foram lidos e definir o tempo e o orçamento de memória. As tabelas de catálogo podem rejeitar arquivos antecipadamente, mas não podem substituir restrições de tempo de execução.

Um exemplo de pré-triagem sem descompressão

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

Os orçamentos neste exemplo são valores pequenos escolhidos para demonstrar caminhos de rejeição e não podem ser replicados diretamente em um ambiente de produção. O exemplo não chama extractall, nem grava entradas ZIP, portanto não é um descompressor totalmente seguro.

Entradas criptografadas, links simbólicos, arquivos aninhados e o consumo de recursos do próprio analisador exigem políticas separadas.

Referências: Python zipfile.

Forneça ao usuário informações acionáveis ao rejeitar

Os usuários precisam saber o que fazer em seguida quando um arquivo for rejeitado; informações suficientes sobre solução de problemas precisam ser registradas internamente. A tabela a seguir fornece os métodos de processamento correspondentes para condições de acionamento comuns:

As explicações aos usuários devem ser breves e claras, evitando exposição excessiva de detalhes internos; Registros internos devem manter nomes de limite, observações e tipos de anomalias para facilitar a resolução de problemas subsequente.

Não feche todas as restrições só pela compatibilidade

Documentos razoavelmente grandes também podem exceder o orçamento. Neste ponto, uma abordagem prudente é fornecer filas grandes independentes de arquivos ou pontos de entrada de processamento manual, em vez de relaxar todas as restrições das tarefas.

Aumentar a cota de negócio de um inquilino não significa permitir a descompressão ilimitada de todas as tarefas. Restrições precisam ser isoladas da execução e não podem ser escritas apenas ao lado do botão de upload.

Distinga qual camada de tradução está falhada em

Ao preparar o envio de documentos para o OmniDoc (Entrada de Produto), primeiro separe a corrupção do contêiner da falha de tradução. Um DOCX que nem sequer consegue ler XML pode ter problemas durante a fase de preparação da entrada. Um relatório pré-inspeção claro informa os usuários se devem reexportar, comprimir imagens ou contatar serviços de tradução para resolução de problemas.

📊 Comparação de Núcleos

🎯 Qual método combina com você?

Se você precisar receber DOCX ou EPUB enviados pelos usuários,

No ponto de entrada, verifique simultaneamente o volume de compressão, número de entradas, tamanho individual do item e expansão total antes de prosseguir para o processamento subsequente.

Se você confia principalmente no sumário para checar,

Use a tabela de diretórios como método de rejeição preventiva e, ao mesmo tempo, acumule os bytes lidos durante a extração real e defina orçamentos de tempo e memória.

Se você frequentemente encontrar documentos razoavelmente grandes

Forneça filas grandes independentes de arquivos ou pontos de entrada de processamento manual para esses documentos; não desative todas as restrições apenas por compatibilidade.

Se você estiver pronto para enviar documentos para a OmniDoc

Primeiro, distinga entre dano no contêiner e falha de translação. Problemas encontrados durante a fase de pré-inspeção podem ser reportados aos usuários o quanto antes.

❓ Perguntas Frequentes (FAQ)

1. O tamanho na tabela de diretórios pode ser usado diretamente para determinar a segurança dos arquivos?

Você não pode confiar nela completamente. O tamanho declarado fornecido pelo ZipInfo é adequado para pré-triagem, mas a extração real ainda exige acumular bytes de leitura e definir o tempo e o orçamento de memória.

2. Por que o pacote comprimido é tão pequeno, mas quando desempacotado, pode ser bastante grande?

Tanto DOCX quanto EPUB usam ZIP como contêiner; um encapsulamento compacto pequeno não significa que o tamanho após a expansão também seja pequeno. Portanto, é necessário limitar o total de implantações.

3. Como devem ser tratados documentos grandes que ultrapassam o orçamento?

Documentos razoavelmente grandes também podem exceder o orçamento, fornecendo filas grandes separadas de arquivos ou pontos de entrada de processamento manual em vez de fechar todas as restrições.

4. Quando a tradução falha, como você determina onde está o problema?

Primeiro, distinga entre dano no contêiner e falha de translação. Um DOCX que nem sequer consegue ler XML pode apresentar problemas durante a fase de preparação da entrada. Um relatório claro de pré-verificação ajuda os usuários a decidir se devem reexportar, comprimir imagens ou fazer serviços de tradução de contatos para resolução de problemas.

📝 Resumo

O limite de descompressão do ZIP na entrada deve cobrir simultaneamente o volume de compressão, número de entradas, tamanho individual do item e quantidade total de expansão, juntamente com verificações acumuladas durante a execução. Dar aos usuários uma dica clara para o próximo passo ao recusar facilita a resolução do problema.

Experimente agora: Envie seu documento para começar a traduzir, preservando a formatação original