質問

私は、curlを使用してウェブサイトから出力を取得し、html出力で多くの文字列操作を行うbashスクリプトを書きました。問題は、出力をgzipで返したサイトに対してそれを実行したときです。ブラウザでそのサイトにアクセスするとうまくいきます。

curlを手動で実行すると、gzip形式の出力が得られます。

$ curl "http://example.com"

これは、その特定のサイトのヘッダーです。

HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=utf-8
X-Powered-By: PHP/5.2.17
Last-Modified: Sat, 03 Dec 2011 00:07:57 GMT
ETag: "6c38e1154f32dbd9ba211db8ad189b27"
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: must-revalidate
Content-Encoding: gzip
Content-Length: 7796
Date: Sat, 03 Dec 2011 00:46:22 GMT
X-Varnish: 1509870407 1509810501
Age: 504
Via: 1.1 varnish
Connection: keep-alive
X-Cache-Svr: p2137050.pubip.peer1.net
X-Cache: HIT
X-Cache-Hits: 425

これは予想通りhtmlを返すので、返されたデータはgzipされていることがわかります。

$ curl "http://example.com" | gunzip

なぜなら、このスクリプトは他のサイトではそのまま動作し、gzipを通してパイプを通すとその機能が壊れてしまうからです。

試してみたこと

1. ユーザーエージェントを変更する（ブラウザが送信するのと同じ文字列、"Mozilla/4.0"などを試しました）。
2. man curl
3. グーグル検索
4. stackoverflowの検索

すべて空振り

何か思い当たることはありますか？

解決方法は？

curl を設定すると、自動的にレスポンスが伸長されます。 --compressed フラグを使用します。

curl --compressed "http://example.com"

--圧縮 (HTTP) libcurl がサポートするアルゴリズムの 1 つを使用して圧縮されたレスポンスを要求し、圧縮されていないドキュメントを保存します。 このオプションが使用され、サーバーがサポートされていないエンコーディングを送信した場合、curl はエラーを報告します。

gzipがサポートされている可能性が高いですが、これを確認するには curl -V を検索し libz Features"の行のどこかにあるはずです。

$ curl -V
...
Protocols: ...
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

ここで、本当に悪いのは問題のあるウェブサイトであることに注意してください。もし curl を渡さなかった。 Accept-Encoding: gzip リクエストヘッダがない場合、サーバーは圧縮されたレスポンスを送信するべきではありませんでした。