Antes de procesar DOCX y EPUB, establezca un presupuesto para la descompresión ZIP

-El valor numérico del ejemplo de este artículo es muy pequeño y solo se usa para demostrar la ruta de rechazo y no se puede usar directamente en el entorno de producción.

• Los documentos razonablemente grandes deben procesarse en una cola separada o manualmente, y no se deben desactivar todas las restricciones por motivos de compatibilidad.

Cuando se trata de DOCX y EPUB, ya surgen muchos problemas durante la etapa de descompresión. DOCX es esencialmente un conjunto de entradas ZIP, y EPUB también usa un contenedor ZIP, por lo que el tamaño pequeño del archivo no significa que será más pequeño después de descomprimirlo. Este artículo está dirigido a desarrolladores y personal de operación y mantenimiento que necesitan recibir documentos de Office o libros electrónicos y realizar un procesamiento posterior. Presenta cómo establecer un presupuesto para la descompresión ZIP en la entrada.

Después de leer esto, podrá determinar qué restricciones se deben colocar en la entrada, cómo devolver información de denegación procesable al usuario y cómo distinguir los problemas del contenedor de los problemas de traducción cuando la traducción falla. Los ejemplos de este artículo se demuestran utilizando muestras sintéticas y el código ha pasado comprobaciones de muestra en un entorno aislado, pero esto no significa que sea válido para todos los archivos reales. Antes de procesar documentos importantes, conserve los originales y revíselos de acuerdo con los límites y elementos de aceptación del texto.

¿Cómo establecer un presupuesto para la descompresión ZIP antes de procesar DOCX y EPUB? Conclusión de una frase

El volumen de compresión, el número de entradas, el tamaño de cada elemento y la cantidad total de expansión deben limitarse en el punto de entrada. No espere hasta que se agote la memoria antes de descubrir anomalías en los archivos.

¿Por qué debemos mirar primero el tamaño ampliado?

Tanto DOCX como EPUB utilizan ZIP como contenedor. Un archivo de varios cientos de KB puede ocupar mucho espacio después de descomprimirlo. Si el sistema solo mirara el tamaño del archivo subido, no sería capaz de detectar este tipo de riesgo.

Por tanto, la inspección en la entrada debe abarcar al mismo tiempo los siguientes aspectos:

• Volumen de compresión: limita el tamaño del archivo cargado.
• Número de entradas: limita el número de archivos dentro del contenedor.
• Tamaño de artículo único: limita el tamaño expandido de cualquier artículo.
• Expansión total: limita el número total de bytes después de la expansión de todas las entradas.

Consulte primero el índice, pero no lo tome como una garantía final

ZipInfo proporciona el tamaño declarado y el tamaño comprimido, adecuados para la selección previa. Ayuda al sistema a rechazar rápidamente archivos que claramente exceden el presupuesto antes de la descompresión.

Sin embargo, la información de la tabla del directorio la declara el propio archivo y no se puede confiar completamente en ella. Al descomprimirlo, aún necesita acumular los bytes que se han leído y establecer el tiempo y el presupuesto de memoria. Las tablas de catálogo pueden rechazar archivos anticipadamente, pero no pueden reemplazar las restricciones de tiempo de ejecución.

Un ejemplo de preselección sin descompresión

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

Los presupuestos en este ejemplo son valores pequeños elegidos para demostrar rutas de rechazo y no se pueden replicar directamente en un entorno de producción. El ejemplo no llama a extractall ni escribe entradas ZIP, por lo que no es un descompresor completamente seguro.

Las entradas cifradas, los enlaces simbólicos, los archivos anidados y el consumo de recursos del propio analizador requieren políticas independientes.

Referencias: Python zipfile.

Proporcionar al usuario información procesable al rechazar

Los usuarios necesitan saber qué hacer a continuación cuando se rechaza un archivo; Es necesario registrar internamente suficiente información sobre solución de problemas. La siguiente tabla proporciona los métodos de procesamiento correspondientes para condiciones de activación comunes:

Las explicaciones a los usuarios deben ser breves y claras, evitando la exposición excesiva de detalles internos; Los registros internos deben conservar nombres límite, observaciones y tipos de anomalías para facilitar la posterior resolución de problemas.

No cierres todas las restricciones solo por compatibilidad

Documentos razonablemente grandes también pueden superar el presupuesto. En este punto, un enfoque prudente es proporcionar colas grandes de archivos independientes o puntos de entrada de procesamiento manual, en lugar de relajar todas las restricciones de tareas.

Aumentar la cuota de negocio de un inquilino no significa permitir la descompresión ilimitada de todas las tareas. Las restricciones deben aislarse de la ejecución y no pueden escribirse solo junto al botón de subida.

Distinguir qué capa está fallando en la traducción

Al prepararse para enviar documentos a OmniDoc (Entrada de producto), primero separa la corrupción del contenedor de la falla de traducción. Un DOCX que ni siquiera puede leer XML puede tener problemas durante la fase de preparación de entrada. Un informe claro de preinspección informa a los usuarios si deben reexportar, comprimir imágenes o contactar con los servicios de traducción para la resolución de problemas.

📊 Comparación de núcleos

🎯 ¿Qué método te conviene?

Si necesitas recibir DOCX o EPUB subidos por usuarios,

En el punto de entrada, comprueba simultáneamente el volumen de compresión, el número de entradas, el tamaño individual del ítem y la expansión total antes de proceder al procesamiento posterior.

Si principalmente confías en el índice para comprobar,

Utiliza la tabla de directorios como método de rechazo preventivo y, al mismo tiempo, acumula los bytes leídos durante la extracción real y establece presupuestos de tiempo y memoria.

Si a menudo te encuentras con documentos razonablemente grandes

Proporciona colas grandes de archivos independientes o puntos de entrada de procesamiento manual para estos documentos; no desactives todas las restricciones solo por compatibilidad.

Si estás listo para enviar documentos a OmniDoc

Primero, distinguir entre daño en el contenedor y fallo de traslación. Los problemas detectados durante la fase previa a la inspección pueden ser reportados a los usuarios lo antes posible.

❓ Preguntas frecuentes (FAQ)

1. ¿Se puede usar directamente el tamaño en la tabla de directorios para determinar la seguridad de los archivos?

No puedes confiar completamente en ella. El tamaño declarado proporcionado por ZipInfo es adecuado para la pre-selección, pero la extracción real aún requiere acumular bytes de lectura y establecer el presupuesto de tiempo y memoria.

2. ¿Por qué el paquete comprimido es tan pequeño, pero cuando se desempaqueta puede ser bastante grande?

Tanto DOCX como EPUB utilizan ZIP como contenedor; un encapsulado pequeño comprimido no significa que el tamaño tras la expansión también sea pequeño. Por lo tanto, es necesario limitar la cantidad total de despliegues.

3. ¿Cómo deberían gestionarse los documentos grandes que superan el presupuesto?

Los documentos razonablemente grandes también pueden superar el presupuesto, proporcionando colas de archivos grandes separadas o puntos de entrada de procesamiento manual en lugar de cerrar todas las restricciones.

4. Cuando la traducción falla, ¿cómo determinas dónde está el problema?

Primero, distinguir entre daño en el contenedor y fallo de traslación. Un DOCX que ni siquiera puede leer XML puede tener problemas durante la fase de preparación de la entrada. Un informe claro de pre-check ayuda a los usuarios a decidir si reexportar, comprimir imágenes o hacer servicios de traducción de contactos para la resolución de problemas.

📝 Resumen

El límite de descompresión de ZIP en la entrada debe cubrir simultáneamente el volumen de compresión, el número de entradas, el tamaño individual del elemento y la cantidad total de expansión, junto con comprobaciones acumulativas durante la ejecución. Dar a los usuarios una pista clara sobre el siguiente paso cuando se niegan facilita la resolución del problema.

Experiencia ahora: Sube tu documento para empezar a traducir, conservando el formato original