Je dois autoriser les utilisateurs à télécharger un fichier zip via un formulaire Web. Le serveur exécute Linux avec un serveur Web Apache. Y at-il des avantages à utiliser un module comme Archive::Zip pour extraire cette archive ou dois-je simplement exécuter un appel système à unzip avec des guillemets?Comment puis-je extraire une archive compressée en Perl?
Si vous exécutez la unzip binaire, votre processus fourche/exec et
Vous Il faudra également configurer avec le chemin correct à unzip. Compte tenu de tout cela, je préférerais fortement l'approche de la bibliothèque.
Selon le Archive::Zip documentation vous seriez mieux d'utiliser Archive::Extract:
Si vous allez juste être zips d'extraction (et/ou d'autres archives) Nous vous recommandons de regarder à l'aide Archive :: Extrait à la place, il est beaucoup plus facile à utiliser et exclut les fonctionnalités spécifiques aux archives.
C'est intéressant parce que Archive::Extract will try Archive::Zip first and then fall back to the unzip binary if it fails. Donc, il semble que Archive :: Zip soit l'option préférée.
Archive :: Zip utilise Compress::Raw::Zlib qui est une interface de bas niveau de la bibliothèque système zlib; ce n'est donc pas une implémentation pure de Perl, ce qui signifie que ses performances seront similaires à unzip. Donc, en d'autres termes, du point de vue de la performance, il n'y a aucune raison de choisir unzip avant Archive :: Zip.
Si vous utilisez 'Archive :: Extract', il fonctionnera également pour d'autres formats de compression. –
Une préoccupation concerne la mémoire. Nous avons trouvé à la dure (plantage du serveur web de production) que Archive::Tar avait une fuite de mémoire. Donc, bien que l'utilisation globale d'un module au lieu d'un appel système à une commande externe soit une bonne idée (voir les autres réponses pour le raisonnement), vous devez vous assurer que le module n'a pas de pièges.
Je ne comprends jamais ce genre de pensée. Un fork/exec est un processus très rapide, toute personne qui a passé du temps à lire ou à écrire des scripts shell est consciente de cela. La mémoire consommée par le binaire unzip lui-même est triviale par rapport aux coûts de l'algorithme et (surtout) les données qu'il contient. Et/usr/bin/unzip est livré par défaut sur toutes les distributions Linux, et je crois que BSD et Cygwin aussi. Sauf si vous avez un exemple de code aussi trivial que: 'open my $ input," unzip -cp $ ARCHIVE $ FILE | "', je préférerais fortement l'option simple. –
Bien que je sois d'accord avec * généralement * ci-dessus, si vous avez un serveur fortement chargé, alors votre consommation de ressources augmentera avec le modèle fork/exec. L'allocation pid, l'allocation de flux inter-processus, l'allocation de mémoire (permettant la copie-sur-écriture). Pour les processus autonomes, je suis satisfait du modèle fork/exec. Pour les modèles de serveurs, je préfère éviter cela pour le modèle avec le moins d'allocation de ressources. –
Si vous êtes en boucle, en particulier une boucle chaude, vous verrez absolument des problèmes de performance. Si vous n'êtes pas dans une boucle, ou si vous forgez au rythme d'une fois par seconde ou une fois toutes les quelques secondes, alors pas de problème. En outre, l'utilisation d'une bibliothèque à la place de la commande système 'unzip' peut être un avantage; la bibliothèque peut être plus récente et moins buggée. –