gzip.GzipFile反向seek失败是文件损坏吗？附场景与疑问

我有一批带8字节自定义头部（例如zrxxxxxx）的文件，头部之后是标准gzip压缩数据流。常规读取操作正常，但执行反向seek时会失败，复现代码如下：

from gzip import GzipFile

f = open('test.bin', 'rb')
f.read(8)  # 跳过自定义头部

h = GzipFile(fileobj=f, mode='rb')
h.seek(8192)
h.seek(8191)  # 抛出异常：gzip.BadGzipFile: Not a gzipped file (b'zr')

无法分享测试文件，但同类结构的文件均可复现该问题。

调试发现问题根源在Lib/_compression.py中的DecompressReader.seek方法，当执行反向seek时，_rewind函数会把原始文件指针重置到开头：

#...
# Rewind the file to the beginning of the data stream.
def _rewind(self):
    self._fp.seek(0)
    #...

def seek(self, offset, whence=io.SEEK_SET):
    #...
    # Make it so that offset is the number of bytes to skip forward.
    if offset < self._pos:
        self._rewind()
    else:
        offset -= self._pos
    #...

请问这是Python的bug还是用法错误？有没有简单的解决办法？

• 这不是用法错误，是Python标准库gzip模块的设计缺陷：GzipFile默认假设传入的fileobj起始位置就是gzip数据流的开头，所以反向seek时调用的_rewind会直接把文件指针重置到fileobj的0位置（也就是自定义头部的起始点），导致后续读取时把自定义头部当成gzip数据，抛出错误。

• 简单解决办法：封装一个自定义文件对象，让它的seek(0)指向gzip数据流的起始位置（即跳过8字节后的位置），而非原始文件开头。示例代码如下：

from gzip import GzipFile
import io

class OffsetFileWrapper(io.IOBase):
    def __init__(self, fp, offset):
        self.fp = fp
        self.offset = offset
        # 确保文件指针初始处于gzip数据流起点
        self.fp.seek(offset)
    
    def seek(self, pos, whence=io.SEEK_SET):
        if whence == io.SEEK_SET:
            return self.fp.seek(self.offset + pos)
        elif whence == io.SEEK_CUR:
            return self.fp.seek(pos, io.SEEK_CUR)
        elif whence == io.SEEK_END:
            return self.fp.seek(pos, io.SEEK_END)
        raise ValueError("Invalid whence value")
    
    def tell(self):
        return self.fp.tell() - self.offset
    
    def read(self, size=-1):
        return self.fp.read(size)
    
    def readinto(self, b):
        return self.fp.readinto(b)

# 使用示例
f = open('test.bin', 'rb')
# 用封装后的文件对象替代原始文件，指定偏移量为8
wrapper = OffsetFileWrapper(f, 8)
h = GzipFile(fileobj=wrapper, mode='rb')

h.seek(8192)
h.seek(8191)  # 现在可正常执行，不会抛出异常

• 原理：这个封装类将seek(0)映射到原始文件的offset位置（即gzip数据流的起始点），当DecompressReader._rewind调用seek(0)时，实际指向的是正确的gzip数据开头，避免读取到自定义头部。

内容的提问来源于stack exchange，提问作者Michel de Ruiter