收到一个压缩包不要急着解压就归档。正确顺序是：先登记原包来源和基本信息、列出包级摘要，再在独立工作目录里解压并逐项核对，原包作为交付来源凭证按保管要求保留。

为什么不能直接解压完就把原包删掉？因为压缩包是对方交付内容的原始载体。日后如果对交付内容有疑问——比如对方说"我明明发了五份附件，你们怎么只归档了四份"——你手里如果没有原包，就很难协助核对对方当时交付了什么。注意：原包本身只能作为核对交付内容的依据之一，最终仍要结合邮件、IM等来源记录一起判断，不能说"有原包就等于证明一切"。

### 第一步：做包级摘要登记

对方通过邮件、IM或共享链接发来一个压缩包，归档动作的第一步不是打开它，而是把它当作一个"待清点的包裹"登记下来。这里记的是包级摘要：压缩包文件名、文件大小、本层成员数、嵌套包数量、来源渠道、实际接收时间、原包ID和保管位置。注意，压缩包元数据里的"压缩日期"不等于对方实际发送或你方接收的时间，来源时间要以邮件或IM记录为准。下面是一张包级摘要表（虚构演示，非真实客户记录）：

| 原包ID | 压缩包文件名 | 大小 | 本层成员数 | 嵌套包数（本层） | 来源渠道 | 接收时间 | 保管位置 |
|---|---|---|---|---|---|---|---|
| PKG-2026-0928-01 | 2026Q4客户资质材料.zip | 47.3 MB | 21个文件加2个子文件夹 | 2个（本层） | 客户张经理邮箱 | 2026-09-28 14:22 | 业务文件夹/原包/ |
| PKG-2026-1008-02 | 项目部交付图纸.rar | 128.6 MB | 55个文件加1个子文件夹 | 1个（本层） | 项目部李工IM | 2026-10-08 09:15 | 业务文件夹/原包/ |
| PKG-2026-1009-03 | 供应商营业执照扫描.zip | 8.2 MB | 6个文件，无子文件夹 | 0 | 供应商王姐邮件 | 2026-10-09 16:40 | 业务文件夹/原包/ |

这张表的作用，是在你还没解压之前，就先对外记录"我收到的是这么一个包"。文件名、大小、成员数要以压缩包软件查看时显示的为准，不要凭对方一句"里面资料都齐了"就填。

### 第二步：解压并做结果核对

解压时建议在一个独立的工作目录里进行，不要直接在原包所在文件夹里解。解压前先确认来源可靠、文件类型正常。解压完成后，把包内完整路径和实际解压结果逐项对照。下面这张表把包内目录和解压结果合并呈现（虚构演示，非真实客户记录）：

| 原包ID | 包内路径 | 解压后文件 | 是否成功 | 嵌套/加密情况 | 失败项处理 |
|---|---|---|---|---|---|
| PKG-2026-0928-01 | 01-营业执照/正副本.pdf | 正副本.pdf，1.8MB | 成功 | 无 | — |
| PKG-2026-0928-01 | 02-资质证书/安全生产许可证.jpg | 安全生产许可证.jpg，2.4MB | 成功 | 无 | — |
| PKG-2026-0928-01 | 03-人员名单/社保明细.zip | 社保明细.zip，3.1MB | 本层解压成功 | 是嵌套包，需二次解压 | 已二次解压，展开后含5份PDF，已登记 |
| PKG-2026-0928-01 | 04-财务报表/2025审计报告.pdf | 解压报错，文件损坏 | 失败 | 无 | 已登记异常，联系发件方重发 |
| PKG-2026-0928-01 | 05-授权委托书/法人授权书扫描.pdf | 该文件为密码保护PDF | 未打开（非解压问题） | 文档打开密码，与解压无关 | 已向发件人索取文档打开密码 |

这张表把"原包里有什么"和"我实际拿到了什么"对齐。几个细节要标清楚：嵌套包数量写的是"本层"还是"展开后总数"；压缩后的体积不能和解压后的总大小直接比较；加密目录如果暂时无法读取，就写"未知"，不要猜。

**关于核对深度。** 文件数和总大小对上，不等于逐项核对完成。两个包都是二十几个文件、总大小差不多，仍可能出现"原包里有A没B，解压后有B没A"的情况。关键文件要按风险核对内容是否完整、能否正常打开；必要时用同一算法做校验比对。失败项、未知项没有关闭之前，不要在台账里写"核对通过"。

### 第三步：原包和散落文件怎么存

一个常见的困惑是：原包要不要在系统里保留？解压出来的文件要不要再单独归档？建议的做法是双轨：

- **原包按保管要求整体保留**，放在对应业务文件夹下，文件名保持对方发来时的原名，不要改名、不要重新打包。它是交付来源凭证。
- **解压后有用的文件**，按企业既有的分类和记录方式归档到对应目录，作为日常检索和查阅的工作副本。
- 两者之间通过同一条业务记录关联：谁解压的、什么时候解的、核对表存在哪里，都记一笔。

这样做的好处是：日常找资料，你查的是解压后归档的单文件；一旦发生交付内容争议，你能调出原包，结合邮件或IM记录协助核对对方当时交付了什么。

### 几个实操提醒

**不要自动解压后删除原包。** 有些同步盘或邮件工具会自动把压缩包解压后清理原文件，这种行为在资料归档场景下要留意关掉。原包的保留跟随该业务事项的档案保管要求。

**嵌套包要拆开，但要设安全停止条件。** 第一层包里套着第二层zip，第二层里可能还有第三层。拆开前先核来源和文件类型，不要运行包内的程序、脚本、宏文件。如果遇到不合理的深层嵌套、解压后容量异常暴增、路径越界（比如试图写入目标目录之外）、重名文件可能被覆盖、或者企业防护工具告警，应立即停止解压并交IT处理，不要无限递归展开。敏感压缩包不要交给公开的在线解压或扫描网站。OWASP在文件上传安全指引中列出了压缩炸弹、覆盖写入和解压后容量失控等风险，这里的停止条件就是针对这些场景。

**加密压缩包和密码保护PDF要分清。** "加密"可能指整个压缩包解压需要密码，也可能指包内某个PDF文件打开时需要密码。前者是解压环节的问题，后者是文档阅读环节的问题，不要混为一谈。遇到密码，正确做法是向发件人索取。

**关于密码存放。** 解压密码不要写进普通业务备注，也不要和原包放在同权限的说明文件里——否则一次普通文件分享或全文检索就可能把密码带出去。密码应存入企业已有的受控凭证保管渠道，比如IT统一管理的密码工具或保险柜登记；普通归档台账里只记录"密码由谁保管、在哪个受控索引里取用"，不写明文密码。这是权限隔离和最小知悉范围的原则，不要求为此新购一套系统。

**为什么不建议暴力破解。** 原因首先是授权和安全边界：密码保护意味着对方明确设置了访问控制，绕过它在授权上站不住脚；其次是安全风险，不明来源的包被强行解压，可能触发恶意内容。不要把理由写成"破解出来文件一定损坏"这种没有依据的说法。

**文件名乱码怎么办。** 常见原因包括压缩时使用的中文编码与解压软件默认编码不一致。可以尝试在解压工具中选择正确的编码重新解压，但这只是常见可能性之一，不保证换编码一定解决；如果重解后仍乱码，记录现状并联系发件方重新提供清晰命名的文件。不要手动批量改文件名，否则和原包目录对不上。

在企业资料管理实践中，原包可以放在获准的保管位置，并附上包级摘要和核对表作为说明材料；解压后有用的单份文件按企业既有分类方式归档。资料管理工具不替你做"自动解压、自动删除原包"这种动作，因为原包本身就是要被保管的交付来源，删不删、什么时候删，应由档案保管规则决定。

## 常见问题

**Q1：对方发来的压缩包密码写在邮件正文里，归档时密码要记在哪？**
密码交由企业已批准的受控渠道保存，普通归档备注只留保管责任人和取用索引，不要写明文密码。不要把密码写进会随文件分享、导出或被全员检索的说明文档；离职交接时按权限移交取用方式，不直接扩大知悉范围。

**Q2：解压出来的文件名乱码怎么办？**
常见原因是压缩时使用的中文编码与解压软件默认编码不一致。可在解压工具中尝试选择正确编码重新解压，但这只是可能性之一，不保证一定解决；仍乱码时联系发件方重新提供，不要手动批量改名以免和原包目录对不上。

**Q3：原包保留多久？**
原包保留期跟随该业务事项的档案保管要求，按公司制度执行。在保管期内不要主动删除；到期后按档案销毁流程统一处理，不要单独挑某几个包删。

**Q4：一个压缩包里既有敏感文件又有公开资料，怎么设权限？**
原包作为整体保存时，访问范围按包里最敏感的那份文件来设置。解压后单份文件归档时，再按各自密级分别配权限，不要因为原包权限松了就导致敏感件被无关人员看到。