Python二进制文件怎么读写_rb/wb模式处理图片与音频流

关于二进制模式读写图片和音频，很多开发者踩过“文件损坏”的坑——不是说加了 rb 或 wb 就万事大吉。问题本质在于：Python 只是原样搬运字节，既不负责编码转换，也不替你校验数据完整性。读少了、写错了、换行符被转了、帧边界对不上……任何一个环节出偏差，图片解码器直接报错或者音频播放器静音处理。

rb/wb 模式读写图片时，为什么文件损坏或打不开

二进制模式不是“加个 b 就完事”，核心在于：Python 不做编码转换，但也不帮你校验数据完整性。你读多少字节、写多少字节，它就原样搬，中间出一丁点错，图片头信息或音频帧结构就断了。

• rb 读取时若没读全（比如用 read(1024) 分块但没循环到 EOF），后续写入的只是碎片，图片解析器直接报 Corrupted JPEG 或静音
• wb 写入前如果误把字符串传进去（比如 f.write("hello")），会抛 TypeError: a bytes-like object is required —— 这是 Python 在拦你，不是系统在拦
• Windows 下用 text 模式写图片（哪怕加了 encoding="latin-1"）会悄悄把 \r\n 换行符转义，音频播放器读到异常换行就卡住

用 open(..., "rb") 读大图片时内存爆了怎么办

直接 read() 整张图加载进内存，10MB 的 PNG 就占 10MB 字节对象，还带 Python 对象头开销。不是不能读，是没必要——尤其你只是想缩放、提取 EXIF 或转发到 HTTP 响应。

• 优先用分块读：chunk = f.read(8192)，配合 while chunk: 循环处理，边读边传、边读边解析
• 需要随机访问（比如读 PNG 的 IHDR 块）？用 f.seek(16) 跳到第 16 字节再 read(4)，别全读
• 真要加载整图做 PIL 处理？交给 PIL.Image.open()，它内部已优化二进制流解析，你传 io.BytesIO(data) 比自己 read() 更稳

音频文件（MP3/WA V）用 wb 写入后时长变短或无法播放

音频格式对字节序、帧边界、末尾填充极度敏感。写入时多一个字节、少一个字节、错位一个字节，解码器可能静音、跳秒，甚至崩溃。

• 确认源数据是完整帧：从 requests 下载 MP3 时，检查 r.content 长度是否和 Content-Length 一致；用 ffmpeg -v error -i input.mp3 -f null - 验证原始流是否合法
• 不要拼接字节串再写：比如 header + data + footer，MP3 没标准 footer，WA V 的 data 子块长度字段必须精确反映后续字节数，手算易错
• 写入后立刻用 os.stat(path).st_size 核对大小，和源文件比对；再用 ffprobe -v quiet -show_entries format=duration input.mp3 看时长是否匹配

rb 读取后怎么安全转成 base64 或传给 FastAPI 的 Response

base64 编码的是字节，不是字符串；FastAPI 的 Response(content=...) 也要求 bytes。中间任何一次误 decode/encode，都会引入不可逆损坏。

• rb 读出就是 bytes，直接传给 base64.b64encode(data)，结果仍是 bytes，如需字符串再 .decode("ascii")
• FastAPI 中返回图片：用 Response(content=data, media_type="image/png")，content 必须是 bytes，别用 json.dumps({"img": data}) —— 那会触发默认字符串序列化，彻底乱码
• 调试时用 data[:10].hex() 快速看开头 10 字节十六进制（PNG 是 89504e47，JPEG 是 ffd8ffe0），比打印整个 bytes 可读性强得多

事情说清了就结束。二进制操作不难，难在每一步都得盯着字节本身——它不讲道理，也不报错，只默默给你一张黑图或一段无声。