En utilisant wget, quelle est la bonne commande pour obtenir la version gzippée au lieu du HTML réel

Je suis tombé sur ce site qui en parle.

Donc, lorsque vous téléchargez un site Web entier en obtenant la version gzippée, quelle est la bonne commande?

J'ai testé cette commande, mais je ne sais pas si wget obtient vraiment la version gzippée:

wget --header="accept-encoding: gzip" -m -Dlinux.about.com -r -q -R gif,png,jpg,jpeg,GIF,PNG,JPG,JPEG,js,rss,xml,feed,.tar.gz,.zip,rar,.rar,.php,.txt -t 1 http://linux.about.com/

wget jomnana
la source

Vous dites que vous avez testé cette commande, mais la réponse de @ EightBitTony ci-dessous semble dire que ce que vous en sortiriez serait un fichier gzip du premier hit sans aucune récursivité sur le site pour plus de fichiers. Est-ce le résultat que vous avez obtenu?

Caleb

linux.about.com est compressé avec gzip, et cette commande recursive l'ensemble du site. J'ai testé cette commande sur un autre site Web et elle récapitule également l'ensemble du site. C'est pourquoi je suis un peu confus s'il télécharge vraiment la version gzippée ou non

jomnana

Si vous demandez du contenu gzip (en utilisant l'en-tête accept-encoding: gzip, ce qui est correct), alors je comprends que wget ne peut pas lire le contenu. Vous vous retrouverez donc avec un seul fichier compressé sur le disque, pour la première page que vous atteignez, mais pas d'autre contenu.

c'est-à-dire que vous ne pouvez pas utiliser wget pour demander du contenu gzippé et récurrer tout le site en même temps.

Je pense qu'il y a un patch qui permet à wget de supporter cette fonction mais ce n'est pas dans la version de distribution par défaut.

Si vous incluez l'indicateur -S, vous pouvez savoir si le serveur Web répond avec le type de contenu correct. Par exemple,

wget -S --header="accept-encoding: gzip" wordpress.com
--2011-06-17 16:06:46--  http://wordpress.com/
Resolving wordpress.com (wordpress.com)... 72.233.104.124, 74.200.247.60, 76.74.254.126
Connecting to wordpress.com (wordpress.com)|72.233.104.124|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Server: nginx
  Date: Fri, 17 Jun 2011 15:06:47 GMT
  Content-Type: text/html; charset=UTF-8
  Connection: close
  Vary: Accept-Encoding
  Last-Modified: Fri, 17 Jun 2011 15:04:57 +0000
  Cache-Control: max-age=190, must-revalidate
  Vary: Cookie
  X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
  X-Pingback: http://wordpress.com/xmlrpc.php
  Link: <http://wp.me/1>; rel=shortlink
  X-nananana: Batcache
  Content-Encoding: gzip
Length: unspecified [text/html]

Le codage du contenu indique clairement gzip, cependant pour linux.about.com (actuellement),

wget -S --header="accept-encoding: gzip" linux.about.com
--2011-06-17 16:12:55--  http://linux.about.com/
Resolving linux.about.com (linux.about.com)... 207.241.148.80
Connecting to linux.about.com (linux.about.com)|207.241.148.80|:80... connected.
HTTP request sent, awaiting response...
  HTTP/1.1 200 OK
  Date: Fri, 17 Jun 2011 15:12:56 GMT
  Server: Apache
  Set-Cookie: TMog=B6HFCs2H20kA1I4N; domain=.about.com; path=/; expires=Sat, 22-Sep-12 14:19:35 GMT
  Set-Cookie: Mint=B6HFCs2H20kA1I4N; domain=.about.com; path=/
  Set-Cookie: zBT=1; domain=.about.com; path=/
  Vary: *
  PRAGMA: no-cache
  P3P: CP="IDC DSP COR DEVa TAIa OUR BUS UNI"
  Cache-Control: max-age=-3600
  Expires: Fri, 17 Jun 2011 14:12:56 GMT
  Connection: close
  Content-Type: text/html
Length: unspecified [text/html]

Il renvoie du texte / html.

Étant donné que certains navigateurs plus anciens ont toujours des problèmes avec le contenu encodé gzip, de nombreux sites ne l'activent que sur la base de l'identification du navigateur. Ils le désactivent souvent par défaut et ne le désactivent que lorsqu'ils savent que le navigateur peut le prendre en charge - et ils n'incluent généralement pas wget dans cette liste. Cela signifie que vous pouvez trouver que wget ne retourne jamais de contenu gzip même si le site semble le faire pour votre navigateur.

EightBitTony
la source

Mais j'ai eu un tas de fichiers, et pas un seul fichier compressé ... ou ma version wget est-elle différente? (en utilisant Ubuntu 11.04)

jomnana

Si vous utilisez -S, vous pouvez voir les en-têtes renvoyés par le serveur, et lorsque vous faites cela contre linux.about.com, vous pouvez clairement voir qu'il renvoie du contenu HTML, pas du contenu gzip. wget -S --header = "accept-encoding: gzip" linux.about.com Type de contenu: text / html

EightBitTony

Parce que tous les navigateurs ne prennent pas en charge l'encodage gzip (IE a des problèmes majeurs), de nombreux sites Web n'activent l'encodage gzip que par navigateur et ne prennent pas la peine de le faire pour wget. Cela explique probablement pourquoi linux.about.com ne gzip pas lorsque wget le demande. Mais cela ne résout pas le problème principal selon lequel (AFAIK) wget ne peut pas récupérer le contenu compressé.

EightBitTony

Je viens d'essayer ceci: la sortie wget est toujours là Content-Type: text/html; charset=UTF-8, mais il y en a aussi Content-Encoding: gzip. Ce ne serait pas une compression transparente si son utilisation obligeait le type MIME de tout à gzip ... J'ai couru strace -s 128 wget ...pour voir certains des octets lus depuis le socket / écrits sur le disque. Ils ne sont pas ASCII. Donc, même si je pense qu'en 2011, votre commande n'a pas reçu de version compressée, en 2015, la même commande en a reçu. (wget 1.15).

Peter Cordes

J'aime faire "-O -" pour que la page passe à stdout, puis la diriger vers gunzip pour s'assurer qu'elle est tronquée et petite lorsqu'elle n'est pas redirigée via gzip et grande et html lorsqu'elle est redirigée via gzip ...

nroose

En utilisant wget, quelle est la bonne commande pour obtenir la version gzippée au lieu du HTML réel

Réponses: