| WGET(1) | GNU Wget | WGET(1) |
Wget - L'outil de téléchargement réseau non interactif.
wget [option]... [URL]...
GNU Wget est un utilitaire libre pour le téléchargement non-interactif de fichiers sur le Web. Il prend en charge les protocoles HTTP, HTTPS, et FTP, ainsi que le téléchargement au travers des mandataires HTTP.
Wget est non interactif, c'est-à-dire qu'il peut travailler en arrière-plan, sans intervention de l'utilisateur. Cela permet de lancer un téléchargement et de se déconnecter du système, laissant wget finir le travail. En revanche, la plupart des navigateurs Web requièrent la présence constante de l'utilisateur, ce qui est particulièrement pénible lorsqu'il y a beaucoup de données à transférer.
wget peut suivre les liens des pages HTML et XHTML, et CSS, pour créer des copies locales de sites web distants, en récréant complètement la structure du site original. Cela est parfois désigné sous le nom de « téléchargement récursif ». En faisant cela, wget respecte le standard d'exclusion de robots (/robots.txt). wget peut aussi être chargé de convertir les liens dans les fichiers téléchargés pour pointer sur des fichiers locaux, pour une consultation hors-ligne.
wget a été conçu pour être robuste en dépit des connexions réseaux lentes ou instables ; si un téléchargement échoue suite à un problème réseau, il réessayera jusqu'à ce que l'intégralité du fichier soit récupérée. Si le serveur gère la reprise, il lui demandera de reprendre là où le téléchargement s'est interrompu.
Comme wget utilise GNU getopt pour traiter les arguments de la ligne de commande, chaque option a une forme longue en plus de la forme courte. Les options longues sont plus pratiques à retenir, mais prennent du temps à taper. Vous êtes libre de mélanger différentes formes d'options, ou d'indiquer les options après les arguments de la ligne de commande. Ainsi, vous pouvez écrire :
wget -r --tries=10 http://fly.srk.fer.hr/ -o log
L'espace entre l'option acceptant un argument et l'argument peut être omise. Vous pouvez écrire -olog au lieu de -o log.
Vous pouvez mettre ensemble plusieurs options ne nécessitant pas d'arguments, comme :
wget -drc <URL>
Cela est absolument équivalent à :
wget -d -r -c <URL>
Comme les options peuvent être indiquées après les arguments, vous pouvez les terminer avec --. Ainsi, ce qui suit va essayer de télécharger URL -x, en signalant l'échec à log :
wget -o log -- -x
Les options qui acceptent des listes séparées par des virgules respectent toutes la convention selon laquelle spécifier une liste vide efface sa valeur. Cela peut être utile pour nettoyer les réglages de .wgetrc. Par exemple, si .wgetrc indique "exclude_directories" à /cgi-bin, l'exemple suivant le réinitialisera d'abord, puis lui indiquera d'exclure /~nobody et /~somebody. Vous pouvez aussi effacer les listes dans .wgetrc.
wget -X "" -X /~nobody,/~somebody
La majorité des options qui n'acceptent pas d'arguments sont des options de type booléen, ainsi nommées car leur état peut être capturé avec une variable oui-ou-non (« booléenne »). Par exemple, --follow-ftp indique à wget de suivre les liens FTP de fichiers HTML et, d'un autre coté, --no-glob lui dit de ne pas effectuer le « globbing » de fichiers sur les URL FTP. Une option booléenne peut être affirmative ou négative (commençant par --no). Toutes ces options partagent plusieurs propriétés.
Sauf indication contraire, il est supposé que le comportement par défaut soit l'opposé de ce que l'option réalise. Par exemple, l'existence documentée de --follow-ftp suppose que le comportement par défaut est de ne pas suivre les liens FTP des pages HTML.
Les options affirmatives peuvent être niées en antéposant le --no au nom de l'option ; les options négatives peuvent être niées en ommettant le préfixe --no. Cela peut sembler superflu : si le comportement par défaut d'une option affirmative est de ne pas faire quelque chose, alors pourquoi lui fournir un moyen pour le faire ? Mais le fichier de démarrage peut en fait changer le comportement par défaut. Par exemple, l'utilisation de "follow_ftp = on" dans .wgetrc fait suivre les liens FTP à wget par défaut, et l'utilisation de --no-follow-ftp est la seule manière de restaurer le comportement par défaut d'origine depuis la ligne de commande.
Si cette fonction est utilisée, aucune URL n'a besoin d'être présente sur la ligne de commande. S'il y a des URL à la fois sur la ligne de commande et dans le fichier d'entrée, celles sur la ligne de commande seront les premières à être extraites. Si --force-html n'est pas indiqué, alors le fichier devrait consister en une suite d'URL, une par ligne.
Cependant, si vous indiquez --force-html, le document sera considéré comme html. Dans ce cas, vous pourriez avoir des problèmes avec les liens relatifs, que vous pouvez résoudre en ajoutant « <base href=url> » aux documents ou en indiquant --base=url sur la ligne de commande.
Si le fichier est externe, le document sera automatiquement traité comme du html si le type de contenu correspond à text/html. Par ailleurs, l'emplacement du fichier sera implicitement utilisé comme href de base si aucun n'est indiqué.
Gardez à l'esprit que les URL pourraient contenir des informations privées telles que des jetons d'accès ou des identifiants.
Par exemple, si vous indiquez http://machin/truc/a.html comme URL, et que wget lit ../bidule/b.html sur le fichier d'entrée, il sera résolu en http://machin/bidule/b.html.
L'utilisation de -O ne signifie pas simplement « utiliser le nom fichier au lieu de celui dans l'URL ». Cela est plutôt similaire à une redirection d'interpréteur : wget -O fichier http://truc est destiné à fonctionner comme wget -O - http://truc > fichier . fichier sera tronqué immédiatement et tout le contenu téléchargé sera écrit là.
Pour cette raison, -N (pour le contrôle d'horodatage) n'est pas pris en charge en combinaison avec -O : dans la mesure où fichier est tout le temps nouvellement créé, il aura toujours un horodatage très récent. Un avertissement sera affiché si la combinaison des deux est utilisée.
De même, l'utilisation de -r ou -p avec -O peut ne pas fonctionner comme vous voudriez : wget ne téléchargera pas seulement le premier fichier dans fichier et ensuite le reste dans leurs noms courants : tout le contenu téléchargé sera placé dans fichier. Cela a été désactivé dans la version 1.11, mais a été réimplanté (avec un avertissement) dans la version 1.11.2, puisqu'il y a des cas où ce fonctionnement peut avoir une certaine utilité.
Une combinaison avec -nc n'est acceptée que si le fichier donné en sortie n'existe pas.
Remarquez qu'une combinaison avec -k n'est permise que lors du téléchargement d'un seul document, car dans ce cas il convertira seulement toutes les URl relatives en URL externes ; -k n'a pas de sens pour des URl multiples lorsqu'elles sont toutes téléchargées dans un seul fichier ; -k ne peut être utilisé que lorsque la sortie est un fichier normal.
Lorsque wget est lancé sans -N, -nc, -r ou -p, le téléchargement du même fichier dans le même répertoire préservera la copie d'origine de fichier et la seconde copie sera nommée fichier.1. Si ce fichier est à nouveau téléchargé, la troisième copie sera nommée fichier.2, et ainsi de suite. (Cela est aussi le comportement avec -nd, même si -r ou -p sont effectifs.) Lorsque -nc est spécifié, ce comportement est supprimé, et wget refusera de télécharger de nouvelles copies de fichier. Par conséquent, « no-clobber » est en fait un terme mal choisi dans ce mode -- ce n'est pas la corruption qui est empêchée (comme les suffixes numériques empêchent déjà la corruption), mais plutôt l'enregistrement de plusieurs versions qui est empêché.
Lorsque wget est lancé avec -r ou -p, mais sans -N, -nd ou -nc, télécharger à nouveau un fichier résultera en ce que la nouvelle copie écrasera simplement la précédente. Ajouter -nc empêchera ce comportement, provoquant plutôt la préservation de la version originale et faisant que les copies plus récentes sur le serveur seront ignorées.
Lors du lancement de wget avec -N, avec ou sans -r ou -p, la décision de télécharger ou non une copie plus récente d'un fichier dépend de l'horodatage local et distant et de la taille du fichier. -nc peut ne pas être spécifié au même moment que -N.
Une combinaison avec -O/--output-document n'est acceptée que si le fichier donné en sortie n'existe pas.
Notez que lorsque -nc est spécifié, les fichiers avec les suffixes .html ou .htm seront chargés depuis le disque local et analysés comme s'ils avaient été récupérés sur le Web.
wget -c ftp://sunsite.doc.ic.ac.uk/ls-lR.Z
S'il y a un fichier nommé ls-lR.Z dans le répertoire actuel, wget supposera qu'il s'agit de la première partie du fichier distant, et demandera au serveur de poursuivre la récupération à partir d'un décalage égal à la longueur du fichier local.
Remarquez que vous n'avez pas besoin d'indiquer cette option si vous voulez simplement que l'invocation actuelle de wget réessaie de télécharger un fichier si la connexion est perdue en cours de route. C'est le comportement par défaut. -c n'affecte que la reprise des téléchargements commencés avant cette invocation de wget, et dont les fichiers locaux sont toujours en attente.
Sans -c, l'exemple précédent devrait juste télécharger le fichier distant dans ls-lR.Z.1, laissant seul le fichier tronqué ls-lR.Z.
Si vous utilisez -c sur un fichier non vide, et que le serveur ne prend pas en charge la reprise du téléchargement, wget relancera le téléchargement depuis le début et écrasera entièrement le fichier existant.
À partir de Wget 1.7, si vous utilisez -c sur un fichier ayant une taille égale à celui sur le serveur, wget refusera de télécharger le fichier et affichera un message explicatif. La même chose arrive lorsque le fichier est plus petit sur le serveur que celui en local (probablement parce qu'il a été modifié depuis votre dernière tentative de téléchargement) -- parce que « continuing » n'est pas assez explicite, aucun téléchargement n'est lancé.
D'un autre coté, en utilisant -c, tout fichier qui est plus gros sur le serveur qu'en local sera considéré comme un téléchargement incomplet et seulement (longueur(distante) - longueur(locale)) octets seront téléchargés et ajoutés à la fin du fichier local. Ce comportement est appréciable dans quelques cas. Par exemple, vous pouvez utiliser wget -c pour télécharger uniquement la nouvelle partie qui a été ajoutée à une collection de données ou à un fichier journal.
En tout cas, si le fichier est plus gros sur le serveur parce qu'il a été modifié, contrairement à juste ajouté, vous vous retrouverez avec un fichier brouillé. wget n'a pas la possibilité de vérifier que le fichier local est réellement un début valable du fichier distant. Vous devez être particulièrement attentif à cela lors de l'utilisation de -c en combinaison avec -r, vu que tout fichier sera considéré comme un « téléchargement incomplet » potentiel.
Un autre cas où vous obtiendrez un fichier brouillé si vous essayez d'utiliser -c, est celui où vous avez un mandataire HTTP bancal qui insère une chaîne "transfer interrupted") dans le fichier local. Dans le futur, une option "rollback" (retour à l'état précédent) devrait être ajoutée pour gérer ce cas de figure.
Prenez en compte que -c ne fonctionne qu'avec les serveurs FTP et les serveurs HTTP qui prennent en charge l'en-tête "Range".
--start-pos a la priorité sur --continue. Lorsque --start-pos et --continue sont toute deux indiquées, wget émettra un avertissement et procèdera comme si --continue était absent.
La prise en charge du serveur pour la poursuite du téléchargement est nécessaire, sinon --start-pos ne pourra pas aider. Voir -c pour les détails.
L'indicateur "bar" est utilisé par défaut. Il dessine un graphique de barre de progression ASCII (comme un affichage « thermomètre ») indiquant l'état de la récupération. Si la sortie n'est pas une console TTY, la barre de progression « dot » sera utilisée par défaut.
Utilisez --progress=dot pour passer à l'affichage "pointillé"). Il retrace la récupération en affichant des points sur l'écran, chaque point représentant une quantité fixe de données téléchargées.
Le type de progression peut aussi prendre un ou plusieurs paramètres. Les paramètres varient suivant le type sélectionné. Les paramètres sont passés au type en les ajoutant au type, séparés par un deux-points ( : ) comme ceci : --progress=type:paramètre1:paramètre2.
Lorsque vous utilisez la représentation de la récupération par points, vous pouvez définir le style en spécifiant le type comme dot:style. Les différents styles assignent différents rôles à un point. Avec le style « default » chaque point représente 1Ko, il y a dix points par grappe et 50 points sur une ligne. Le style « binary » a plus une orientation du genre « ordinateur » : points de 8Ko, 16 points par grappe et 48 points par ligne (ce qui fait des lignes de 384Ko). Le style « mega » est adapté au téléchargement de gros fichiers : chaque point représentant 64Ko de récupération, il y a huit points dans une grappe, et 48 points sur chaque ligne (chaque ligne contenant 3Mo). Si « mega » n'est pas suffisant, alors vous pouvez utiliser le style « giga » -- chaque point représente 1 Mo récupérés, il y a huit points par grappe, et 32 points par ligne (donc chaque ligne contient 32Mo).
Avec --progress=bar, il y a actuellement deux paramètres possibles, force et noscroll.
Lorsque la sortie n'est pas une console TTY, la barre de progression retombe toujours sur "dot", même si --progress=bar a été passé à wget lors de l'invocation. Ce comportement peut être outrepassé et la sortie "bar" forcée avec le paramètre "force" comme --progress=bar:force.
Par défaut, la barre de progression du style bar fait défiler le nom du fichier de gauche à droite pour le fichier en cours de téléchargement si le nom du fichier dépasse la longueur maximale allouée à son affichage. Dans certains cas, comme avec --progress=bar:force, il peut ne pas y avoir de défilement du nom de fichier dans la barre de progression. En passant le paramètre "noscroll", wget peut être forcé à afficher la plus grande partie possible du nom de fichier sans le faire défiler.
Remarquez que vous pouvez indiquer le style par défaut en utilisant la commande "progress" dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande. Par exemple, pour forcer la barre de sortie à ne pas défiler, utilisez --progress=bar:force:noscroll.
Par défaut, wget affiche seulement la barre de progression en mode détaillé. Il est possible de vouloir que wget affiche la barre de progression en accord avec un autre mode de détail comme --no-verbose ou --quiet. Cela peut être désirable lors de l'invocation de wget pour télécharger plusieurs petits et/ou grands fichiers. Dans un tel cas, wget pourrait simplement être invoqué avec ce paramètre pour avoir une sortie plus propre sur l'écran.
Cette option forcera également la barre de progression à être affichée dans stderr lorsqu'elle est utilisée avec l'option --output-file.
Par défaut, lorsqu'un fichier est téléchargé, son horodatage est réglé pour correspondre à celui du fichier distant. Cela permet l'utilisation de --timestamping sur les invocations suivantes de wget. Cependant, il est parfois nécessaire de baser l'horodatage du fichier local sur celui de son téléchargement ; l'option --no-use-server-timestamps a été fournie dans ce but.
wget --spider --force-html -i marque-pages.html
Cette caractéristique nécessite encore quelques travaux pour se rapprocher des fonctionnalités de véritables robots d'indexation.
Lorsqu'il interagit avec le réseau, wget peut vérifier le délai d'attente et annuler l'opération si cela dure trop. Cela permet d'éviter les anomalies telles que les lectures suspendues et les connexions infinies. Le seul délai d'attente activé par défaut est un délai d'attente de lecture de 900 secondes (15 min). Définir un délai d'attente à 0 désactive l'ensemble. À moins de savoir ce que vous faites, il vaut mieux ne pas changer les réglages du délai d'attente par défaut.
Toutes les options liées au délai d'attente acceptent les valeurs décimales, ainsi que les valeurs en dixième de seconde. Par exemple, 0.1 seconde est un choix classique (bien que peu judicieux) du délai d'attente. Les temps d'attente en dixièmes de seconde sont utiles pour la vérification des temps de réponse du serveur ou pour tester la latence du réseau.
Bien sûr, le serveur distant peut choisir de terminer la connexion plus tôt que requis par cette option. Le délai de lecture est de 900 secondes (15 min) par défaut.
Cette option autorise l'usage de nombres décimaux, habituellement en conjonction avec des suffixes de puissance ; par exemple, --limit-rate=2.5k est une valeur classique.
Remarquez que wget implémente la limitation en dormant pendant la durée appropriée après une réception depuis le réseau qui a pris moins de temps que spécifié par le débit. Finalement cela peut causer le ralentissement du tranfert TCP jusqu'à approximativement le débit spécifié. Cependant, il se peut que cela prenne un peu de temps avant de se stabiliser ; ne soyez pas surpris si cette limite n'est pas vraiment respectée lors du transfert de très petits fichiers.
L'indication d'une grande valeur pour cette option est pratique si le réseau ou l'hôte de destination est éteint, ainsi wget peut attendre assez longtemps pour raisonnablement espérer que l'erreur réseau soit réparée d'ici le prochain essai. L'intervalle de temps d'attente indiqué par cette fonction est influencé par "--random-wait" qui surveille.
Par défaut, wget prendra une valeur de dix secondes.
Un article est paru en 2001 dans une publication consacrée au développement sur une plate-forme populaire grand public qui fournissait un code permettant d'effectuer cette analyse à la volée. Son auteur a suggéré un blocage au niveau des adresses de classe C pour s'assurer que les programmes d'extraction automatique soient bloqués malgré le changement des adresses fournies par le DHCP.
L'option --random-wait a été inspirée par cette recommandation peu judicieuse qui consiste à bloquer l'accès à un site web à de nombreux utilisateurs non concernés en raison des actions d'un seul.
Remarquez que le quota n'affectera jamais le téléchargement d'un seul fichier. Donc si vous indiquez wget -Q10k https://example.com/ls-lR.gz, tout le fichier ls-lR.gz sera téléchargé. C'est la même chose lorsque plusieurs URL sont indiquées sur la ligne de commande. Le quota n'est seulement vérifié qu'à la fin de chaque fichier téléchargé, donc il ne provoquera jamais le téléchargement partiel d'un fichier. Ainsi vous pouvez tranquillement taper wget -Q2m -i sites, le téléchargement s'arrêtera après que le fichier qui dépasse le quota a été complètement téléchargé.
Définir le quota à 0 ou à inf retire la limite du quota de téléchargement.
Cela dit, il a été rapporté que dans quelques situations, il n'est pas désirable de mettre en cache les noms d'hôtes, même pour la durée d'une application brève et rapide comme wget. Avec cette option, wget effectue une nouvelle recherche DNS (plus précisément, un nouvel appel à "gethostbyname" ou "getaddrinfo") à chaque nouvelle connexion. Veuillez prendre en compte que cette option n'affectera pas la mise en cache qui pourrait être effectuée par la bibliothèque de résolution ou par une couche de mise en cache externe, telle que NSCD.
Si vous ne comprenez pas exactement ce que fait cette option, vous n'en avez probablement pas besoin.
Par défaut, wget protège les caractères qui ne sont pas valables ou sûrs dans les noms de fichiers pour votre système d'exploitation, ainsi que pour les caractères de contrôle habituellement impossibles à afficher. Cette option est utile pour changer ce comportement par défaut, peut être parce que vous téléchargez dans une partition non native, ou parce que vous voulez désactiver la protection des caractères de contrôle, ou parce que vous voulez restreindre encore plus de caractères à ceux de la plage de valeurs ASCII.
Les modes sont un ensemble de valeurs textuelles séparées par des virgules. Les valeurs acceptées sont unix, windows, nocontrol, ascii, lowercase et uppercase. Les valeurs unix et windows sont mutuellement exclusives (l'une écrasera l'autre), de même pour lowercase et uppercase. Ces deux dernières sont des cas spéciaux, car elles ne changent pas l'ensemble des caractères qui devraient être protégés, mais plutôt forcent les chemins de fichier local à être converti soit en minuscules ou en capitales.
Lorsque "unix" est indiqué, wget protège le caractère / et les caractères de contrôle dans les plages de 0 à 31 et de 128 à 159. C'est le comportement par défaut pour les systèmes d'exploitation de type Unix.
Lorsque "windows" est indiqué, wget protège les caractères \, |, /, :, ?, ", *, <, >, et les caractères contrôle dans les plages de 0 à 31 et de 128 à 159. En plus de cela, wget en mode Windows utilise + au lieu de : pour séparer l'hôte et le port dans les noms de fichiers locaux, et utilise @ au lieu de ? pour séparer la partie requête du nom de fichier du reste. Par conséquent, une URL qui aurait été sauvegardée en www.xemacs.org:4300/search.pl?input=blabla en mode Unix pourrait l'être en www.xemacs.org+4300/search.pl@input=blabla en mode Windows. C'est le mode par défaut sur Windows.
Si vous indiquez nocontrol, alors la protection des caractères de contrôle est aussi désactivée. Cette option est utile lorsque vous téléchargez des URL avec des noms contenant des caractères UTF-8 sur un système qui peut sauvegarder et afficher les noms de fichiers en UTF-8 (certaines valeurs d'octets possibles utilisées dans les séquences d'octets UTF-8 tombent dans la plage de valeurs désignée par wget comme "contrôles").
Le mode ascii est utilisé pour spécifier que tous les octets dont la valeur est en dehors de la plage de caractères ASCII, (c'est-à-dire supérieure à 127) doivent être protégés. Cela est utile lors de la sauvegarde des noms de fichiers dont l'encodage ne correspond pas à celui utilisé en local.
Aucune de ces options ne devrait être normalement nécessaire. Par défaut, un wget prenant en charge IPv6 utilisera la famille d'adresses spécifiée par l'enregistrement DNS de l'hôte. Si le DNS répond avec à la fois des adresses IPv4 et IPv6, wget les essaiera dans l'ordre jusqu'à ce qu'il en trouve une pour se connecter. Consultez aussi l'option "--prefer-family" décrite ci-dessous.
Ces options peuvent être utilisées pour forcer délibérément l'usage des familles d'adresses IPv4 ou IPv6 sur les systèmes avec les deux familles, habituellement pour aider au débogage ou s'occuper d'une configuration réseau défaillante. Seulement l'une des options --inet6-only et --inet4-only peut être indiquée au même moment. Aucune option n'est disponible si wget a été compilé sans la prise en charge de IPv6.
Cela permet d'éviter les erreurs et les tentatives de connexion intempestives lors de l'accès à des hôtes dont l'adresse est à la fois IPv6 et IPv4 à partir de réseaux IPv4. Par exemple, www.kame.net se résout en 2001:200:0:8002:203:47ff:fea5:3085 et en 203.178.141.194. Lorsque la famille souhaitée est "IPv4", l'adresse IPv4 sera utilisée en premier ; lorsque la famille souhaitée est "IPv6", l'adresse IPv6 sera utilisée en premier ; si la valeur indiquée est "none", l'ordre des adresses renvoyé par DNS est utilisé sans changement.
Contrairement à -4 et -6, cette action n'empêche pas l'accès à une quelconque famille d'adresse, elle change juste l'ordre dans lequel on accède aux adresses. Remarquez aussi que le réordonnancement effectué par cette option est stable : il n'affecte pas l'ordre des adresses de la même famille. C'est-à-dire que l'ordre relatif de toutes les adresses IPv4 et de toutes les adresses IPv6 reste intact dans tous les cas.
Vous pouvez définir la commande par défaut pour use-askpass dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande.
Vous pouvez définir l'état par défaut de la prise en charge des IRI en utilisant la commande "iri" dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande.
wget utilise la fonction "nl_langinfo()" et donc la variable d'environnement "CHARSET" pour obtenir les paramètres régionaux. Si cela échoue, ASCII sera utilisé.
Vous pouvez définir l'encodage local par défaut en utilisant la commande "local_encoding" dans .wgetrc. Ce réglage peut être écrasé par la ligne de commande.
Pour HTTP, l'encodage distant peut être trouvé dans l'en tête HTTP "Content-Type" et dans les méta-étiquettes HTML "Content-Type http-equiv".
Vous pouvez définir l'encodage par défaut avec la commande "remoteencoding" dans .wgetrc. Ce réglage peut être écrasé en ligne de commande.
Prenons comme exemple le répertoire à l'adresse ftp://ftp.xemacs.org/pub/xemacs/. Si vous le récupérez avec -r, il sera sauvegardé localement sous ftp.xemacs.org/pub/xemacs/. Bien que l'option -nH peut supprimer la partie ftp.xemacs.org/, vous êtes encore coincé avec pub/xemacs. C'est là où --cut-dirs est vraiment pratique : il permet à wget de ne pas « voir » le nombre de composants de répertoire distant. Voici quelques exemples de la manière dont l'option --cut-dirs fonctionne.
Pas d'options -> ftp.xemacs.org/pub/xemacs/ -nH ->
pub/xemacs/ -nH --cut-dirs=1 -> xemacs/ -nH --cut-dirs=2 >
. --cut-dirs=1 -> ftp.xemacs.org/xemacs/ ...
Si vous voulez simplement vous débarrasser de la structure du répertoire, cette option est similaire à une combinaison de -nd et -P. Par contre, contrairement à -nd, --cut-dirs ne se perd pas avec des sous-répertoires (par exemple, avec -nH --cut-dirs=1, un sous-répertoire beta/ sera placé sur xemacs/beta, comme on pourrait l'espérer.
Notez que les noms de fichiers modifiés ainsi seront téléchargés à nouveau chaque fois que vous remettrez en miroir un site, car wget ne peut pas dire que le fichier local X.html correspond à l'URL X distante (étant donné qu'il ne sait pas encore que l'URL produit une sortie sous forme text/html ou application/xhtml+xml.
Avec la version 1.12 wget s'assure aussi que tous les fichiers téléchargés de forme text/css se terminent par le suffixe .css, et l'option a été renommée de --html-extension, pour mieux refléter son nouveau comportement. L'ancien nom de l'option est encore acceptable, mais devrait être considéré comme obsolète.
Depuis la version 1.19.2, wget s'assure aussi que tout fichier téléchargé avec un "Content-Encoding" de type br, compress, deflate ou gzip finisse avec le suffixe .br, .Z, .zlib et .gz respectivement.
À l'avenir, cette option devrait être assez étendue pour englober les suffixes d'autres types de contenus, incluant ceux qui ne sont pas analysés par wget.
Une autre manière d'indiquer le nom d'utilisateur et le mot de passe est de les spécifier dans l'URL. Les deux méthodes révèlent votre mot de passe à quiconque se donne la peine d'exécuter "ps"). Pour empêcher que les mots de passe ne soient vus, utilisez --use-askpass ou stockez les dans .wgetrc ou .netrc, et assurez vous de protéger ces fichiers des autres utilisateurs avec "chmod". Si les mots de passe sont très importants, ne les laissez pas traîner dans ces fichiers non plus (éditez les fichiers et effacez-les après que wget a commencé le téléchargement).
Cette option a son utilité quand, pour une raison quelconque, les connexions persistantes (keep-alive) ne fonctionnent pas pour vous, dû par exemple à un bogue du serveur ou en raison de l'incapacité des scripts côté serveur à gérer les connexions.
La mise en cache est autorisée par défaut.
Vous utiliserez généralement cette option pour la mise en place d'un miroir de sites qui exigent que vous soyez connecté pour accéder à tout ou partie de leur contenu. Le processus de connexion fonctionne généralement de la manière suivante : le serveur Web émet un cookie HTTP après avoir reçu et vérifié vos identifiants. Le cookie est alors renvoyé par le navigateur pour accéder à cette partie du site, et prouve ainsi de votre identité.
La mise en miroir d'un tel site nécessite que wget renvoie les même cookies que ceux envoyés par le navigateur lors de la communication avec le site. Cela est fait par --load-cookies ; il suffit d'indiquer à wget l'emplacement du fichier cookies.txt et il enverra les mêmes cookies que votre navigateur enverrait dans la même situation. Les différents navigateurs conservent les fichiers cookies textuels à des endroits différents :
Si vous ne pouvez pas utiliser --load-cookies, il devrait exister une alternative. Si votre navigateur prend en charge un "gestionnaire de cookie", vous pouvez l'utiliser pour visualiser les cookies utilisés pour accéder au site que vous mettez en miroir. Écrire le nom et la valeur du cookie, et donner des instructions manuellement à wget pour qu'il envoie ces cookies, en contournant le gestionnaire de cookie « officiel » :
wget --no-cookies --header "Cookie: <nom>=<valeur>"
Comme le format de fichier de cookie ne contient généralement pas les cookies de session, wget les marque avec un délai d'expiration de 0. --load-cookies de wget les reconnaît comme cookies de session, mais cela pourrait être confus pour d'autres navigateurs. Prenez en compte aussi que les cookies chargés ainsi seront traités comme d'autres cookies de session, donc si vous voulez que --save-cookies les conserve à nouveau, vous devez utiliser --keep-session-cookies à nouveau.
Avec cette option, wget ignorera l'en-tête "Content-Length", comme s'il n'avait jamais existé.
Vous pouvez définir plus d'un en-tête additionnel en indiquant --header plus d'une fois.
wget --header='Accept-Charset: iso-8859-2' \
--header='Accept-Language: hr' \ http://fly.srk.fer.hr/
L'indication d'une chaîne vide comme valeur d'en-tête effacera tous les en-têtes précédemment définis par l'utilisateur.
Avec wget 1.10, cette option peut être utilisée pour écraser les en-têtes qui autrement auraient été générés automatiquement. Cet exemple donne l'instruction à wget de se connecter à l'hôte local, mais en indiquant truc.machin dans l'en-tête "Host" :
wget --header="Host: truc.machin" http://localhost/
Dans les versions de wget antérieures à 1.10, une telle utilisation de --header provoquait l'envoi d'en-têtes en double.
Si auto ou gzip sont indiqués, wget demande au serveur de compresser le fichier en utilisant le format gzip de compression. Si le serveur compresse le fichier et répond avec le champ d'en-tête "Content-Encoding" configuré de manière adéquate, le fichier sera décompressé automatiquement.
Si none est indiqué, wget ne demandera pas au serveur de compresser le fichier et ne décompressera aucune réponse du serveur. C'est le comportement par défaut.
La prise en charge de la compression est actuellement expérimentale. Au cas où la compression est activée, merci de rapporter tout bogue à "bug-wget@gnu.org".
Des considérations de sécurité similaires à celles avec --http-password sont pertinentes ici aussi.
Le protocole HTTP autorise les clients à s'identifier eux-mêmes en utilisant un champ d'en-tête "User-Agent". Cela permet de différencier les logiciels WWW, généralement dans des buts de statistiques ou pour retracer les violations de protocole. Normalement, wget s'identifie comme Wget/version, où version est le numéro de la version actuelle de wget.
Cependant, certains sites sont connus pour imposer la politique d'adaptation de la sortie en fonction des informations fournies par le "User-Agent". Bien que ce ne soit pas une si mauvaise idée en théorie, il y a eu des abus par des serveurs refusant l'information à des clients autres que Netscape (historiquement), ou plus fréquemment, Microsoft Internet Explorer. Cette option vous permet de changer la ligne "User-Agent" fournie par wget. Utiliser cette option est déconseillé, à moins de savoir réellement ce que vous faites.
Indiquer un user agent vide avec --user-agent="" demandera à wget de ne pas envoyer d'en-tête "User-Agent" dans les requêtes HTTP.
Veuillez noter que wget n'exige pas que le contenu soit de la forme "clé1=valeur1&clé2=valeur2", et ne le teste pas non plus. wget transmettra simplement toutes les données qui lui sont fournies. La plupart des serveurs s'attendent toutefois à ce que les données POST soient dans le format ci-dessus lors du traitement des formulaires HTML.
Lors de l'envoi d'une requête POST à l'aide de l'option --post-file, wget traite le fichier comme un fichier binaire et envoie chaque caractère de la requête POST sans supprimer les caractères de fin de ligne ou de saut de page. Tout autre caractère de contrôle dans le texte sera aussi envoyé tel quel dans la requête POST.
Merci de prendre en compte que wget doit connaître la taille des données POST à l'avance. C'est pourquoi l'argument à "--post-file" doit être un fichier normal ; spécifier une FIFO ou quelque chose comme /dev/stdin ne fonctionnera pas. La façon de contourner cette limite inhérente à HTTP/1.0. n'est pas très claire. Bien que HTTP/1.0. introduise le transfert morcelé qui ne nécessite pas de connaître la longueur à l'avance, un client ne peut pas utiliser le tronçonnage avant de savoir qu'il parle à un serveur HTTP/1.1. Et il ne peut pas le savoir avant d'avoir reçu une réponse, qui a son tour nécessite qu'une requête ait abouti - le problème de l'œuf et de la poule).
Note : Depuis la version 1.15 si wget est redirigé après que la requête POST a terminé, son comportement dépendra du code de la réponse renvoyé par le serveur. Dans le cas d'un 301 Moved Permanently, 302 Moved Temporarily ou 307 Temporary Redirect, wget en accord avec la RFC2616, continuera à envoyer une requête POST. Dans le cas où un serveur veut que le client change la méthode de requête lors de la redirection, il devrait envoyer un code de réponse 303 See Other .
Cet exemple montre comment se connecter à un serveur en utilisant POST et ensuite procéder au téléchargement des pages souhaitées, vraisemblablement accessibles uniquement aux utilisateurs autorisés :
# Se connecter au serveur. Cela ne peut être fait qu'une fois. wget
--save-cookies cookies.txt \ --post-data
'user=truc&password=machin' \ http://example.com/auth.php
# Maintenant prendre la ou les pages qui nous intéressent . wget
--load-cookies cookies.txt \ -p
http://example.com/interesting/article.php
Si le serveur utilise des cookies de session pour tracer l'authentification de l'utilisateur, l'exemple ci-dessus ne fonctionnera pas car --save-cookies ne les sauvegardera pas (comme aucun navigateur) et le fichier cookies.txt sera vide. Dans ce cas, utiliser --keep-session-cookies avec --save-cookies pour forcer la sauvegarde des cookies de session.
Actuellement, --body-file ne transmet pas les fichiers comme un tout. wget ne prend actuellement pas en charge "multipart/form-data" pour la transmission de données, mais seulement "application/x-www-form-urlencoded". Dans le futur, cela devrait changer pour que wget puisse envoyer le fichier --body-file comme un fichier complet, au lieu d'envoyer son contenu au serveur. Veuillez prendre en compte que wget nécessite de connaître le contenu des données BODY à l'avance et donc l'argument de --body-file devrait être un fichier ordinaire. Voir --post-file pour des explications plus détaillées. Une seule des options --body-data et --body-file devrait être spécifiée.
Si wget est redirigé après la fin de la requête, wget suspend la méthode en cours et envoie une requête GET jusqu'à ce que la redirection soit terminée. Cela est vrai pour tous les codes de redirection de réponse à l’exception de 307 Temporary Redirect qui est utilisé pour indiquer explicitement que la méthode de requête ne devrait pas changer. Une autre exception est quand la méthode est positionnée à "POST", auquel cas les règles de redirection indiquées avec --post-data sont suivies.
Cette option est utile pour quelques programmes de téléchargement CGI qui utilisent des en-têtes "Content-Disposition" pour décrire à quoi devrait ressembler le nom d'un fichier téléchargé.
Quand il est combiné avec --metalink-over-http et --trust-server-names, un fichier Content-Type: application/metalink4+xml est nommé en utilisant le champ de nom de fichier de "Content-Disposition", s'il est disponible.
L'utilisation de cette option est déconseillée, et est destinée uniquement à la prise en charge de quelques serveurs obscurs qui n'envoient jamais d'authentification par question-réponse HTTP, mais acceptent les informations d'authentification non sollicitées, disons, en plus de l'authentification par formulaire.
L'utilisation de cette option n'est prévue que pour des cas d'utilisation particuliers et n'est généralement pas recommandée, car elle peut forcer des tentatives même dans les cas où le serveur essaie réellement de réduire sa charge. Veuillez l'utiliser à bon escient et seulement si vous savez ce que vous faites.
Pour la prise en charge des téléchargements HTTP (HTTPS) chiffrés, wget doit être compilé avec une bibliothèque SSL externe. Habituellement par défaut c'est GnuTLS. En plus, wget prend aussi en charge HSTS (HTTP Strict Transport Security). Si wget est compilé sans la prise en charge de SSL, aucune de ces options n'est disponible.
Indiquer SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2 ou TLSv1_3 force l'utilisation du protocole correspondant. Cette fonction est utile lorsque l'on s'adresse à des implémentations de serveur SSL anciennes et boguées qui rendent le choix de la version correcte du protocole difficile pour la bibliothèque SSL sous-jacente. Heureusement, de tels serveurs sont assez rares.
La spécification de PFS impose l'utilisation des suites de chiffrement dites « Perfect Forward Security ». Pour faire court, PFS ajoute une sécurité en créant une clé à usage unique pour chaque connexion SSL. Cela a un impact un peu plus important sur le CPU du client et du serveur. Nous utilisons des chiffrements connus pour être sûrs (par exemple, pas de MD4) et le protocole TLS. Ce mode exclut également de manière explicite les méthodes d'échange de clés non PFS, telles que RSA.
Depuis wget 1.10, le comportement par défaut est de vérifier le certificat du serveur auprès des autorités de certification reconnues, cassant l'établissement de la liaison SSL et stoppant le téléchargement si la vérification échoue. Aussi, même si cela procure des téléchargements plus sûrs, cela casse l'interopérabilité avec certains sites qui fonctionnent avec des versions précédentes de wget, en particulier ceux qui utilisent des certificats auto-signés, expirés ou non valables. Cette option force le mode "insecure" qui transforme les erreurs de vérification de certificats en avertissements, permettant ainsi de poursuivre.
Si vous rencontrez des erreurs "certificate verification" ou qui indiquent "le nom courant ne correspond pas au nom d'hôte demandé", vous pouvez utiliser cette option pour outrepasser la vérification. N'utilisez cette option que si vous êtes convaincu par un autre moyen de l'authenticité du site, ou si vraiment peu vous importe la validité de son certificat. C'est presque toujours une mauvaise idée de ne pas vérifier les certificats lors de la transmission de données confidentielles ou importantes. Pour les certificats auto-signés, vous devriez télécharger le certificat pour le vérifier au lieu de forcer en mode non sécurisé. Si vous êtes vraiment sûr de ne vouloir aucune vérification de certificat, vous pouvez indiquer --check-certificate=quiet pour dire à wget de ne pas afficher d'avertissements au sujet des certificats non valables, bien que dans la plupart des cas ce soit la mauvaise chose à faire.
Sans cette option wget cherche les certificats CA aux endroits spécifiés par le système, choisis par OpenSSL lors de son installation.
Sans cette option wget cherche les certificats CA aux endroits spécifiés par le système, choisis par OpenSSL lors de son installation.
Lors de la négociation d'une connexion TLS ou SSL, le serveur envoie un certificat prouvant son identité. Une clé publique est extraite de ce certificat et si cela ne correspond pas exactement à une des clés publique fournies à cette option, wget annulera la connexion avant l'envoi ou la réception de données.
Sur de tels systèmes, la bibliothèque -SSL a besoin d'une source extérieure de données aléatoires pour s'initialiser. Les données aléatoires peuvent être fournies par EGD (voir --egd-file ci dessous) ou lues sur une source extérieure spécifiée par l'utilisateur. Si cette option n'est pas indiquée, wget cherchera les données aléatoires dans $RANDFILE ou, s'il n'est pas défini, dans HOME/.rnd.
Si vous obtenez l'erreur "Could not seed OpenSSL PRNG; disabling SSL.", vous devriez fournir des données aléatoires en utilisant l'une des méthodes décrites ci-dessus.
OpenSSL autorise l'utilisateur à indiquer sa propre source d'entropie en utilisant la variable d'environnement "RAND_FILE". Si cette variable n'est pas définie, ou si le fichier indiqué ne produit pas assez de caractères aléatoires, OpenSSL lira les données aléatoires du socket EGD indiqué en utilisant cette option.
Si cette option n'est pas indiquée (et que la commande équivalente de démarrage n'est pas utilisée), EGD n'est jamais contacté. EGD n'est pas nécessaire sur les systèmes Unix modernes qui prennent en charge /dev/urandom.
La base de données HSTS de wget est un fichier en texte brut. Chaque ligne contient une entrée HSTS (c'est-à-dire, un site qui a fourni un en-tête "Strict-Transport-Security" et a néanmoins indiqué une politique concrète HSTS à appliquer). Les lignes commençant par un croisillon ("#") sont ignorées par wget. Veuillez noter qu'en dépit de cette facilité de lecture, la création manuelle de la base de données HSTS n'est généralement pas une bonne idée.
Une entrée de ligneHSTS consiste en plusieurs champs séparés par un ou plusieurs espaces blancs :
"<hostname> SP [<port>] SP <include subdomains> SP <created> SP <max-age>"
Les champs hostname et port indiquent le nom de l'hôte et le port sur lequel est appliquée la politique HSTS indiquée. Le champ port peut être zero, et le sera, dans la majorité des cas. Cela signifie que le numéro de port ne sera pas pris en compte lors de la décision d'appliquer telle ou telle politique HSTS pour une requête donnée (seul le nom d'hôte sera évalué). Lorsque port est différent de zéro, à la fois le nom d'hôte et le port seront évalués et la politique HSTS sera appliquée si les deux correspondent. Cette option a été incluse à des fins de test et de développement surtout. La suite de tests de wget (dans testenv/) crée des bases de données HSTS avec des ports explicites dans le but d'assurer un comportement correct à wget. L'utilisation de politiques HSTS sur des ports autres que ceux par défaut est déconseillée par la RFC 6797 (voir l'appendice B "Differences between HSTS Policy and Same-Origin Policy"). Ainsi, cette option ne devrait pas être utilisée dans des environnements en production et le port sera typiquement zéro. Les trois derniers champs font ce qu'on attend d'eux. Le champ include_subdomains peut être 1 ou 0 et indique si les sous-domaines du domaine cible devraient aussi faire partie de la politique HSTS donnée. Les champs create et max-age portent l'horodatage de la création de l'entrée (comme vu la première fois par wget) et la valeur définie par HSTS "max-age", qui définit combien de temps la politique HSTS devrait rester activée, mesuré en secondes écoulées depuis le délai stocké dans created. Une fois ce temps écoulé, la politique HSTS ne sera plus valable et sera finalement enlevée de la base de données.
Si vous fournissez votre propre base de données HSTS à l'aide de --hsts-file, sachez que wget peut modifier le fichier fourni si un changement se produit entre les politiques HSTS demandées par les serveurs distants et celles du fichier. Quand wget se termine, il met effectivement à jour la base de données HSTS en réécrivant le fichier de base de données avec les nouvelles entrées.
Si le fichier fourni n'existe pas, wget en créera un. Ce fichier contiendra les nouvelles entrées HSTS. Si aucune entrée HSTS n'a été crée (aucun en-tête "Strict-Transport-Security" n'a été envoyé par aucun des serveurs) alors aucun fichier n'est créé, même pas un vide. Ce comportement s'applique aussi au fichier de base de données par défaut (~/.wget-hsts) : il ne sera pas créé, sauf par un serveur qui force la politique HSTS.
L'attention est mise sur le fait de ne pas écraser de possibles changements faits par d'autres wget au même moment sur la base de données HSTS. Avant de déposer les entrées HSTS mises à jour dans le fichier, wget le relit et fusionne les modifications.
Il est déconseillé d'utiliser une base de données HSTS personnalisée ou de modifier une base existante. Pour plus d'informations sur les menaces de sécurité potentielles découlant d'une telle pratique, consultez la section 14 "Considérations de sécurité" de la RFC 6797, en particulier la section 14.9 "Manipulation créative du stockage de politiques HSTS".
Le nom d'utilisateur et le mot de passe peuvent être indiqués dans l'URL. Les deux méthodes révèlent votre mot de passe à quiconque se donne la peine d'exécuter "ps". Pour empêcher que vos mots de passe soient vus, stockez les dans .wgetrc ou .netrc, et assurez-vous de protéger ces fichiers des autres utilisateurs avec "chmod". Si les mots de passe sont très importants, vous ne devriez pas les laisser traîner dans ces fichiers non plus (éditez les fichiers et effacez-les après que wget a commencé le téléchargement).
Remarquez que même si wget écrit dans un nom de fichier connu pour ce fichier, ce n'est pas une faille de sécurité dans le scénario d'un utilisateur faisant de .listing un lien symbolique vers /etc/passwd ou autre et demandant à "root" d'exécuter wget dans son répertoire. Selon les options utilisées, soit wget refusera d'écrire dans .listing, faisant échouer l'opération de globbing/récursion/horodatage, soit le lien symbolique sera supprimé et remplacé par le fichier .listing réel, soit le listing sera écrit dans un fichier .listing.numéro.
Même dans cette situation, cela n'est pas un problème, bien que, "root" ne devrait jamais lancer wget dans un répertoire utilisateur non sécurisé. Un utilisateur pourrait faire quelque chose d'aussi simple qu'un lien de index.html à /etc/passwd et demander à "root" de lancer wget avec -N ou -r et ainsi écraser le fichier.
wget ftp://gnjilux.srk.fer.hr/*.msg
Par défaut, la fonction de globbing est activée si l'URL contient un caractère de globbing. Cette option peut être utilisée pour activer ou désactiver le globbing de manière permanente.
Vous devrez peut-être mettre entre guillemets l'URL pour le protéger de l'expansion par votre interpréteur de commandes. Le globbing fait que wget cherche une liste de répertoires, ce qui est spécifique au système. C'est pourquoi cela ne fonctionne actuellement qu'avec les serveurs FTP Unix (et ceux qui émulent la sortie "ls" d'Unix).
Si la machine est connectée directement à Internet, FTP actif et passif devraient fonctionner aussi bien l'un que l'autre. Derrière la plupart des configurations de pare-feu et de NAT, le FTP passif a plus de chance de fonctionner. Cependant, dans certaines configurations rares de pare-feu, le FTP actif fonctionne alors que le FTP passif ne fonctionne pas. Si vous pensez que c'est le cas, utilisez cette option, ou définissez "passive_ftp=off" dans votre fichier init.
Lorsque --retr-symlinks=no est indiqué, le fichier pointé n'est pas téléchargé. À la place, un lien symbolique correspondant est créé sur le système de fichiers local. Le fichier pointé ne sera pas récupéré sauf si la récupération récursive le rencontre autrement et le télécharge de toutes façons. Cette option pose un risque de sécurité où un serveur FTP malveillant pourrait amener wget à écrire dans des fichiers situés en dehors des répertoires prévus par le biais d'un fichier .LISTING spécialement contrefait.
Notez que cette option n'a aucun effet lors de la récupération d'un fichier (pas d'un répertoire) parce qu'il a été indiqué dans la ligne de commandes plutôt que trouvé par récursion. Les liens symboliques sont toujours suivis dans ce cas.
wget -r -l 0 http://<site>/1.html
Idéalement, on pourrait s'attendre à ce que cela ne télécharge que 1.html, mais malheureusement ce n'est pas le cas, car -l 0 est équivalent à -l inf (ce qui est la récursion infinie). Pour télécharger une seule page HTML (ou quelques pages), indiquez les sur la ligne de commande et délaissez -r et -l. Pour télécharger les éléments essentiels à l'affichage d'une seule page HTML, voir page requisites.
wget -r -nd --delete-after http://toto.com/~page/populaire/
L'option -r est pour récupérer récursivement et -nd pour ne pas créer de répertoires.
Remarquez que --delete-after efface les fichiers sur la machine locale. Cela n'émet pas la commande DELE pour les sites FTP distants, par exemple. Notez aussi que lorsque --delete-after est indiqué, --convert-links est ignoré, ainsi les fichiers .orig ne sont tout simplement pas créés en premier lieu.
Chaque lien sera changé d'une manière ou d'une autre :
Exemple : si le fichier téléchargé /toto/doc.html pointe vers /machin/img.gif aussi téléchargé, alors le lien dans doc.html sera modifié pour pointer vers ../machin/img.gif. Ce genre de transformation fonctionne pour relier des combinaisons arbitraires de répertoires.
Exemple : si le fichier téléchargé /toto/doc.html pointe vers /machin/img.gif (ou vers ../machin/img.gif), alors le lien dans doc.html sera modifié pour pointer vers http://nomdhôte/machin/img.gif.
De ce fait, la navigation locale fonctionne de manière fiable : si un fichier lié a été téléchargé, le lien renverra à son nom local ; s'il n'a pas été téléchargé, le lien renverra à son adresse Internet complète plutôt que de présenter un lien brisé. Le fait que les anciens liens soient convertis en liens relatifs garantit que vous pouvez déplacer la hiérarchie téléchargée vers un autre répertoire.
Notez que ce n'est qu'à la fin du téléchargement que wget peut savoir quels liens ont été téléchargés. De ce fait, le travail effectué par -k sera réalisé à la fin de tous les téléchargements.
Cela fonctionne particulièrement bien en conjonction avec --adjust-extension, même si ce couplage n'est pas appliqué. Cela est utile pour alimenter les caches Internet avec des fichiers téléchargés à partir de différents hôtes.
Exemple : si un lien pointe vers //toto.com/machin.cgi?xyz avec --adjust-extension activé et sa destination locale étant prévue d'être ./toto.com/machin.cgi?xyz.css, alors le lien devrait être converti en //toto.com/machin.cgi?xyz.css. Remarquez que seule la partie nom de fichier a été modifiée. Le reste de l'URL n'a pas été touché, y compris le chemin de réseau ("//") qui aurait dû autrement être traité par wget et converti en schéma effectif (c'est à dire "http://").
Normalement, lors du téléchargement d'une seule page HTML, les documents nécessaires à son affichage ne sont pas téléchargés. Utiliser -r associé à -l peut aider, comme wget ne distingue pas d'ordinaire les documents externes de ceux internes, on se retrouve généralement avec des « documents feuilles » à qui manquent les éléments requis.
Par exemple, le document 1.html contient une étiquette "<IMG>" référençant 1.gif et une étiquette "<A>" pointant vers le document externe 2.html. Disons que 2.html est similaire mais que son image est 2.gif et qu'elle pointe vers 3.html. Disons que cela continue jusqu'à un nombre arbitrairement élevé.
Si on exécute la commande :
wget -r -l 2 http://<site>/1.html
alors 1.html, 1.gif, 2.html, 2.gif, et 3.html seront téléchargés. Comme vous pouvez voir, 3.html est sans son requis 3.gif parce que wget compte juste le nombre de bonds (jusqu'à deux) en dehors de 1.html pour déterminer où arrêter la récursion. De toute façon, avec cette commande :
wget -r -l 2 -p http://<site>/1.html
tous les fichiers au-dessus et le fichier 3.gif nécessaire à 3.html seront téléchargés. De même,
wget -r -l 1 -p http://<site>/1.html
entraînera le téléchargement de 1.html, 1.gif, 2.html et 2.gif. On pourrait penser que :
wget -r -l 0 -p http://<site>/1.html
ne téléchargera que 1.html et 1.gif, mais malheureusement ce n'est pas le cas, car -l 0 est équivalent à -l inf (qui est la récursion infinie). Pour télécharger une seule page HTML (ou une poignée d'entre elles, toutes indiquées sur la ligne de commande ou dans un fichier d'entrée -i URL ) et son (ou ses) éléments requis, enlevez simplement -r et -l :
wget -p http://<site>/1.html
Notez que wget se comportera comme si -r avait été spécifié, mais seule cette page unique et ses éléments requis seront téléchargés. Les liens de cette page vers des documents externes ne seront pas suivis. Actuellement, pour télécharger une seule page et ses éléments requis (même s'ils existent sur d'autres sites web), et s'assurer que le lot s'affiche correctement localement, cet auteur aime utiliser quelques options en plus de -p :
wget -E -H -k -K -p http://<site>/<document>
Pour terminer ce sujet, il est utile de savoir que l'idée que wget se fait d'un lien vers un document externe est toute URL spécifiée dans une étiquette "<A>", une étiquette "<AREA>" ou une étiquette "<LINK>" autre que "<LINK REL="stylesheet">".
Selon les spécifications, les commentaires sont exprimés en tant que declarations SGML. La déclaration est un marqueur spécial commençant par <! et finissant par >, comme <!DOCTYPE...>, qui peut contenir des commentaires entre une paire de délimiteurs --. Les commentaires HTML sont des « déclarations vides », des déclarations SGML sans aucun texte qui n'est pas un commentaire. Par conséquent, <!--toto--> est un commentaire valable, et aussi <!--un-- --deux-->, mais <!--1--2--> n'en est pas un.
D'autre part, la plupart des rédacteurs de HTML ne perçoivent pas les commentaires comme autre chose que du texte délimité par <!-- et -->, ce qui n'est pas tout à fait la même chose. Par exemple, quelque chose comme <!------------> fonctionne comme un commentaire valable tant que le nombre de tirets est un multiple de quatre (!). Sinon, le commentaire dure techniquement jusqu'au prochain --, qui peut se trouver à l'autre bout du document. À cause de cela, beaucoup de navigateurs populaires ignorent totalement la spécification et mettent en œuvre ce que l'utilisateur attend : des commentaires délimités par <!-- et -->.
Jusqu'à la version 1.9, wget interprétait les commentaires de façon stricte, ce qui aboutissait en des liens manquants dans plusieurs pages web qui s'affichaient bien dans les navigateurs, mais avaient la malchance de contenir des commentaires non conformes. À partir de la version 1.9, wget a rejoint les rangs des clients qui implémentent des commentaires « naïfs », terminant chaque commentaire à la première occurrence de -->.
Si, pour une raison quelconque, vous voulez une analyse stricte des commentaires, utilisez cette option pour l'activer.
Dans le passé, cette option était la meilleure solution pour télécharger une seule page et ses éléments requis, en utilisant une ligne de commande comme :
wget --ignore-tags=a,area -H -k -K -r
http://<site>/<document>
Cependant, l'auteur de cette option a trouvé une page avec des étiquettes comme "<LINK REL="home" HREF="/">" et a réalisé que spécifier les étiquettes à ignorer n'était pas suffisant. On ne peut pas simplement dire à wget d'ignorer "<LINK>", car les feuilles de style ne seront pas téléchargées. Maintenant la meilleure solution pour télécharger une seule page et son nécessaire reste l'option --page-requisites.
wget prend en charge les mandataires à la fois pour les récupérations HTTP et FTP. La façon normale d'indiquer l'emplacement des mandataires, reconnus par wget, est d'utiliser les variables d'environnement suivantes :
wget peut renvoyer l'un des différents codes d'erreur s'il rencontre des problèmes.
À l'exception de 0 et 1, les codes de retour les moins élevés sont prioritaires par rapport aux plus élevés lorsque plusieurs types d'erreurs sont rencontrés.
Dans les versions de wget antérieures à la 1.12, les codes de retour de wget tendaient à n'être d'aucune utilité et incohérents. Les téléchargements récursifs auraient toujours renvoyé 0 (succès), sans tenir compte des problèmes rencontrés, et les recherches non récursives ne renvoyaient que l'état correspondant à la dernière tentative de téléchargement.
Vous êtes les bienvenus pour soumettre des rapports de bogue à l'aide du système de suivi de bogue de GNU wget (voir <https://savannah.gnu.org/bugs/?func=additem&group=wget>) ou de la liste de diffusion <bug-wget@gnu.org>.
Visitez <https://lists.gnu.org/mailman/listinfo/bug-wget> pour obtenir plus d'informations (comment souscrire, les archives de la liste, ...).
Avant de soumettre un rapport de bogue, veuillez essayer de suivre quelques principes simples.
De plus, bien que je serais intéressé par le contenu de votre fichier .wgetrc, l'intégrer simplement dans le message de débogage est probablement une mauvaise idée. À la place, vous devriez d'abord essayer de voir si le bogue se répète avec un .wgetrc retiré de son emplacement. C'est seulement s'il s'avère que les paramètres de .wgetrc affectent le bogue, que vous devriez m'envoyer les parties pertinentes du fichier.
Note : merci de veiller à supprimer toute information potentiellement sensible du journal de débogage avant de l'envoyer à l'adresse pour les bogues. Le "-d" ne se démènera pas pour collecter des informations sensibles, mais le journal contiendra une transcription assez complète de la communication de wget avec le serveur, qui peut inclure des mots de passe et des éléments de données téléchargés. Comme l'adresse pour les bogues est publiquement archivée, vous devez comprendre que tous les rapports de bogue sont visibles du public.
Cela n'est pas le manuel complet de GNU wget. Pour des informations plus complètes, comprenant plus d'explications détaillées de certaines des options, et un nombre de commandes à utiliser avec les fichiers .wgetrc et l'option -e, consulter l'entrée de GNU Info pour wget.
Voir aussi wget2(1), la version mise à jour de GNU wget avec une prise en charge encore meilleure du téléchargement récursif et des protocoles modernes tels que HTTP/2.
Écrit à l'origine par Hrvoje Niki <hniksic@xemacs.org>. Actuellement maintenu par Darshit Shah <darnir@gnu.org> et Tim Rühsen <tim.ruehsen@gmx.de>.
Copyright (c) 1996--2011, 2015, 2018--2023 Free Software Foundation, Inc.
L'autorisation est accordée de copier, distribuer et/ou modifier ce document selon les termes de la GNU Free Documentation License, Version 1.3 ou toute version ultérieure publiée par la Free Software Foundation ; sans sections invariantes, sans texte de première de couverture et sans texte de couverture du verso. Une copie de la licence est incluse dans la section intitulée "GNU Free Documentation license".
La traduction française de cette page de manuel a été créée par Sébastien Blanchet, Éric Piel <eric.piel@tremplin-utc.net> et bubu <bubub@no-log.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à debian-l10n-french@lists.debian.org.
| 10 septembre 2023 | GNU Wget 1.21.4 |