Usando wget, ¿Cuál es el comando correcto para obtener la versión comprimida en lugar del HTML real?

Me topé con este sitio web que habla sobre esto.

Entonces, al descargar todo el sitio web obteniendo la versión comprimida, ¿cuál es el comando correcto?

He probado este comando, pero no sé si wget realmente obtendrá la versión comprimida:

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
fuente

Dices que has probado ese comando, pero la respuesta de @ EightBitTony a continuación parece decir que lo que obtendrías sería un archivo gzip del primer hit sin ninguna recurrencia a través del sitio para obtener más archivos. ¿Fue ese el resultado que obtuviste?

Caleb

linux.about.com está comprimido con gzip, y este comando se repite en todo el sitio. He probado este comando en otro sitio web y también se repite en todo el sitio. Es por eso que un poco confundido si realmente descargar la versión gzip o no

jomnana

Si solicita contenido gzip'ed (usando la codificación accept: encabezado gzip, que es correcto), entiendo que wget no puede leer el contenido. Por lo tanto, terminará con un solo archivo comprimido en el disco, para la primera página que golpee, pero ningún otro contenido.

es decir, no puede usar wget para solicitar contenido comprimido y recurrir todo el sitio al mismo tiempo.

Creo que hay un parche que permite que wget admita esta función, pero no está en la versión de distribución predeterminada.

Si incluye el indicador -S, puede saber si el servidor web responde con el tipo de contenido correcto. Por ejemplo,

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]

La codificación de contenido indica claramente gzip, sin embargo para linux.about.com (actualmente),

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]

Está devolviendo texto / html.

Debido a que algunos navegadores antiguos aún tienen problemas con el contenido codificado con gzip, muchos sitios solo lo habilitan en función de la identificación del navegador. A menudo lo desactivan de manera predeterminada y solo lo activan cuando saben que el navegador puede admitirlo, y generalmente no incluyen wget en esa lista. Esto significa que es posible que wget nunca devuelva contenido de gzip, incluso si el sitio parece hacerlo para su navegador.

OchoBitTony
fuente

Pero obtuve un montón de archivos, y ni un solo archivo comprimido ... ¿o mi versión de wget es diferente? (usando Ubuntu 11.04)

jomnana

Si usa -S, puede ver los encabezados devueltos por el servidor, y cuando lo hace contra linux.about.com, puede ver claramente que está devolviendo contenido html, no gzip. wget -S --header = "accept-encoding: gzip" linux.about.com Tipo de contenido: texto / html

EightBitTony

Debido a que no todos los navegadores admiten la codificación gzip (IE tiene problemas importantes), muchos sitios web solo permiten la codificación gzip por navegador y no se molestan en hacerlo por wget. Eso probablemente explica por qué linux.about.com no hace gzip cuando wget se lo solicita. Pero no soluciona el problema principal que wget (AFAIK) no puede repetir contenido comprimido.

EightBitTony

Acabo de intentar esto: la salida de wget todavía está Content-Type: text/html; charset=UTF-8, pero también la hay Content-Encoding: gzip. No sería una compresión transparente si usarlo forzara el tipo MIME de todo a gzip ... Corrí strace -s 128 wget ...para ver realmente algunos de los bytes leídos del socket / escritos en el disco. No son ASCII. Entonces, aunque creo que en 2011 su comando no recibió una versión comprimida, en 2015 sí lo hizo. (wget 1.15).

Peter Cordes

Me gusta hacer "-O -" para que la página vaya a stdout y luego colocarla en gunzip para asegurarme de que sea confusa y pequeña cuando no se canalice a través de gzip y grande y html cuando se canalice a través de gzip ...

nroose

Usando wget, ¿Cuál es el comando correcto para obtener la versión comprimida en lugar del HTML real?

Respuestas: