Comment éviter qu'une image n'occupe toute la mémoire de la machine dans le portail de téléchargement OCR ?
Le fichier téléchargé ne fait que quelques mégaoctets, mais peut nécessiter beaucoup plus de mémoire que prévu après le décodage. Les images hautement compressibles sont particulièrement sujettes à des jugements de taille de fichier invalides. Le portail OCR doit limiter à la fois la taille des octets et des pixels téléchargés, ainsi que la mémoire de la couche d'exécution, le temps et le budget de simultanéité.
Le fichier téléchargé ne fait que quelques mégaoctets, mais après décodage, il peut occuper beaucoup plus de mémoire que prévu. Les images hautement compressibles sont particulièrement susceptibles d'invalider les jugements sur la taille des fichiers, donc le simple fait de regarder la taille du fichier n'est pas fiable.
Cet article est destiné aux développeurs responsables des portails de téléchargement, du traitement d'images ou de l'intégration OCR. Au moment où vous aurez fini de lire, vous comprendrez pourquoi vous devez limiter à la fois les octets et les pixels de téléchargement, comment définir un budget sans désactiver la protection de la bibliothèque et pourquoi vous avez également besoin de limites de mémoire, de temps et de concurrence pour la couche d'exécution.
Les valeurs de code et de budget présentées dans cet article sont vérifiées à l'aide d'échantillons synthétiques. Ils illustrent uniquement des idées de traitement et ne représentent pas une garantie de tous les fichiers réels ou effets du produit. 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 éviter que l'entrée de téléchargement d'image ne soit consommée ? Conclusion en une phrase
Limitez également la taille des octets et des pixels téléchargés et définissez les budgets de mémoire, de temps et de simultanéité au niveau de la couche d'exécution. Ne vous contentez pas de regarder la taille du fichier et ne désactivez pas la protection pour éliminer les avertissements.
| votre situation | Pratiques recommandées | raison |
|---|---|---|
| Déterminez si le téléchargement est sécurisé en fonction uniquement de la taille du fichier. | Limitez la taille des octets et des pixels téléchargés en même temps | Les fichiers image hautement compressibles sont petits et peuvent encore occuper beaucoup plus de mémoire que prévu après le décodage. |
| Un oreiller déclenche une alerte à la bombe de décompression | Définissez votre budget en fonction de votre activité et identifiez les avertissements qui doivent être transformés en refus | Définir directement MAX_IMAGE_PIXELS sur None supprimera une ligne de défense importante |
| Besoin de gérer plusieurs trames ou demandes simultanées | Augmentez le nombre d'images, les pixels accumulés, la mémoire, la durée et la limite de simultanéité | Les exemples d'une seule image ne peuvent pas couvrir les totaux multi-images et les pics de décodage simultanés |
| Les dessins légalement volumineux dépassent le budget par défaut | Suivez un processus clair pour les fichiers volumineux et indiquez aux utilisateurs si les pixels ou les octets dépassent la limite. | Dépasser la limite ne signifie pas que les fichiers sont mauvais, les utilisateurs doivent savoir comment s'ajuster |
Ne désactivez pas la protection pour éliminer les avertissements
Pillow dispose d'un mécanisme de protection contre le nombre de pixels contre les bombes de décompression potentielles. Définir directement MAX_IMAGE_PIXELS sur None peut faire disparaître l'avertissement, mais cela supprime également une ligne de défense importante. Les budgets doivent être définis en fonction de l'entreprise et il doit être clair quels avertissements sont transformés en refus.
Un contrôle d'entrée protégé par une bibliothèque réservée
from io import BytesIO
import warnings
from PIL import Image
def inspect(raw, max_bytes=4096, max_pixels=1000):
if len(raw) > max_bytes:
raise ValueError("upload byte budget")
with warnings.catch_warnings():
warnings.simplefilter("error", Image.DecompressionBombWarning)
with Image.open(BytesIO(raw)) as im:
if im.width * im.height > max_pixels:
raise ValueError("pixel budget")
im.load()
return im.size
stream = BytesIO()
Image.new("RGB", (40, 30), "white").save(stream, format="PNG")
raw = stream.getvalue()
assert len(raw) < 4096
assert inspect(raw, max_pixels=1200) == (40, 30)
try:
inspect(raw, max_pixels=1000)
except ValueError as exc:
assert "pixel" in str(exc)
else:
raise AssertionError("pixel budget not enforced")
Les valeurs budgétaires ne servent qu'à des tests synthétiques. Les exemples traitent d'images uniques et ne couvrent pas les totaux multi-images, les bogues d'encodeur ou les pics de décodage simultanés. L'entrée formelle nécessite également :
- Numéro d'image et limites cumulées de pixels
- Gérer les fichiers non fiables dans un environnement d'exécution isolé
Le refus a des responsabilités différentes de celles de la quarantaine
La limite supérieure des octets téléchargés concerne principalement les charges de réseau et de stockage, la limite supérieure des pixels d'une seule page traite des risques courants liés aux images volumineuses, les limites de mémoire et de temps limitent la consommation réelle d'exécution et la limite supérieure de la concurrence contrôle l'utilisation totale des ressources.
Mais chaque type de contrôle a des angles morts : la limite supérieure d'octets ne peut pas remplacer le jugement de l'échelle de décodage, la limite supérieure de pixel d'une seule page ne peut pas voir l'échelle cumulée de plusieurs images, les limites de mémoire et de temps nécessitent également un retour d'erreur explicable, et la limite supérieure de concurrence nécessite la coopération des files d'attente et de la contre-pression.
Un dépassement de budget n'est pas synonyme de mauvais fichiers
Les dessins légalement grands peuvent également dépasser le budget par défaut. Il devrait être autorisé à suivre le processus explicite des fichiers volumineux, plutôt que de désactiver discrètement toutes les protections.
Expliquez à l'utilisateur si la limite dépassée est en pixels ou en octets, afin qu'il sache s'il doit recadrer la page, réduire la résolution de capture ou choisir une méthode de traitement spécialisée.
Le portail de traduction doit indiquer à l'avance les risques liés à la saisie.
L'ajout de sa propre vérification préalable des entrées avant l'intégration de OmniDoc (portail produit) peut permettre aux grandes images non prises en charge de recevoir des commentaires plus tôt. Le contrôle en amont ne peut pas remplacer les propres limitations de la plateforme, et ne doit pas non plus prétendre que la plateforme a mis en œuvre les politiques décrites dans cet article. Il s'agit d'une couche d'assurance explicable que vous créez entre le téléchargement et la livraison.
Références : Instructions de décompression et de protection de l'image de l'oreiller
📊 Comparaison de base
| contrôle | Principales limites | Il faut encore ajouter |
|---|---|---|
| Limite d'octets de téléchargement | Charge de réseau et de stockage | échelle de décodage |
| Nombre maximum de pixels par page | Risques généraux courants | Échelle cumulative de plusieurs images |
| Limites de mémoire et de temps | Consommation d'exécution réelle | Retour d'erreur explicable |
| Limite de concurrence | Utilisation totale des ressources | Files d'attente et contre-pression |
🎯 Quelle méthode vous convient ?
Si vous êtes responsable du téléchargement de l'entrée
Définissez d'abord la double limite d'octets et de pixels, puis ajoutez le budget de mémoire, de temps et de concurrence de la couche d'exécution.
Si vous rencontrez un avertissement de bombe de décompression d'oreiller
Ne vous contentez pas de désactiver le chèque. Définissez le budget de votre entreprise avant de décider quels avertissements doivent être transformés en rejets.
Si vous devez gérer plusieurs trames ou requêtes simultanées
Complétez le nombre d'images, les pixels accumulés, la mémoire, la limite supérieure de temps et de concurrence, et coopérez avec la file d'attente et la contre-pression.
Si vos utilisateurs téléchargent souvent de grands dessins techniques
Concevez un processus clair pour les fichiers volumineux pour les fichiers qui dépassent la limite et indiquez aux utilisateurs si la limite est dépassée en pixels ou en octets.
❓ Questions fréquemment posées (FAQ)
1. Le fichier téléchargé ne fait que quelques mégaoctets, pourquoi y a-t-il encore un risque ?
La mémoire décodée dépend de la taille de l'image, et les images hautement compressibles sont particulièrement sujettes à des jugements de taille de fichier invalides.
2. MAX_IMAGE_PIXELS peut-il être directement défini sur Aucun ?
Non recommandé. Bien que cela fasse disparaître l’avertissement, cela supprime également une ligne de défense importante pour Pillow.
3. La valeur budgétaire de l'exemple peut-elle être directement utilisée dans l'environnement de production ?
ne peut pas. La valeur budgétaire ne sert qu'aux tests synthétiques, l'entrée formelle nécessite également plusieurs images et limites cumulées de pixels, et gère les fichiers non fiables dans un environnement isolé.
4. Les grandes photos qui dépassent le budget doivent-elles être rejetées directement ?
La protection ne doit pas être désactivée silencieusement. Les dessins techniques légaux à grande échelle peuvent suivre un processus clair pour les fichiers volumineux et indiquer aux utilisateurs si les pixels ou les octets dépassent la limite.
📝Résumé
La sécurité du portail de téléchargement OCR ne dépend pas seulement de la taille du fichier, mais doit également être limitée par les pixels, les octets et le budget de la couche d'exécution. Ce n'est qu'en définissant le budget tout en conservant la protection de la bibliothèque et en expliquant clairement aux utilisateurs les raisons du dépassement de la limite que la stabilité et la disponibilité peuvent être prises en compte.


