zipfile should reject inconsistent disk information in EOCDR

Bug report

Bug description:

zipfile is explicitly documented as not handling multipart (i.e. multi-disk) ZIPs.

However, zipfile also does not check the EOCDR's state for consistency with that invariant.

Two fields are relevant (offsets are relative to the start of the EOCDR):

• "number of this disk" (offset 4, size 2)
• "number of the disk with the start of the central directory" (offset 6, size 2)

In zipfile's model, both of these should always be 0, since there's exactly one "disk."

However, at the moment, zipfile appears to silently ignore these fields and allows a parse even when they're incoherent or inconsistent with each other. For example:

import io
import struct
import zipfile

archive = io.BytesIO()
with zipfile.ZipFile(archive, "w") as zipf:
    zipf.writestr("entry.txt", b"payload")
data = bytearray(archive.getvalue())
eocd = data.rfind(zipfile.stringEndArchive)
struct.pack_into("<H", data, eocd + 4, 1)
with zipfile.ZipFile(io.BytesIO(data)) as zipf:
    print(zipf.namelist())

This exposes ['entry.txt'], whereas other parsers (Rust's zip and async_zip, Info-ZIP, and 7-ZIP) reject the ZIP as malformed.

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-155814

首先重現 issue 中的 BytesIO 範例，並追蹤 zipfile 對 EOCDR 的解析，重點關注位於偏移量 4 和 6 的兩個磁碟編號欄位。當包含非零或不一致磁碟資訊的格式錯誤封存檔遭到拒絕，而不是成功解析時，即表示完成；issue 連結了 PR gh-155814，以跟進正在進行的工作。