Python二进制字符串编解码：Git对象解码报错及rb模式疑问

我尝试解码Git对象时编写了如下代码：

import zlib
import os

...
# 当前目录为.git/objects
for current, subs, files in os.walk('.'):
    for filename in files:
        # 格式为##/#{38}
        path = os.path.join(current, filename)[2:]

        # 存在'info/'和'pack/'目录，无需关注打包文件
        with open(path, 'r') as file:
            # 返回bytes对象，默认采用UTF-8编码而非旧编码
            # .decode()同样默认使用utf-8
            print(zlib.decompress(file.read()).decode())

但运行时遭遇了UnicodeDecodeError，正确的处理方式类似如下代码：

with open(path, 'rb') as file:
  data = zlib.decompress(file.read())
  header, content = data.split(b'\0', 1)

我有几个疑问需要澄清：

• 看到有评论称rb模式完全不进行解码，但输出的二进制字符串是可读的，这似乎不准确；
• 既然Git默认（且当前仓库）使用UTF-8编码，为何直接解码会失败？
• 若无法解码，二进制字符串为何能以b'This is a string'这类人类可读的形式呈现？

问题解答 #

关于rb模式的本质

rb模式确实是完全不做解码的，它会原封不动地读取文件的原始字节，返回Python的bytes对象。你看到的b'This is a string'只是Python对bytes对象的友好显示逻辑：当字节序列中的内容恰好对应ASCII或UTF-8可打印字符时，Python会把这些字节转换成对应的字符展示；而无法被打印的字节则会用\xXX这类十六进制格式表示。整个过程只是显示层面的优化，底层始终是未被解码的原始字节数据。

为何直接解码会失败

原因主要有三点：

1. Git对象的内容不一定是合法UTF-8：Git存储的blob对象可能是二进制文件（比如图片、压缩包），这些内容本身就不是文本编码，自然无法用UTF-8解码；就算是文本文件，若文件本身用非UTF-8编码（如GBK）编写，或包含特殊控制字符，解码也会失败。
2. 文本模式读取的损坏：最初代码用'r'文本模式读取Git对象文件，而Git对象是压缩后的二进制数据。文本模式会自动做一些隐式转换（比如Windows下的换行符替换），导致读取的字节序列被破坏，zlib解压后的数据不完整或损坏，最终触发解码错误。
3. Git对象的结构限制：Git对象的格式是「头部字符串\0实际内容」，头部是ASCII编码，但后续的内容类型不固定，不能直接整体解码。

正确的处理逻辑

必须用rb模式读取原始二进制数据，解压后先通过空字节b'\0'分割出头部和内容：

• 头部（如b'commit 123'）是ASCII编码，可以直接解码；
• 内容部分则要根据对象类型判断：commit、tree、tag对象的内容是UTF-8文本，可安全解码；blob对象需对应原始文件类型，二进制文件保留字节，文本文件按对应编码解码。

内容的提问来源于stack exchange，提问作者user18348324