Question

11.8. 处理被压缩的数据

你要支持的最后一个重要的 HTTP 特性是压缩。 许多 web 服务具有发送压缩数据的能力, 这可以将网络线路上传输的大量数据消减 60% 以上。 尤其适用于 XML web 服务, 因为 XML 数据 的压缩率可以很高。

服务器不会为你发送押送数据，除非你告诉服务器你可以处理压缩数据。

例 11.14. 告诉服务器你想获得压缩数据

>>> import urllib2, httplib
>>> httplib.HTTPConnection.debuglevel = 1
>>> request = urllib2.Request('http://diveintomark.org/xml/atom.xml')
>>> request.add_header('Accept-encoding', 'gzip')        
>>> opener = urllib2.build_opener()
>>> f = opener.open(request)
connect: (diveintomark.org, 80)
send: '
GET /xml/atom.xml HTTP/1.0
Host: diveintomark.org
User-agent: Python-urllib/2.1
Accept-encoding: gzip                                    
'
reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Thu, 15 Apr 2004 22:24:39 GMT
header: Server: Apache/2.0.49 (Debian GNU/Linux)
header: Last-Modified: Thu, 15 Apr 2004 19:45:21 GMT
header: ETag: "e842a-3e53-55d97640"
header: Accept-Ranges: bytes
header: Vary: Accept-Encoding
header: Content-Encoding: gzip                           
header: Content-Length: 6289                             
header: Connection: close
header: Content-Type: application/atom+xml

	这是关键: 一旦你已经创建了你的 Request 对象, 就添加一个 Accept-encoding 头信息告诉服务器你能接受 gzip 压缩数据。 gzip 是你使用的压缩算法的名称。 理论上你可以使用其它的压缩算法, 但是 gzip 是 web 服务器上使用率高达 99% 的一种。
	这是你的头信息传越网络线路的过程。
	这是服务器的返回信息: Content-Encoding: gzip 头信息意谓着你要回得的数据已经被 gzip 压缩了。
	Content-Length 头信息是已压缩数据的长度, 并非解压缩数据的长度。 一会儿你会看到, 实际的解压缩数据长度为 15955, 因此 gzip 压缩节省了 60% 以上的网络带宽!

例 11.15. 解压缩数据

>>> compresseddata = f.read()                              
>>> len(compresseddata)
6289
>>> import StringIO
>>> compressedstream = StringIO.StringIO(compresseddata)   
>>> import gzip
>>> gzipper = gzip.GzipFile(fileobj=compressedstream)      
>>> data = gzipper.read()                                  
>>> print data                                             
<?xml version="1.0" encoding="iso-8859-1"?>
<feed version="0.3"
  xmlns="http://purl.org/atom/ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xml:lang="en">
  <title mode="escaped">dive into mark</title>
  <link rel="alternate" type="text/html" href="http://diveintomark.org/"/>
  <-- rest of feed omitted for brevity -->
>>> len(data)
15955

	继续上面的例子, f 是一个从 URL 开启器返回的类似文件的对象。 使用它的 read() 方法将正常地获得非压缩数据, 但是因为这个数据已经被 gzip 压缩过, 所以这只是获得你想要的最终数据的第一步。
	OK, 只是先得有点儿凌乱的步骤。 Python 有 gzip 模块, 它读取 (并实际写入) 磁盘上的 gzip 压缩文件。 但是磁盘上还没有文件, 只在内存里有一个 gzip 压缩缓冲区, 并且 你不想仅仅为了解压缩而写出一个临时文件。 那么怎么做来创建一个内存数据 (compresseddata) 之外的类似文件的对象呢, 需要使用 StringIO 模块。 你首次看到 StringIO 模块是在 上一章, 但现在你会发现它的另一种用法。
	现在你可以创建 GzipFile 的一个实例, 并且告诉它其中的 “file” 是一个类似文件的对象 compressedstream。
	这是做所有工作的一行: 从 GzipFile 中 “读取” 将会解压缩数据。 感到奇妙吗? 是的, 它确实解压缩了数据。 gzipper 是一个类似文件的对象, 它代表一个 gzip 压缩文件。 尽管这个 “file” 并非一个磁盘上的真实文件; 但 gzipper 还是真正的从你用 StringIO 包装了压缩数据所创建的类似文件的对象中 “读取” 数据, 它仅仅是内存中的变量 compresseddata。 压缩的数据来自哪呢? 你通常从远程 HTTP 服务器下载, 然后从你用 urllib2.build_opener 创建的类似文件的对象中 “读取”。 令人吃惊吧, 这就是所有的步骤。 链条上的每一步都完全不知道上一步在造假。
	看看吧, 实际的数据 (实际为 15955 bytes)。

“等等!” 我听见你在叫。 “还能更简单吗!” 我知道你在想什么。 你在想那个 opener.open 返回一个类似文件的对象, 那么为什么不抛弃中间件 StringIO 而通过 f 直接访问 GzipFile 呢? OK, 或许你没想到, 但是别为此担心, 因为那样无法工作。

例 11.16. 从服务器直接解压缩数据

>>> f = opener.open(request)                  
>>> f.headers.get('Content-Encoding')         
'gzip'
>>> data = gzip.GzipFile(fileobj=f).read()    
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python23\lib\gzip.py", line 217, in read
    self._read(readsize)
  File "c:\python23\lib\gzip.py", line 252, in _read
    pos = self.fileobj.tell()   # Save current position
AttributeError: addinfourl instance has no attribute 'tell'

	继续前面的例子, 你已经有一个用 Accept-encoding: gzip 头信息设置的 Request 对象。
	简单地打开请求将获得你的头信息 (虽然还没下载任何数据)。 正如你从 Content-Encoding 头信息所看到的, 这个数据已经被 gzip 压缩发送了。
	从 opener.open 返回了一个类似文件的对象, 并且阅读头信息你可以获知, 你将获得 gzip 压缩数据, 为什么不简单地通过那个类似文件的对象直接访问 GzipFile 呢? 因为你从 GzipFile 实例 “读取” , 他将从远程 HTTP 服务器 “读取” 被压缩的数据并且立即解压缩。 这是个好主意, 但是不行的是它无法工作。 由 gzip 压缩的工作方式所致, GzipFile 需要存储其位置并在压缩文件上往返游走。当 “file” 是来自远程服务器的字节流时无法工作; 你能用它做的所有工作就是一次返回一个字节流, 而不是在字节流上往返。 所以使用 StringIO 这种看上去不雅的手段是最好的解决方案: 下载压缩的数据, 除此之外用 StringIO 创建一个类似文件的对象, 并从中解压缩数据。