压缩再解压，未必等于原样还原：包里还有「属性」这一半

7-Zip 的兼容列表里，除了自家的 7z，还列着 RAR、ZIP、CAB、ISO、ARJ、GZ、TAR。

一款软件支持这么多种格式，看起来只是"方便"。 但这份列表里其实藏着两类东西：

一类来自 Windows 世界（ZIP、CAB），一类来自 Unix 世界（TAR、GZ）。

它们保存的东西并不完全一样。 而这一点，决定了一个很常见却被忽略的事实：

"压缩再解压"，未必等于"原样还原"。

一、压缩包保存的不只是内容

很多人默认压缩包里装的就是"那些文件"。更准确地说，它装的是两样东西：

• 文件内容——那串字节
• 文件属性——时间、权限、所有者、是不是链接，等等

平时这两样几乎不会被注意到，因为大部分时候你只关心内容对不对。

但凡涉及跨系统搬运、或者做备份，"属性"这一半就会开始显形。

这里要先澄清一句最容易误解的话：

"无损压缩"的无损，指的是"文件内容"，不包括"文件系统上的属性"。

无损说的是"解压出来的字节和原来的字节一样"。 它不承诺"这个文件在你系统上的样子也一样"。

二、具体会丢什么：四类

第一类：时间戳。

这不是"保不保留"的问题，而是"格式能不能表达"的问题。

ZIP 来自早期 DOS 时代，它记录时间的字段本身就是那个年代的格式——精度有限，而且不含时区信息。所以一个 ZIP 里的时间，在不同时区、不同工具下解出来可能不一样。

TAR 那边的情况不同：它能记录更完整的时间信息。

所以"解压之后文件时间变了"，有时候不是软件没保留，而是那个格式存不下你要的那种时间。

第二类：权限与可执行位。

这一条是跨系统搬运时最常见的坑。

Unix 世界里，"这个文件能不能执行"是文件属性的一部分；而 Windows 那边不以这种方式使用权限。

于是会出现这样一条链路：

在 Linux 上打包一个脚本 → 在 Windows 上解压 → 再传回 Linux → 脚本不能执行了。

内容一个字节没丢，但"它应该是个可执行文件"这条信息在中间不见了。

这就是为什么跨系统传脚本或程序时，格式选择比压缩率重要得多。

第三类：符号链接。

链接这类东西比较特殊：它是"指向别处"这个事实本身，而不是一份内容。

有些格式可以记录"这里是个链接、指向哪里"；但解压的时候，还得解压端能够创建出链接来。

在权限不足或者系统不支持的环境里，常见的处理是把它展开成实际的文件——于是你会在解压出来的目录里看到一些"怎么多出来的"文件。

第四类：其他一些容易被顺手改掉的东西。

• 换行符：文本文件在不同系统上的行尾不同，有些工具解压时会"顺手转换"
• NTFS 的额外数据流：多数通用格式不保存
• 稀疏文件：保存方式不同，占用空间会变

三、为什么"能解压"不等于"能还原"

把上面几条合起来，就能看出这里有三个环节，任何一个都可能丢信息：

1. 打包时有没有记录（工具是否勾选了保留属性）
2. 格式里能不能保存（格式本身是否支持）
3. 解压时有没有还原（解压端是否具备了还原的条件）

这三步是串联的：任何一步不成立，最终结果就不一样。

所以判断"我的压缩包可靠吗"，不能只问"能不能打开"——能打开只说明第一步的内容部分通过了；这也是 7-Zip 的"压缩率"介绍里从来不会提的那一半。

四、按用途选格式

• 传文档、图片、视频（该关注什么：只关心内容；建议：什么格式都可以）
• 传要在 Linux 上执行的脚本（该关注什么：权限位；建议：用能保存权限的归档格式，不要用 ZIP）
• 保留原始时间（该关注什么：时间戳的表达能力；建议：选支持完整时间的格式）
• 搬运带链接的项目目录（该关注什么：链接能否被记录与创建；建议：避开会展开链接的格式与场景）
• 系统级备份（该关注什么：属性、系统结构；建议：压缩包不是镜像，两者目标不同）
• 只是想让文件变小（该关注什么：压缩率与耗时；建议：这才是压缩率发挥作用的场合）

最后一行值得单说："压缩"和"备份"是两件目标不同的事。

压缩的目标是"体积更小"；备份的目标是"能还原成原来的样子"。前者可以牺牲属性，后者不能。

用一个高压缩率的格式去做备份，方向就偏了。

五、怎么验证搬完是否一致

别只比内容。 先看一眼属性，再看内容：

Get-Item .\sample.txt %7C Select-Object Name, Length, LastWriteTime, Attributes

搬之前看一眼、搬之后再看一眼，两边的 LastWriteTime 和 Attributes 对不对得上就清楚了。

如果只关心内容是否一致，那就比对哈希：

Get-FileHash .\a.txt, .\b.txt -Algorithm SHA256 %7C Select-Object Hash

两个哈希一样，说明字节完全一致——但注意：这只证明"内容一样"，仍然不说明"属性一样"。

这两步要分开做，因为它们是两回事。

六、按现象定位

• 解压后文件时间变了（原因方向：格式的时间表达能力有限，或被解压端覆盖；处理方向：换格式，并确认解压选项）
• 脚本搬过去不能执行（原因方向：可执行位没被保存或没被还原；处理方向：改用能保存权限的格式）
• 解压出来多了一堆文件（原因方向：符号链接被展开成了实际文件；处理方向：属环境限制，非包损坏）
• 文本换行变了（原因方向：解压时做了行尾转换；处理方向：用二进制方式处理）
• 压缩包小了但还原不完全（原因方向：压缩与备份是两件事；处理方向：备份要另选方案）
• 哈希一致但"感觉不对"（原因方向：属性差异不在哈希里；处理方向：单独比对属性）

七、小结

关于 7-Zip 这类工具，记住四条：

• 压缩包保存的是"内容 %2B 属性"两半——平时只注意内容，跨系统搬运时属性那一半才会显形
• "无损压缩"的无损只针对内容：它承诺字节一样，不承诺文件在你系统上的样子一样
• 四类容易丢的信息：时间戳（受格式表达能力限制）、权限与可执行位、符号链接、以及换行符之类的细节
• 三个环节串联：打包时记录、格式能保存、解压时能还原——任何一步不成立，结果就不同

这里可以带走的经验是关于"无损"这个词的：看到"无损""原样""完整还原"这类说法，都要追问一句"对什么无损"。

无损压缩对字节无损；无损音频对采样点无损（不保证响度与其他版本一致）；"原样恢复"也要问清范围包不包括权限与链接。

这个词从来不是没有边界的承诺，而是"在某一个确定范围内不会变"——把范围问清楚，很多"明明说无损却不一样"的困惑，就不成立了。

https://www.ijinshan.com/software/7Zip.html?channel=4116