Avant de traiter DOCX et EPUB, définissez un budget pour la décompression ZIP

Lorsqu'il s'agit de DOCX et EPUB, de nombreux problèmes surviennent déjà lors de la phase de décompression. DOCX est essentiellement un ensemble d'entrées ZIP, et EPUB utilise également un conteneur ZIP, donc la petite taille du fichier ne signifie pas qu'il sera plus petit après la décompression. Cet article est destiné aux développeurs et au personnel d'exploitation et de maintenance qui doivent recevoir des documents Office ou des livres électroniques et effectuer un traitement ultérieur. Il explique comment définir un budget pour la décompression ZIP à l'entrée.

Après avoir lu ceci, vous pouvez déterminer quelles restrictions doivent être placées à l'entrée, comment renvoyer des informations de refus exploitables à l'utilisateur et comment distinguer les problèmes de conteneur des problèmes de traduction en cas d'échec de la traduction. Les exemples de cet article sont illustrés à l'aide d'échantillons synthétiques et le code a passé avec succès des contrôles d'échantillons dans un environnement isolé, mais cela ne signifie pas qu'il est valide pour tous les fichiers réels. Avant de traiter des documents importants, veuillez conserver les originaux et les examiner en fonction des limites et des éléments d'acceptation du texte.

Comment définir un budget pour la décompression ZIP avant le traitement des DOCX et EPUB ? Conclusion en une phrase

Le volume de compression, le nombre d'entrées, la taille des éléments individuels et le montant total de l'expansion doivent être limités au point d'entrée. N'attendez pas que la mémoire soit épuisée pour découvrir des anomalies de fichiers.

Pourquoi devons-nous d'abord examiner la taille agrandie ?

DOCX et EPUB utilisent ZIP comme conteneur. Un fichier de plusieurs centaines de Ko peut prendre beaucoup de place après avoir été décompressé. Si le système ne regardait que la taille du fichier téléchargé, il ne serait pas en mesure de détecter ce type de risque.

Par conséquent, l’inspection à l’entrée doit couvrir simultanément les aspects suivants :

• Volume de compression : Limitez la taille du fichier téléchargé lui-même.
• Nombre d'entrées : limite le nombre de fichiers dans le conteneur.
• Taille d'élément unique : limite la taille développée d'un élément.
• Extension totale : Limite le nombre total d'octets après l'expansion de toutes les entrées.

Vérifiez d'abord la table des matières, mais ne la considérez pas comme une garantie finale

ZipInfo fournit la taille déclarée et la taille compressée, adaptées au présélection. Cela aide le système à rejeter rapidement les fichiers qui dépassent clairement le budget avant décompression.

Cependant, les informations contenues dans la table du répertoire sont déclarées par le fichier lui-même et ne peuvent pas être totalement fiables. Lors de la décompression, vous devez toujours accumuler les octets qui ont été lus et définir le budget de temps et de mémoire. Les tables de catalogue peuvent rejeter des fichiers plus tôt, mais elles ne peuvent pas remplacer les restrictions d'exécution.

Un exemple de pré-sélection sans décompression

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

Les budgets dans cet exemple sont de petites valeurs choisies pour démontrer les chemins de rejet et ne peuvent pas être directement répliqués dans un environnement de production. L'exemple n'appelle pas extractall et n'écrit pas d'entrées ZIP, ce n'est donc pas un décompresseur entièrement sécurisé.

Les entrées chiffrées, les liens symboliques, les archives imbriquées et la consommation de ressources de l'analyseur lui-même nécessitent tous des politiques distinctes.

Références : Python zipfile.

Donner à l'utilisateur des informations exploitables en cas de rejet

Les utilisateurs doivent savoir quoi faire lorsqu'un fichier est rejeté ; des informations de dépannage suffisantes doivent être enregistrées en interne. Le tableau suivant indique les méthodes de traitement correspondantes pour les conditions de déclenchement courantes :

Les explications aux utilisateurs doivent être brèves et claires, évitant une exposition excessive de détails internes ; Les enregistrements internes doivent conserver les noms des limites, les observations et les types d’anomalies pour faciliter le dépannage ultérieur.

Ne ferme pas toutes les restrictions juste pour la compatibilité

Des documents assez volumineux peuvent également dépasser le budget. À ce stade, une approche prudente consiste à fournir de grandes files d’attente indépendantes ou des points d’entrée de traitement manuel, plutôt que d’assouplir toutes les restrictions de tâches.

Augmenter le quota d’affaires d’un locataire ne signifie pas permettre une décompression illimitée de toutes les tâches. Les restrictions doivent être isolées pour l’exécution et ne peuvent pas être écrites uniquement à côté du bouton de téléversement.

Distinguer quelle couche de translation se situe en

Lors de la préparation de la soumission de documents à OmniDoc (entrée produit), il faut d’abord séparer la corruption du conteneur de l’échec de traduction. Un DOCX qui ne peut même pas lire XML peut rencontrer des problèmes lors de la phase de préparation des entrées. Un rapport clair de pré-inspection informe les utilisateurs s’ils doivent réexporter, compresser des images ou utiliser des services de traduction de contacts pour le dépannage.

📊 Comparaison des noyaux

🎯 Quelle méthode te convient ?

Si vous devez recevoir un DOCX ou un EPUB téléchargé par les utilisateurs,

Au point d’entrée, vérifiez simultanément le volume de compression, le nombre d’entrées, la taille individuelle de l’article et l’expansion totale avant de procéder au traitement suivant.

Si tu te fies principalement à la table des matières pour vérifier,

Utilisez la table des répertoires comme méthode de rejet préventif et, en même temps, accumulez les octets lus lors de l’extraction réelle, et fixez les budgets de temps et de mémoire.

Si vous tombez souvent sur des documents assez volumineux

Prévoyez de grandes files d’attente indépendantes ou des points d’entrée de traitement manuel pour ces documents ; ne désactivez pas toutes les restrictions uniquement pour des raisons de compatibilité.

Si vous êtes prêt à soumettre des documents à OmniDoc

Premièrement, distinguez entre dommages au conteneur et défaillance de translation. Les problèmes détectés lors de la phase de pré-inspection peuvent être signalés aux utilisateurs le plus tôt possible.

❓ Foire aux questions (FAQ)

1. La taille dans la table des répertoires peut-elle être directement utilisée pour déterminer la sécurité des fichiers ?

On ne peut pas s’y fier complètement. La taille déclarée fournie par ZipInfo est adaptée au pré-pré-pré-sélection, mais l’extraction réelle nécessite toujours d’accumuler des octets de lecture et de définir le budget temps et mémoire.

2. Pourquoi le boîtier compressé est-il si petit, mais une fois déballé, il peut être assez volumineux ?

DOCX et EPUB utilisent tous deux ZIP comme conteneur ; un petit boîtier compressé ne signifie pas que la taille après expansion est également petite. Il est donc nécessaire de limiter le nombre total de déploiements.

3. Comment devraient-ils gérer les documents volumineux qui dépassent le budget ?

Des documents relativement volumineux peuvent également dépasser le budget, en fournissant de grandes files d’attente séparées ou des points d’entrée de traitement manuel au lieu de supprimer toutes les restrictions.

4. Lorsque la traduction échoue, comment déterminez-vous où réside le problème ?

Premièrement, distinguez entre dommages au conteneur et défaillance de translation. Un DOCX qui ne peut même pas lire XML peut rencontrer des problèmes lors de la phase de préparation des saisies. Un rapport clair de pré-vérification aide les utilisateurs à décider s’ils doivent réexporter, compresser des images ou contacter des services de traduction pour le dépannage.

📝 Résumé

La limite de décompression ZIP à l’entrée doit couvrir simultanément le volume de compression, le nombre d’entrées, la taille individuelle de l’élément et le montant total de l’extension, ainsi que les vérifications cumulatives pendant l’exécution. Donner aux utilisateurs un indice clair pour la prochaine étape lorsqu’ils refusent facilite la résolution du problème.

Faites l’expérience dès maintenant : téléchargez votre document pour commencer à traduire, tout en conservant la mise en forme originale