Za pomocą wget, jakie jest właściwe polecenie, aby uzyskać wersję spakowaną gzip zamiast rzeczywistego HTML

Natknąłem się na tę stronę internetową, która mówi o tym.

Więc kiedy pobierasz całą stronę internetową, pobierając wersję spakowaną gzip, jakie jest właściwe polecenie?

Przetestowałem to polecenie, ale nie wiem, czy wget naprawdę dostaje wersję spakowaną gzip:

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/

Jeśli poprosisz o zawartość gzip (używając poprawnego kodowania: nagłówek gzip, co jest poprawne), rozumiem, że wget nie może wtedy odczytać treści. Tak więc skończysz na jednym, spakowanym gzipie pliku na dysku dla pierwszej trafionej strony, ale żadnej innej zawartości.

tzn. nie możesz użyć wget do żądania treści spakowanych gzipem i do ponownego uruchomienia całej witryny w tym samym czasie.

Myślę, że jest łatka, która pozwala wgetowi na obsługę tej funkcji, ale nie ma jej w domyślnej wersji dystrybucyjnej.

Jeśli podasz flagę -S, możesz stwierdzić, czy serwer WWW odpowiada poprawnym typem treści. Na przykład,

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]

Kodowanie treści wyraźnie określa gzip, jednak dla linux.about.com (obecnie),

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]

Zwraca tekst / HTML.

Ponieważ niektóre starsze przeglądarki nadal mają problemy z zawartością zakodowaną w gzip, wiele stron umożliwia to tylko na podstawie identyfikacji przeglądarki. Często wyłączają go domyślnie i wyłączają tylko wtedy, gdy wiedzą, że przeglądarka może je obsługiwać - i zwykle nie zawierają wget na tej liście. Oznacza to, że może się okazać, że wget nigdy nie zwraca treści gzip, nawet jeśli witryna wydaje się to robić w przeglądarce.

proste polecenie, aby uzyskać stronę HTML i skompresować ją lub uzyskać dowolny plik i skompresowany.

$ wget -qO - <url> | gzip -c > file_name.gz

aby uzyskać więcej informacji na temat opcji. użyj polecenia man.