一包 ZIP 资料交给 Agent，怎样先检查目录再安排解析

一包ZIP资料交给Agent后，先列成员清单并判断能否受控展开，再让各类解析器读取文件。压缩包能打开，只说明工具识别了外层容器；它没有证明所有成员可处理，也没有证明内部目录可以直接写到服务器。

下面使用合成目录演练接收预检。产物是压缩包清单和处置决定，不检查项目是否交齐验收材料，也不执行包内任何文件。

清单应在展开之前产生

先给接收包一个稳定编号，保存原包、接收时间、大小和来源。遍历成员时读取原始成员名、声明大小、压缩方式和目录标记，再生成拟处理路径。原名与规范化路径分开留存，便于定位乱码、重复成员和异常路径。

Python zipfile官方文档说明了成员信息和不同压缩方式的支持限制，也提醒提取不可信压缩包需要检查。若采用这一工具，应核对实际运行版本及可用压缩模块，不能照着文档中最新版本的功能假定客户环境已经具备。

接收规则由实施方和资料管理员共同确定：允许哪些格式、最多展开多少层、单个成员与总展开量的上限、失败后放在哪个待处理区。具体数值应从客户样本和环境约束决定，不在没有验证时给出通用容量承诺。

成员名可能包含上层目录跳转、绝对路径或不同系统的路径分隔方式。应先解析并核对最终位置仍在指定接收目录内，再允许生成文件。检测到异常时记录成员名和拒绝原因，不能为了“尽量处理完”去掉几个字符后继续写入未知位置。

同名成员也要单独检查。一个包里可以出现显示名称相近甚至完全相同的记录，如果默认后写覆盖前写，清单数量与实际保留数量就会不同。给每个成员独立接收标识，冲突交人工选择，不静默保留最后一份。

嵌套压缩包先登记为容器候选。是否继续展开应重新经过同样预检，并累计资源预算。不能只在最外层限制大小，后续每层都重新从零计算，否则多层容器仍可能造成远超预期的展开量。

下载压缩包目录演练。附件是可复建的合成成员清单与处置预期，没有声称附带已经解压或扫描过的真实ZIP。

普通文本成员可以进入解析队列；内部另有ZIP时先挂起为待展开容器；出现异常路径时拒绝写入。附件还提供同名成员与不支持压缩方式的情形。业务团队可以按表建立自己的测试包，再填写所用工具版本和真实结果。

清单中的“声明大小”不是已验证的实际展开量。实际处理仍需按读取进度控制资源，发生不一致时中止该成员并记录。压缩比异常可以作为风险信号，却不能独立判定资料恶意，也不能成为自动删除整个原包的理由。

拒绝表示触犯接收规则，例如路径越界；跳过表示资料不在当前处理范围，例如可执行文件；失败表示本来允许但读取不成功，例如内容损坏或缺少对应压缩模块。三类原因分别交给安全管理员、资料所有者或实施人员。

如果解开五个成员后第六个失败，原始包与清单仍应保存，已完成成员不应悄悄消失。重跑时要能确认哪些副本来自哪次接收，避免把第一次的结果和第二次的新包混合成一次完整交付。需要恢复批任务时，可衔接失败记录与重跑方法，但预检本身不负责改写整个任务恢复系统。

人工挑选一个包，对照原始目录逐项数成员，确认目录项、普通文件与嵌套容器没有混算。再比较清单与实际保留副本，任何被跳过、拒绝或失败的成员都应有理由与下一步，而不是只给一个成功比例。

检查路径时还应在目标操作系统做演练，因为大小写规则、保留文件名和字符规范可能不同。开发环境通过的目录，不代表在客户服务器上一定产生相同文件布局。公开演示只使用虚构目录，真实路径在受控范围内交换。

资料接收后再按文件类型安排文档处理，整体移交范围可先参考资料台账。如果资料经常以多层压缩包交付，可带一份脱敏目录与拟定接收规则，通过定制咨询先确定预检清单和异常交接范围。