机器人交易压缩包验收：目录路径与接收位置怎样说明

机器人交易资料常被打包发送，接收方看到“解压成功”就开始整理报告，容易忽略压缩包内部路径与约定接收位置之间的关系。验收应先确认包内是什么、供方希望如何组织，以及是否有明确的接收说明。本文讨论防御性的资料审阅，不打开或执行未知包内程序，也不提供任何用于突破目录限制的示例。

先确定资料包的交付用途

买方可以要求供方说明压缩包是报告集合、软件交付还是二者混合。不同内容有不同接收流程，不能因为它们装在一个容器里就允许所有文件进入同一工作位置。若约定只是查看报告，应让供方明确报告入口和所需附件，减少接收人员根据文件外观自行判断的空间。

假设资料清单写了“检测报告及附图”，包内却出现用途未说明的其他内容。此时应保留原包和清单关系，请供方解释或重新提供范围明确的交付件。不能为了尽快整理而删除不熟悉文件，再把编辑后的目录当作原始交付结果，也不能直接把未知内容当成正常安装材料。

Python官方zipfile文档提醒，处理不可信来源的压缩包前应进行检查，并解释提取成员时与路径有关的注意事项。该提醒支持先审阅再决定后续处理的顺序，并不意味着所有工具、所有版本都具有同样的路径处理行为。

接收单位可以让具备权限的人员按既有流程检查目录列表和交付说明。本文不执行这些操作，也不把文件扩展名、压缩成功提示或来源名称当成包内内容无风险的保证。若缺少适用工具和责任安排，应暂停未知内容的处理，由供方补交更明确的资料，而不是临时扩大接收权限。

MITRE的CWE-22说明讨论了路径名没有被正确限制在预定目录范围内的问题。这里引用它是为了说明接收范围的必要性，不是认定某个交易包存在该弱点，更不是给出构造或利用路径的方法。

资料交付说明可以指出预期目录结构和允许使用的接收位置，并让负责人员按其管理流程处理。包内名字描述一种组织关系，实际写入位置属于接收环境的决定，二者需要明确关联。对于无法解释的成员路径，应保留问题和原件，由供方澄清，而不是靠接收人员猜测哪种写法能够通过工具处理。

若供方回复需要执行安装程序才能读取报告，应重新确认这是否属于原约定范围，并由有权限的人员决定。资料验收不应成为隐含的软件安装授权。接收方可以要求提供适合已约定阅读方式的文档版本，同时保留原始交付说明，不把方便阅读与允许运行混为一谈。

供方补交新的压缩包时，应说明调整了哪些目录或交付内容，原清单是否仍适用。接收方保留旧问题、新包及对方说明之间的关系，再按批准流程决定后续操作。只更换文件名，不能说明之前的问题已经解决；重新打包也不自动证明所有报告事实已经核实。

若既有流程要求临时接收位置或恢复记录，应由相应责任人维护。编辑应记录实际发生的处理和结果，不应为了文章演示而创建、移动或清空任何真实目录。对于仍待解释的内容，继续保持待核状态，比把一次提取提示当成整包验收结论更清楚。

最终记录至少要让后续人员理解交付用途、目录说明、允许处理范围及尚未完成的审阅。容器能够被读取，只说明某项技术处理发生，不代表报告已被接受，更不能证明设备现状或交易权属。本文没有测试真实包，也没有报告任何漏洞或实际提取结果。

配图为原创接收关系示意，不含路径攻击样例和实际文件树。更多资料核验主题可见机器人交易核验栏目及文章目录。先明确允许接收什么，再决定如何继续处理，有助于让交付双方围绕具体内容沟通。