Python zipfile.ZipFile 怎样用 ZIP64 写入超大文件

用 Python 生成可能超过传统 ZIP 限制的压缩包时，通常不需要手工拼接 ZIP64 字段。zipfile.ZipFile 的 allowZip64 默认就是 True，它允许归档在需要时使用 ZIP64 扩展。真正容易写错的是：磁盘文件大小已经确定时用 write()，数据大小尚未确定时则要在流式写入中使用 force_zip64=True。

官方地址：https://docs.python.org/3.14/library/zipfile.html

结论：已知大小的文件保持 allowZip64=True 后直接调用 ZipFile.write()；未知大小但可能超过 2 GiB 的流，使用 ZipFile.open(name, mode="w", force_zip64=True)，并确保最后关闭归档。

先分清 allowZip64 和 force_zip64

ZIP 的传统字段对单个文件大小、归档总大小和条目数量都有较小的表示范围。ZIP64 是扩展格式，允许这些值突破传统字段的限制。Python 里的两个参数分别位于不同层面：

• allowZip64 是 ZipFile 的归档级开关，默认值为 True。设为 False 时，只要最终归档需要 ZIP64，写入就会抛出 LargeZipFile。
• force_zip64 是 ZipFile.open() 写入模式的成员级选项。它适合文件大小暂时未知、但之后可能超过 2 GiB 的流式成员，让写入头部预留 ZIP64 所需格式。

因此，force_zip64=True 不能替代 allowZip64=True。前者解决“这个成员写入前不知道多大”，后者解决“整个归档是否允许使用 ZIP64”。

磁盘文件大小已知时直接使用 write

如果输入是磁盘上的普通文件，zipfile 可以在写入前取得文件大小。此时不需要为了 ZIP64 自己计算头部字段，保持默认配置即可。代码中的注释只说明关键边界和资源关闭点：

from pathlib import Path
from zipfile import ZipFile, ZIP_DEFLATED

source = Path("large-export.bin")
archive = Path("backup.zip")

# 默认 allowZip64=True，允许归档在超过传统 ZIP 范围时使用 ZIP64。
with ZipFile(archive, "w", compression=ZIP_DEFLATED, allowZip64=True) as zf:
    # write() 面向磁盘文件，zipfile 可以先读取文件元数据再写入成员。
    zf.write(source, arcname=source.name)

# with 退出时会关闭归档并写入目录；不要在目录尚未写完时读取 ZIP。

这里的 arcname 只控制压缩包内的成员名，不会把本机绝对路径暴露到归档中。ZIP_DEFLATED 需要当前 Python 环境提供 zlib；若只关注体积边界而不需要压缩，也可以使用默认的 ZIP_STORED。

数据大小未知时使用 force_zip64

流式导出、网络响应转存或生成器输出通常没有一个可以提前交给 ZipFile 的最终大小。此时使用 ZipFile.open() 的写入句柄，并把 force_zip64 设为 True：

from zipfile import ZipFile, ZIP_DEFLATED

archive = "stream-export.zip"

with ZipFile(archive, "w", compression=ZIP_DEFLATED, allowZip64=True) as zf:
    # force_zip64 为未知长度但可能很大的成员预留 ZIP64 写入格式。
    with zf.open("records.ndjson", mode="w", force_zip64=True) as member:
        for index in range(100_000):
            # 每次只写一条记录，避免把整个导出结果堆进内存。
            line = f'{{"id": {index}, "state": "ready"}}\n'.encode("utf-8")
            member.write(line)

# 两层 with 都退出后，成员数据和归档目录才完整落盘。

如果能够可靠地预先知道成员大小，也可以构造 ZipInfo 并设置 file_size，但对于边生成边写入的场景，force_zip64=True 更直接。它不会替你限制内存、磁盘或输入流长度；生产代码仍应在外层设置配额和取消策略。

为什么仍然会收到 LargeZipFile

遇到 LargeZipFile 时，可以按下面的边界判断，而不是只把 force_zip64 加到所有调用上：

1. 归档显式关闭了 ZIP64：检查创建 ZipFile 时是否传入了 allowZip64=False。需要大归档时应删除这个限制或改为 True。
2. 流式成员没有预留格式：如果用 zf.open(name, "w") 写入未知大小数据，而且成员可能超过传统范围，补上 force_zip64=True。
3. 关闭动作没有执行：ZIP 的中央目录在归档关闭时写入。异常路径中如果没有进入 with 的退出逻辑，得到的文件可能不完整，后续读取会表现为坏归档，而不是正常的 ZIP64 结果。
4. 读取端过旧：写入成功不等于所有下游工具都支持 ZIP64。需要把归档交给旧系统时，应先确认对方支持 ZIP64，不能为了兼容而盲目关闭扩展。

另外，allowZip64 只控制 ZIP64 格式是否允许，并不代表程序可以无限写入。超大文件仍可能受到磁盘、进程权限、压缩库和业务配额限制。

按输入类型选择写法

最稳妥的判断顺序是：先确认下游是否支持 ZIP64，再看成员大小是否已知，最后选择 write() 或流式 open()。不要仅因为文件名带有“大文件”就把所有场景改成同一种调用。

常见问题

allowZip64=True 会把小文件强制写成 ZIP64 吗？

不会。它表示需要时允许使用 ZIP64，不等于每个归档都必须使用扩展格式。小文件仍可以保持普通 ZIP 表示。

force_zip64=True 应该和 ZipFile.write() 一起传吗？

不应该。它是 ZipFile.open() 写入句柄的参数；对磁盘文件直接使用 write() 时，让 zipfile 根据已知文件信息处理即可。

为什么压缩包关闭后才出现异常？

目录和最终大小信息要在关闭阶段写入，很多边界错误会因此延迟到 close() 或 with 退出时暴露。把关闭动作放进上下文管理器，才能让异常在写入流程中被调用方捕获。

记住一句话：allowZip64 决定归档能不能使用 ZIP64，force_zip64 解决未知长度成员如何安全开始写入；两者配合，才能覆盖磁盘大文件和流式大成员这两类场景。