Windows 11 对于 BZip2、Gzip、XZ 和 Zstandard 这些压缩格式的支持情况如下表所示：Windows 系统自带的压缩算法支持情况的简明表格：Windows 自带 tar.exe 解析 macOS PKG 完整底层原理全解析

Windows11 新版资源管理器右键菜单（7‑Zip 新版外壳扩展）解构

这是 Win11 默认精简现代右键面板，走IExplorerCommandCOM 扩展接口。

图中关键条目：全部解压、压缩到… 两个 7‑Zip 注入菜单项；底部「显示更多选项」唤起老式 IContextMenu 完整右键菜单。

一、菜单分层与接口归属

上层可见菜单（截图当前面板）

接口：IExplorerCommand（Win11 现代外壳扩展）
- 7‑Zip 输出两个命令项：全部解压、压缩到…（带子菜单）
- COM 组件：7‑Zip.dll，被 explorer.exe 加载。
- 用户点击 “压缩到…”，DLL 执行CreateProcess拉起独立7zG.exe，传入IShellItemArray选中文件列表，弹出【创建存档】配置对话框。
最底部：显示更多选项（Shift+F10 等效）

接口：老式IContextMenu
- 切换到传统完整右键菜单，加载旧版上下文菜单处理器。
- 这里会出现旧版全套 7‑Zip 菜单项。

两套接口同时注册到系统：

IExplorerCommandProvider → 现代精简菜单（截图所示）

IContextMenu → “显示更多选项” 之后的旧菜单

二、图中 7‑Zip 两个菜单项底层链路对比

菜单项	行为	底层调用
全部解压	直接解压，不弹出配置窗口	DLL 唤起`7zG.exe`，传入解压参数，直接执行解压
压缩到…	展开子菜单：`7zip`、`zip`、其他选项	点击 “其他选项” 才弹出我们前面分析的完整【创建存档】对话框；快速项直接按注册表默认参数生成压缩包

三、注册表对应项

IExplorerCommand 现代菜单 CLSID

plaintext

HKEY_CLASSES_ROOT\CLSID\{23170F69‑40C1‑278A‑1000‑000100020000}

IContextMenu 老式处理器

plaintext

HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\7‑Zip

四、常见故障现象分析

Win11 右键看不到 7‑Zip 菜单项
- 现代菜单消失：CLSID 注册损坏；只重装 7‑Zip 修复 COM 注册。
- “显示更多选项” 里面也没有：IContextMenu处理器注册表丢失。
点击 “压缩到…” 无响应
- 杀毒拦截7zG.exe启动；权限不足；7‑Zip.dllCOM 加载异常。
只有 “显示更多选项” 里面才有 7‑Zip
- 新版 IExplorerCommand 注册失败，只能回退到老式菜单。

五、时序简版

plaintext

explorer.exe
    └─加载7‑Zip.dll(IExplorerCommandProvider)
        └─枚举命令 → 输出“全部解压”“压缩到…”到现代右键面板
用户点击【压缩到…】→ DLL调用CreateProcess启动7zG.exe，传递选中文件对象
7zG.exe弹出创建存档UI，完成参数收集，调用7z.dll完成压缩
explorer不参与后续压缩运算，业务完全隔离在独立进程。

💡补充：

老式 IContextMenu 模式，过去部分旧版压缩软件会直接在 explorer 进程做业务逻辑，一旦崩溃直接资源管理器重启；新版 7‑Zip 无论 IExplorerCommand 还是 IContextMenu，全部业务都交给独立 7zG.exe 进程，实现进程隔离。

ExplorerCommand 与 IContextMenu 外壳扩展对比

背景：

IContextMenu：Win95‑Win10 传统右键菜单接口（老式 Shell 扩展）
IExplorerCommand：Windows 11 引入的现代右键菜单接口，新版 7‑Zip、Notepad++ 都同时实现两套接口，分别适配 Win11 新右键与旧版系统。

Windows11 资源管理器存在两套菜单：

默认精简现代菜单（使用IExplorerCommand）

“显示更多选项” 唤起完整旧菜单（使用老式IContextMenu）

一、基础定位对照表

对比项	IContextMenu（传统）	IExplorerCommand（现代 Win11）
发布年代	Windows 95	Windows 11
宿主进程	加载到`explorer.exe`进程内，DLL 注入资源管理器进程	同样加载到`explorer.exe`，COM DLL 依然在资源管理器地址空间运行
菜单层级	支持无限级嵌套子菜单；可以动态生成大量菜单项	原生支持分组、图标；嵌套子菜单能力受限；适合扁平化菜单
渲染引擎	自绘或者系统标准 MenuItem，老式 GDI 渲染	配合 WinUI / 资源管理器现代 UI 渲染，支持现代图标、分隔线、分组标签
触发方式	`InvokeCommand`，把命令 ID 传给扩展 DLL，DLL 内部自己执行逻辑，也可启动外部程序	`Invoke`方法；更推荐把业务交给外部 EXE 进程执行
DLL 崩溃影响	DLL 内执行业务逻辑，一旦 DLL 崩溃，explorer 直接崩溃重启	最佳实践：DLL 仅负责提供菜单描述，业务全部交给外部 exe，DLL 只传参；就算业务程序崩溃，资源管理器不受影响
适用菜单入口	旧版完整右键菜单（Win11 “显示更多选项”）	Win11 默认弹出的精简现代右键面板
7‑Zip 中实现	兼容旧系统，用于 “显示更多选项” 展开的老式菜单	新版 7‑Zip 主要实现，第一张截图的「压缩到…」子菜单，就是 IExplorerCommand 输出

二、调用逻辑时序拆解

1）IContextMenu 传统链路

plaintext

explorer.exe
    ↓加载Shell扩展DLL(7‑zip.dll)
IContextMenu::QueryContextMenu → 插入菜单项
IContextMenu::InvokeCommand() → 在explorer进程空间内DLL收到命令
    ↓
DLL内部可以：①直接在本进程干活；②CreateProcess拉起外部程序

⚠️风险：

如果 DLL 直接在explorer.exe进程做大量计算、IO、压缩逻辑，内存泄漏 / 崩溃直接造成资源管理器重启。

老版本 7‑Zip 早期版本曾经直接在 explorer 做部分逻辑，经常出现资源管理器卡死。

2）IExplorerCommand 现代链路（7‑Zip 新版采用）

plaintext

explorer.exe
    ↓加载7‑zip.dll COM组件
IExplorerCommandProvider::GetCommands()
    → 返回一组IExplorerCommand对象，提供菜单名称、图标、提示
用户点击菜单项
    ↓
IExplorerCommand::Invoke(IShellItemArray选中文件列表)
    ↓【DLL只做参数转发】
DLL调用 CreateProcess 启动独立 7zG.exe，把选中文件路径作为命令行参数传给GUI程序
explorer释放COM对象，**不再参与后续压缩业务**

✅设计优势：

真正的 UI、压缩运算全部跑在独立7zG.exe进程。即使压缩崩溃、内存暴涨，explorer 完全不受影响。

关键点：接口本身不会隔离进程，是微软推荐开发模式：IExplorerCommand不要在 DLL 中执行业务，只负责唤起外部 EXE。 接口本身仍然被加载 explorer 地址空间，DLL 本身崩溃依旧会炸资源管理器，但是业务逻辑移出去了。

三、关键能力差异

子菜单支持

IContextMenu：自由多级嵌套子菜单，传统软件大量使用。
IExplorerCommand：原生只支持一级子菜单，复杂多层嵌套实现难度很高。7‑Zip 的 “压缩到…> 子菜单”，就是一级子菜单，刚好满足。

选中项传递方式

IContextMenu：InvokeCommand只能传递字符串命令 ID，扩展 DLL 自己去拿选中文件。
IExplorerCommand：Invoke直接接收IShellItemArray对象，原生拿到完整选中文件对象数组，不需要自己解析字符串，更安全可靠，支持虚拟文件夹库。

兼容性

IContextMenu：Win95‑Win11 全平台，Win11 点击「显示更多选项」才会走这套。
IExplorerCommand：仅 Windows11 及以上可用；Windows10 完全不识别该 COM 接口。

所以新版 7‑zip 同时实现两套接口：

Win11 默认现代右键 → IExplorerCommand

Win11 “显示更多选项” / Win10 → IContextMenu

UI 表现

IExplorerCommand 支持现代 UI 特性：暗色模式适配、SVG 图标、菜单分组标题，和系统原生菜单视觉风格统一。
IContextMenu 是老式 GDI 绘制，菜单样式老旧，和 Win11 视觉割裂。

四、7‑Zip 实际行为对照两套接口

操作	使用接口	行为
Win11 普通右键，直接出现「压缩到…」	`IExplorerCommand`	DLL 拉起独立 7zG.exe，弹出创建存档窗口
Win11 右键 → 显示更多选项（旧菜单）	`IContextMenu`	老式菜单，同样拉起 7zG.exe
Windows10 系统右键菜单	仅`IContextMenu`	只有老式菜单逻辑

五、常见坑点

有些旧工具只清理 IContextMenu 的注册表，不会清理 IExplorerCommand 的 COM CLSID 注册项，造成故障排查找不到原因。
就算使用IExplorerCommand，如果开发者在 DLL 内部直接执行业务逻辑，依然会导致 explorer 崩溃；接口只是鼓励把业务放到外部进程，不是强制隔离。
部分老旧杀毒软件会拦截被 explorer 加载的 COM 外壳扩展 DLL，两套接口都会失效，表现右键菜单不出现。

六、开发选型总结

需要兼容 Win10/Win7：必须实现 IContextMenu。
只面向 Win11，想要原生现代菜单视觉体验：实现IExplorerCommand。
商业软件（如 7‑Zip）：两套接口同时实现，做双适配。

新版 7‑Zip Windows11 右键「压缩到…」解构

对应截图：资源管理器右键弹出子菜单 → 点击其他选项唤起创建存档（CreateArchive）模态对话框。

新版 7‑Zip（24+）适配 Win11 现代右键，采用ExplorerCommand COM 外壳扩展，不再是老式 IContextMenu，整个链路分为：资源管理器进程 → Shell 扩展 COM 组件 → GUI 进程 → 压缩引擎 DLL 四层GitHub。

一、核心依赖文件（64‑bit 默认安装路径 `C:\Program Files\7‑Zip\`）

文件	角色	进程宿主	核心职责
`7‑Zip.dll`	Shell 扩展 COM 组件	explorer.exe（资源管理器进程内加载）	实现 Win11 现代右键菜单接口 `IExplorerCommand`；枚举菜单项、传递选中文件列表；点击菜单时启动 7zG.exe 并传递选中文件路径参数。
`7zG.exe`	图形界面 GUI 载体	独立新进程，脱离 explorer	负责渲染【创建存档】对话框（第一张截图窗口），处理 UI 交互（压缩级别滑块、格式下拉、符号链接勾选），收集全部配置参数，调用 7z.dll 完成压缩作业。
`7z.dll`	压缩算法核心引擎	7zG.exe 加载，纯业务逻辑，无 UI	实现 LZMA2/LZMA/BZIP2/ZIP/TAR 算法；读写归档文件；处理符号链接 / 硬链接元数据；导出 C 风格 API，是真正干活的底层库；7z.exe/7zFM.exe/7zG.exe 全部依赖此 DLL。
`7z.exe`	控制台命令行版本	独立进程	无图形界面，等价 7zG 的命令行版本；批处理、脚本调用。
`7zFM.exe`	7‑Zip 主文件管理器	独立进程	完整的归档浏览窗口，不是右键压缩对话框载体。

⚠️关键点：

7‑Zip.dll 被 explorer.exe 加载到资源管理器进程空间；如果此 DLL 崩溃，会直接导致资源管理器重启。

真正的压缩窗口和压缩运算跑在独立 7zG.exe 进程，和 explorer 解耦，压缩崩溃不会卡死文件管理器。

二、注册表注册链路（新版 Win11 现代菜单）

COM 组件 CLSID 注册：{23170F69‑40C1‑278A‑1000‑000100020000}，指向 7‑Zip.dll。
上下文菜单处理器注册：

plaintext

HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\7‑Zip
@="{23170F69‑40C1‑278A‑1000‑000100020000}"

* = 所有文件；Directory = 文件夹；分别注册处理器，资源管理器右键选中文件时加载该 COM 组件。

用户配置保存位置：HKCU\Software\7‑Zip，保存上次压缩级别、默认格式、符号链接勾选状态，对话框打开自动回显上次参数。

三、完整逻辑调用时序（从右键单击 → 压缩完成）

7z.dll(压缩引擎)7zG.exe(GUI对话框进程)7‑Zip.dll(Shell扩展)explorer.exe(资源管理器)7z.dll(压缩引擎)7zG.exe(GUI对话框进程)7‑Zip.dll(Shell扩展)explorer.exe(资源管理器)弹出【创建存档】窗口，读取注册表历史配置，渲染UI控件右键点击文件，IShellItemArray传入选中文件路径列表IExplorerCommand返回菜单列表（Zip文件 /7z文件 /TAR /其他选项）用户点击【其他选项】CreateProcess启动7zG.exe，命令行传入选中的文件路径列表参数用户修改参数：存档格式、压缩方法、压缩级别、勾选保留符号链接(-snl)用户点击【创建】，调用7z.dll导出API，传入全部参数读取源文件，执行LZMA2压缩；处理NTFS符号链接/硬链接元数据；写归档输出返回压缩完成/错误码弹出完成提示框；7zG退出

sequenceDiagram
    participant EXP as explorer.exe(资源管理器)
    participant COM as 7‑Zip.dll(Shell扩展)
    participant GUI as 7zG.exe(GUI对话框进程)
    participant ENG as 7z.dll(压缩引擎)

    EXP->>COM: 右键点击文件，IShellItemArray传入选中文件路径列表
    COM-->>EXP: IExplorerCommand返回菜单列表（Zip文件 /7z文件 /TAR /其他选项）
    EXP->>COM: 用户点击【其他选项】
    COM->>GUI: CreateProcess启动7zG.exe，命令行传入选中的文件路径列表参数
    Note over GUI: 弹出【创建存档】窗口，读取注册表历史配置，渲染UI控件
    GUI->>GUI: 用户修改参数：存档格式、压缩方法、压缩级别、勾选保留符号链接(-snl)
    GUI-->>ENG: 用户点击【创建】，调用7z.dll导出API，传入全部参数
    ENG->>ENG: 读取源文件，执行LZMA2压缩；处理NTFS符号链接/硬链接元数据；写归档输出
    ENG-->>GUI: 返回压缩完成/错误码
    GUI-->>GUI: 弹出完成提示框；7zG退出

快速菜单（直接 “压缩到 7z 文件”）和【其他选项】的区别

快速菜单项（Zip 文件 /7z 文件）：7‑Zip.dll直接调用7zG.exe，不弹出对话框，使用注册表保存的默认参数，直接生成压缩包。
其他选项：唤起完整 CreateArchive 对话框，允许全部参数自定义，也就是截图 1 的窗口。

四、UI 界面字段和底层参数映射（对话框每个控件对应 7z.dll 参数）

界面控件	底层 7z 参数	说明
存档格式下拉	-t{7z/zip/tar}	归档格式开关，`‑t7z`代表 7z 格式
压缩方法 LZM42 (界面简写)	`‑m0=lzma2`	实际是 LZMA2 算法，UI 显示截断；7z.dll 内部压缩算法选择器。
压缩级别滑块较快 ↔ 较小	`‑mx=0~9`	mx1 最快，mx9 最高压缩比；控制字典大小、线程、压缩迭代次数。
✅保留符号链接	`‑snl`	告诉 7z.dll 保存 NTFS 符号链接元数据，不解开链接指向的实际文件；WSL 开发目录备份必备。
保留硬链接	`‑snh`	保存 NTFS 硬链接信息。

等价命令行（对话框全部勾选配置直接转为命令行）

powershell

7zG a -t7z -m0=lzma2 -mx=6 -snl 输出.7z "选中文件路径"

五、关键底层特性与坑点

进程隔离设计

右键扩展 DLL 跑在 explorer；压缩运算跑独立 7zG。即使压缩算法异常、大文件内存暴涨，不会让资源管理器卡死崩溃。老版本部分设计会直接在 explorer 进程做运算，容易资源管理器卡死。
符号链接实现逻辑

勾选「保留符号链接」，7z.dll不读取链接指向的真实磁盘文件，而是把 NTFS 重解析点属性直接写入归档；解压时恢复重解析点。不勾选，则跟随链接读取源文件内容打包进去。WSL 目录、Git 工作目录大量软链接场景必须开启。
Win11 现代菜单兼容代价

新版 7‑Zip 采用IExplorerCommandCOM 接口，不再是老式IContextMenu；部分旧优化工具清理旧 shell 扩展注册表，不识别新版 CLSID，造成右键菜单消失。修复：重装 7‑Zip 修复 COM 注册。
数据流向

plaintext

磁盘源文件 → 7zG读取文件流 → 传入7z.dll压缩器(LZMA2) → 写入输出归档到磁盘

7z.dll 只做内存压缩逻辑，文件 IO 由上层 7zG 控制。

六、故障排查对应模块

右键看不到菜单：7‑Zip.dllCOM 注册损坏，CLSID 注册表丢失；
点击菜单没反应：无法启动7zG.exe，权限不足、杀毒拦截；
压缩大文件闪退：7z.dll内存溢出；调低下压缩级别，降低字典大小；
解压后符号链接失效：打包时没有勾选「保留符号链接」（‑snl参数缺失）。

Windows 自带 tar.exe 解析 macOS PKG 完整底层原理全解析

一、基础背景：Windows tar.exe 的出身

微软从 Windows 10 1709（2018 年 4 月更新） 开始，系统原生内置 tar.exe 命令行工具，它不是 GNU tar，而是基于 libarchive 库的 bsdtar 程序Microsoft ...。 libarchive 是跨平台开源归档解析库，原生支持自动探测 60 + 种归档格式，其中就包含苹果专用的 XAR 归档（macOS PKG 的底层容器），这是它能解压 PKG 的核心前提。而 7-Zip、WinRAR 等传统压缩软件，默认未适配 XAR 格式，因此只能识别 PKG 外层，无法完整解析内部目录结构。

二、macOS .pkg 安装包的本质：XAR 归档

macOS 扁平化安装包（Flat Package，.pkg 后缀），本质就是一个 XAR（eXtensible ARchive）可扩展归档文件，苹果专门用来封装软件安装程序，结构固定：

xxx.pkg（XAR容器）
├─ Bom                # 二进制物料清单，记录所有安装文件的路径、权限、哈希校验值
├─ Payload            # 核心程序负载，gzip压缩的cpio归档，存放最终要安装的软件文件
├─ Scripts           # 安装前后执行的shell脚本（preinstall/postinstall）
├─ PackageInfo       # XML元数据，记录包ID、版本、安装路径、依赖信息
└─ SharedSupport.dmg  # 附加磁盘镜像（你截图里的12.4GB系统镜像资源）

XAR 格式自带 XML 索引 + 二进制数据块，苹果仅在 macOS 系统内置xar命令解析，Windows 下常规工具无法识别。

三、libarchive 解析 XAR 的完整技术链路

格式自动探测 libarchive 读取文件头部特征码，识别出这是 XAR 归档，加载对应的 XAR 解析模块，依赖 libxml2 库解析 XAR 内置的 XML 目录索引，不需要用户手动指定格式。
遍历 XAR 内部文件条目 通过 XAR 的目录索引，依次读取Bom、Payload、Scripts、PackageInfo、SharedSupport.dmg等所有文件，完整还原苹果 PKG 的标准目录结构。
解压 Payload 内层归档 Payload 本身是 cpio+gzip 压缩包，libarchive 同样支持 cpio 格式，可进一步解压出软件原始文件；而SharedSupport.dmg是磁盘镜像，tar.exe 仅负责提取文件，无法直接挂载 dmg。
Windows 原生 tar.exe 直接落地 微软编译的 bsdtar 版本完整集成了 libarchive 的 XAR、cpio、gzip、bzip2、zstd 等全量解码器，无需额外安装依赖，在 CMD/PowerShell 中直接执行解压命令即可完成解析。

四、实操命令（Windows 环境直接运行）

1. 查看 PKG 内部文件列表

tar -tf 安装包.pkg

可以完整列出 Bom、Payload、Scripts、PackageInfo、SharedSupport.dmg 所有文件，和 macOS 下xar -tf效果完全一致。

2. 完整解压 PKG 到指定文件夹

tar -xf 安装包.pkg -OutputDirectory D:\pkg_extract

执行后会生成和苹果 PKG 内部一模一样的目录结构，和你截图里的目录完全对应。

3. 进一步解压 Payload 提取软件本体

Payload 是 cpio.gz 压缩包，继续用 tar 解压：

tar -xf Payload -OutputDirectory D:\payload_files

即可得到 macOS 软件的全部程序文件。

五、关键技术边界与限制

仅支持读取，不支持生成 PKG Windows tar.exe/libarchive 可以解析 XAR，但无法创建符合苹果规范的 pkg 安装包，苹果 XAR 有专属签名、权限、元数据规范，仅 macOS installer 工具可生成。
只能提取文件，不能运行 macOS 程序 解压出的是 macOS 平台的二进制程序、dmg 镜像，Windows 系统无法直接执行，仅用于资源提取、逆向分析、固件 / 镜像抓取。
老旧非扁平化 PKG 不兼容 OS X 10.5 之前的旧版 Bundle 格式 pkg（文件夹形式的 pkg），tar.exe 无法解析，仅支持现代扁平化 XAR 结构的 pkg。
权限与签名信息会丢失 解压后会丢失 macOS 的文件权限、ACL、签名信息，仅保留文件本身数据。

六、和 7-Zip 的核心差异对比

工具	底层依赖	XAR 格式支持	PKG 解析完整性	适用场景
Windows tar.exe	libarchive(bsdtar)	原生完整支持	可完整提取全部目录、Payload、dmg 镜像	Windows 下批量脚本解析、自动化提取 macOS 安装包资源
7-Zip	自研压缩算法	不支持 XAR	只能识别外层容器，无法展开内部标准目录	普通 zip/7z 解压，无法处理苹果 PKG

七、典型应用场景

Windows 环境下提取 macOS 系统安装镜像（SharedSupport.dmg），制作黑苹果安装介质；
逆向分析 macOS 软件安装逻辑，查看安装脚本、Payload 内的程序文件；
批量提取 PKG 内的资源文件，无需切换 macOS 系统；
企业运维脚本自动化解析 macOS 安装包，做资产管理。

7‑Zip 存档格式 & 压缩方法完整解构

两张截图分别是：

存档格式（外层容器）：7zip / ZIP / 多种 tar 变体；
压缩方法（内部压缩算法）：Store、Deflate、BZip2、LZMA1、LZMA2、PPMd。

重要概念区分：

存档格式（Container 容器）：定义归档文件的外壳结构、元数据存储（权限、符号链接、文件名编码）；
压缩方法（Algorithm 算法）：真正做字节压缩的算法；容器和算法可以组合，但存在兼容性约束。

一、存档格式（容器）解读

存档格式	说明	可用压缩算法	典型场景
7zip(.7z)	7‑Zip 原生容器，元数据能力最强，支持符号链接、硬链接、AES 加密、多卷。	Store / Deflate / BZip2 / LZMA1 / LZMA2 / PPMd	本地备份，追求最高压缩率
ZIP(.zip)	通用交换格式，Windows/macOS 原生打开。仅有限支持元数据。	Store、Deflate、BZip2（部分软件不识别 BZip2 ZIP）	对外分发，兼容性优先
tar(GNU)	GNU tar 格式，Linux 传统归档，本身不压缩，只打包文件元数据。	Store（tar 仅打包，压缩需要外层 gzip/bz2）	GNU Linux 系统备份
tar (POSIX pax 交换)	PAX 扩展 tar，支持长文件名、大文件，跨平台兼容性最好。	Store	跨 Windows‑Linux 交换带链接的工程目录，WSL 备份首选
tar (受限 POSIX pax 交换)	裁剪版 pax，兼容老旧 tar 实现。	Store	老旧 Unix 设备
tar(POSIX ustar)	传统 ustar，文件名长度限制，老旧 POSIX 标准。	Store	极老系统兼容

⚠️关键点：tar 只是打包容器，本身不压缩；7‑Zip 中 tar 格式下，压缩方法只能选 Store（无压缩）。想要压缩 tar 包，输出.tar.gz等价于tar+Deflate两步。

二、压缩方法（算法层）逐条拆解

压缩方法	底层原理	特点	命令行参数	适用场景
Store	不压缩，直接原字节拷贝	速度最快，体积不变，仅打包。	`‑m0=Store`	仅打包、快速归档、tar 容器必选
Deflate	LZ77+Huffman，ZIP 标准算法	平衡速度压缩，兼容性最强。	`‑m0=Deflate`	zip 通用包，跨平台交换
BZip2	Burrows‑Wheeler 变换	压缩优于 Deflate，CPU 消耗更高；多核支持差。	`‑m0=BZip2`	文本类数据，现在逐步被 LZMA2 替代
LZMA1	LZ77 + 区间编码，7z 初代算法	高压缩，单线程，字典最大 1GB。	`‑m0=lzma`	老版 7z 归档，现已被 LZMA2 替代
LZMA2	LZMA1 改良，支持多线程，容错更好	7z 默认算法；多核并行，压缩率优秀。	`‑m0=lzma2`	绝大多数场景首选
PPMd	预测部分匹配，面向文本优化	纯文本代码、文档压缩率极高；二进制文件效果差。	`‑m0=ppmd`	源代码、文档、纯文本集合，不适合图片 / EXE

压缩级别 `-mx=N`

mx0 Store；mx1最快；mx6默认平衡；mx9极限压缩，大字典，占用大量内存。

三、容器与算法的合法组合（7‑Zip 约束）

7z 容器：全部 6 种算法都支持。
- 日常默认：7z + LZMA2
- 源码文档集合：7z + PPMd
ZIP 容器：Store / Deflate / BZip2；不支持 LZMA2（普通解压软件打不开 LZMA‑ZIP）。

很多人踩坑：把 zip 格式选 LZMA2，Windows 自带解压直接报错。

tar 全部变体：只能 Store（无压缩）。

常见错误组合

❌ 存档格式 ZIP，压缩方法 LZMA2：生成的 zip Windows 资源管理器无法解压。
❌ 存档格式 tar，压缩方法 LZMA2：7‑Zip 界面会自动置回 Store，tar 本身不承载压缩。

四、符号链接、硬链接选项与容器的关系

✅保留符号链接 (-snl)：只有 7z / pax‑tar 容器可以完整保存 NTFS 重解析点、POSIX 软链接元数据。
ZIP、ustar tar：不完整支持符号链接元数据，勾选也无法正确保存。

WSL / 开发目录备份最佳配置：

存档格式：7zip；压缩方法：LZMA2；勾选「保留符号链接」。

五、对应命令行示例

powershell

# 标准7z备份，保留符号链接
7z a -t7z -m0=lzma2 -mx=6 -snl output.7z ./source

# zip通用分发（只用Deflate）
7z a -tzip -m0=deflate -mx=6 output.zip ./source

# tar‑pax打包，无压缩，用于WSL迁移
7z a -ttar -mpax -snl output.tar ./source

# 源代码文本，PPMd最大化压缩
7z a -t7z -m0=ppmd -mx=9 code.7z ./src

六、选型速查建议

使用场景	存档格式	压缩算法	附加选项
对外发给普通用户	ZIP	Deflate	不保存链接
本地备份，兼顾体积速度	7z	LZMA2	需要开发目录则勾选保留符号链接
源代码、大量 txt 文档	7z	PPMd	保留符号链接
迁移 WSL、Linux 目录到 Linux	tar (pax 交换)	Store	✅保留符号链接

7-Zip「创建存档」tar 系列选项完整解构

对应截图界面：7-Zip 图形界面「存档格式」下拉：tar(GNU) / tar(POSIX pax交换) / tar(受限POSIX pax交换) / tar(POSIX ustar) 前置核心认知：tar 本身只是「打包器（归档），不是压缩器」；它只把多个文件 + 元数据拼接成连续流，压缩需要外层叠加 gzip/bz2/xz 等（截图源文件后缀是.bz2，属于压缩层）

一、底层原理

1. tar 通用基础结构（所有子格式共用骨架）

tar 由512 字节固定 Header 块 + 文件数据块（补齐 512 字节对齐） 循环组成，末尾 2 个全 0 512 块作为结束标记：

[512B 文件元数据头] → [文件二进制数据，填充至512整数倍] → [下一个文件Header] … → [结束空块×2]

Header 内置：文件名、权限 mode、uid/gid、文件大小、mtime、校验和、文件类型（普通文件 / 软链接 / 硬链接）等元信息。不同 tar 子格式差异只在于 Header 字段编码、扩展元数据支持能力，基础块结构完全兼容。

2. 4 种 tar 子格式底层差异

选项	底层规范	核心原理
tar (GNU)	GNU tar 扩展格式	在老式 v7 tar 基础上加入 GNU 私有扩展头，支持 > 8GB 大文件、长文件名、稀疏文件；Linux 原生 tar 默认格式，非 POSIX 标准
tar (POSIX pax 交换)	IEEE Std 1003.1-2001 PAX	ustar 兼容基底 + 可扩展 x/g 全局扩展头；扩展头用文本 K/V 存储超长路径、纳秒时间、ACL、UTF8 文件名；老 tar 程序会自动忽略扩展头，只读取基础 ustar 内容
tar (受限 POSIX pax 交换)	PAX 精简子集	仅启用最基础的扩展（解决 ustar 8GB / 长文件名限制），禁用非标准扩展属性（ACL、自定义元数据），极致兼容老旧设备
tar (POSIX ustar)	POSIX.1-1988 ustar	最早标准化 tar 头；字段长度硬编码，文件名上限 100B、路径前缀 155B、单文件最大 8GB，无扩展能力

3. 7-Zip 内部实现原理

7-Zip自研 tar 编码器，不依赖 libarchive/GNU tar 二进制，内置在7z.dll核心模块中：

文件遍历：读取本地文件 / NTFS 元数据，识别硬链接、符号链接（重解析点）
元数据适配：根据选中的 tar 格式，生成对应 Header、按需插入 pax 扩展头
块对齐写入：按 512B 块输出归档流
可选压缩层：如果外层勾选压缩方法（gzip/bz2 等），tar 裸流会送入对应的压缩编码器

二、依赖文件 & 依赖关系

✅ 核心依赖文件（7-Zip 本体）

7z.dll：核心归档 / 编码实现，tar、7z、zip 等全部格式的编解码逻辑都在此，GUI 和命令行7z.exe都调用此 dll
7zFM.exe：7-Zip 文件管理器 GUI（你截图的界面程序），只负责 UI 交互，不直接处理归档二进制
7z.exe：命令行版本，复用7z.dll同一套 tar 编码逻辑

✅ 系统依赖

Windows API：CreateFileW/GetFileAttributesExW/FindFirstFileW：读取文件、时间戳、NTFS 硬链接 / 符号链接信息
NTFS 文件系统：硬链接、符号链接、备用数据流 (ADS) 仅 NTFS 支持；FAT32/exFAT 无法读取 / 存储这类元数据
字符编码：Windows Unicode（UTF-16）→ 转成 tar 存储用的 UTF-8（pax/GNU 支持，ustar 仅 ASCII）

❌ 不依赖

不依赖系统自带tar.exe、不依赖 libarchive、不依赖 WSL、不需要 GNU 工具链。

和前面聊的 Windows 自带 tar.exe（bsdtar+libarchive）两套完全独立实现

三、完整逻辑链路（从你截图的操作出发）

用户在7-Zip GUI选择文件 → 选择存档格式【tar系列】→ 勾选【保留符号链接/硬链接】→ 点击创建
        ↓
7zFM.exe（GUI） → 调用7z.dll的Tar编码器模块
        ↓
①遍历源文件：读取文件内容、mtime、权限、NTFS链接标记
②按选定tar格式生成Header：
    · ustar：直接写固定512B头，超长路径直接截断
    · pax：自动生成x类型扩展头存放超长路径/高精度时间
    · GNU：写入GNU私有扩展
③写入文件数据块，512字节对齐
④末尾写入2块全0结束标记
        ↓
【可选】叠加bz2/gzip压缩（当前源文件后缀是.bz2，就是tar流送入bzip2编码器）
        ↓
输出最终 .tar / .tar.bz2 文件

勾选「保留符号链接 / 硬链接」的分支逻辑：

硬链接：记录nlink计数 + inode，后续解压只存 1 份实体数据，其余条目只写链接元

符号链接：不读取目标文件内容，Header 标记文件类型l，存储目标路径字符串 ⚠️ ustar 格式对 Windows NTFS 符号链接支持缺陷很大，pax/GNU 才能完整保留

四、配套链

1. 生态配套（跨平台兼容）

生成格式	可正常解压工具	典型配套场景
tar(GNU)	GNU tar、7-Zip、libarchive(Windows tar.exe)	传统 Linux 服务器、老运维脚本
tar (POSIX pax 交换)	所有现代 tar（bsdtar/GNU tar/Windows tar.exe）、7-Zip	✅【推荐】跨 Windows↔Linux、WSL 备份、工程交付
tar (受限 pax)	极老旧嵌入式 tar（路由器、IoT 设备）	低版本嵌入式系统交付
tar(ustar)	上古 UNIX、极老嵌入式	遗留老旧设备兼容（现在极少用）

2. 上下游配套工具

上游：7z.exe命令行批量打包（可复刻 GUI 的 tar 参数）
下游：Windows 自带tar.exe（libarchive）、GNU tar、bsdtar、Python tarfile、Python libarchive、嵌入式 busybox tar
压缩配套：gzip/bzip2/xz/zstd（tar 本身无压缩，组合成 tar.gz tar.bz2 txz）

五、边界（硬性限制、坑点）

1. ustar 硬边界（最容易踩坑）

文件名本体最大 100 字节，路径前缀最多 155 字节，总路径≤255B，超长直接截断丢数据
文件大小上限 8GB，超过直接损坏归档
不支持 UTF-8 文件名、纳秒级时间戳、ACL/NTFS 权限
对 Windows 符号链接支持差

2. GNU tar 边界

私有扩展，非 POSIX 标准；部分极简嵌入式 tar（busybox 旧版本）无法识别扩展头，会解析异常
稀疏文件仅 GNU tar 可完整还原，pax/ustar 不支持稀疏标记

3. PAX 边界

基础头依然是 ustar，老旧 tar 会忽略扩展头，只能拿到截断文件名、8GB 内文件
「受限 pax」主动砍掉 ACL、自定义元数据，仅解决长文件名 / 大文件
Windows 下 NTFS 特殊元数据（ADS 备用数据流）pax 标准本身不定义，7-Zip 无法存入 tar（只能 7z 容器保存 ADS）

4. Windows 平台通用边界

tar 是UNIX 原生格式，Windows 没有 uid/gid 权限体系；打包时 7-Zip 会填充虚拟 uid/gid，解压到 Linux 才生效，Windows 解压会直接忽略 uid/gid
硬链接 / 符号链接：仅 NTFS 文件系统可正常识别打包；FAT32/exFAT 无法读取链接信息，会直接打包成独立实体文件
不支持加密：tar 系列容器本身无加密字段，如果需要加密，只能外层再套 7z

5. 和 Windows 自带 tar.exe（libarchive）的核心边界区分

7-Zip tar 编码器：自研，图形界面可控 4 种子格式，适合人工打包交付；但之前我们测试它无法识别 XAR/PKG
Windows 自带 tar.exe（bsdtar+libarchive）：自动探测 XAR/cpio 等格式，能解析 macOS pkg；但没有图形界面，无法精细选择 ustar/pax/GNU 子格式

六、选型建议（直接落地）

跨 Windows ↔ Linux 通用交付、WSL 备份 → tar (POSIX pax 交换)（首选）
对接老旧 Linux 服务器，传统脚本兼容 → tar (GNU)
老旧嵌入式 IoT 设备（busybox 老 tar） → tar (受限 POSIX pax)
上古遗留设备，严格 POSIX.1988 → tar (POSIX ustar)（尽量避免）

BZip2、Gzip、XZ 和 Zstandard（Zstd）是四种常见的压缩算法，它们在不同的应用场景中有各自的优势。下面是它们的详细说明：

1. BZip2 (Block-sorting compression algorithm)

格式扩展名：.bz2
压缩算法原理： BZip2 使用 Burrows-Wheeler Transform (BWT) 和 Move-to-Front (MTF) 变换，再配合 Huffman 编码 来实现数据压缩。BZip2 是块排序压缩算法，压缩效率高，但解压速度相对较慢。
特点：
- 高压缩比：相比于其他压缩格式（如 Gzip），BZip2 通常能提供更高的压缩比。
- 压缩速度慢，解压速度稍快：压缩过程比 Gzip 慢，但解压速度比压缩过程快。
- 文件扩展名：.bz2，常用于压缩单个文件。
应用： BZip2 常用于 Linux 系统中，例如 .tar.bz2 格式，通常将多个文件打包为 .tar 文件后再用 BZip2 压缩。
支持：
- Windows 需要使用第三方工具（如 7-Zip）来解压 .bz2 格式文件。

2. Gzip (GNU zip)

格式扩展名：.gz
压缩算法原理： Gzip 使用 DEFLATE 算法，它结合了 LZ77 和 Huffman 编码。DEFLATE 算法是一种无损数据压缩算法，它使用字典编码和变长编码来达到高效的压缩效果。
特点：
- 速度较快：相对于 BZip2 和 XZ，Gzip 的压缩和解压速度较快，但压缩比通常不如 BZip2 或 XZ 高。
- 广泛使用：Gzip 是 Unix/Linux 系统中最常用的压缩格式之一，也广泛用于 Web 服务（例如 HTTP 压缩传输）。
- 文件扩展名：.gz，通常用于压缩单个文件或作为 .tar.gz 格式使用。
应用： Gzip 被广泛应用于 Web 服务器的压缩传输（例如，Apache 和 Nginx 支持 Gzip），以及 Linux 系统中的文件压缩。常见的 .tar.gz 或 .tgz 格式用于将多个文件打包和压缩。
支持：
- Windows 需要使用第三方工具（如 7-Zip 或 Gzip for Windows）来解压 .gz 文件，或者通过 WSL 使用 Linux 命令行工具。

3. XZ (LZMA2 compression)

格式扩展名：.xz
压缩算法原理： XZ 使用 LZMA2（Lempel-Ziv-Markov chain algorithm）算法。LZMA2 是一种字典压缩算法，它通过更大的字典和更复杂的算法来提高压缩比。Xz 相对于其他格式（如 Gzip）提供了更高的压缩比，但也需要更多的计算资源。
特点：
- 极高的压缩比：Xz 提供比 Gzip 和 BZip2 更高的压缩比，适合用于大文件或大数据集的压缩。
- 压缩速度较慢，解压速度较快：压缩过程非常耗时，但解压速度相对较快。
- 文件扩展名：.xz，通常用于单个文件的压缩。也可以与 .tar 配合使用（.tar.xz）来打包和压缩多个文件。
应用： XZ 格式被广泛用于 Linux 系统中的软件包管理，例如 .tar.xz 格式常用于压缩源代码包和安装包。
支持：
- 在 Windows 中，用户需要通过 7-Zip 或 XZ Utils 工具来解压 .xz 文件。
- 使用 WSL（Windows Subsystem for Linux）也是一个可行的解决方案。

4. Zstandard (Zstd)

格式扩展名：.zst
压缩算法原理： Zstandard 是由 Facebook 开发的一种新的压缩算法，旨在提供更快的压缩和解压速度，同时保持良好的压缩比。它采用了 fast compression algorithms 和 Huffman 编码，并且具有多级压缩层级，可以根据需要调整压缩比与速度之间的平衡。
特点：
- 非常高的压缩速度：Zstd 在压缩和解压速度上比其他格式更快，尤其适用于需要快速处理数据的场景。
- 良好的压缩比：虽然 Zstd 的压缩比通常比 Gzip 差，但在与 BZip2 和 XZ 相比时，它提供了更好的速度和压缩比平衡。
- 灵活性：Zstd 提供了多个压缩等级，允许用户在压缩比和速度之间做出平衡。
- 文件扩展名：.zst，常用于大数据处理和传输的压缩文件格式。
应用： Zstandard 被设计为一种高效的通用压缩算法，特别适用于需要快速压缩和解压的场景，如大数据处理、文件系统压缩（例如 Facebook 的 fcompress）等。
支持：
- Windows 用户需要使用第三方工具（如 Zstandard 官方工具 或 7-Zip）来解压 .zst 文件。
- 同样可以通过 WSL 使用 Linux 环境下的 zstd 命令来解压 Zstandard 格式文件。

压缩算法	优势	劣势	使用场景
BZip2	高压缩比，适用于压缩单个文件	压缩速度较慢，解压速度一般	适用于需要高压缩比的文件（如 `.tar.bz2`）
Gzip	压缩速度快，解压速度也快，广泛支持	压缩比不如 BZip2 或 XZ 高	网络传输、Web 服务、Linux 系统压缩（如 `.tar.gz`）
XZ	极高的压缩比，适合大文件压缩	压缩速度较慢，资源消耗大	适用于需要高压缩比的场景（如 `.tar.xz`）
Zstandard	高压缩速度，良好的压缩比，灵活的压缩级别	对 CPU 使用较高（高压缩等级时）	高效的数据压缩和解压（如 `.zst` 格式）

这些压缩格式在不同的应用场景中各有优势，选择哪种压缩格式通常取决于需要优化的方面（压缩比、压缩速度或解压速度）以及具体的使用需求。

在 Windows 11 中，符号链接（Symbolic Link, symlink）和硬链接（Hard Link）是两种重要的文件系统链接技术，它们允许文件和文件夹之间建立引用关系，提供了灵活的文件管理和操作方式。虽然这两者都用于将一个文件或文件夹引用到另一个位置，但它们在实现方式和应用场景上有所不同。下面是它们的详细说明：

1. 符号链接（Symbolic Link, symlink）

定义

符号链接（又叫软链接）是指向文件或目录的引用，类似于快捷方式。在文件系统中，符号链接本质上是一个特殊的文件，其内容包含另一个文件或目录的路径。符号链接可以跨分区和跨驱动器工作，因为它是基于路径的引用。

特点

指向路径：符号链接包含一个指向目标文件或目录的路径。当打开符号链接时，操作系统会自动将它解析为目标文件的路径。
跨分区支持：符号链接可以指向不同分区、不同磁盘上的文件或文件夹。
可以指向目录：符号链接不仅可以指向文件，也可以指向文件夹。
删除链接不影响目标文件：删除符号链接不会影响目标文件本身。
易损坏：如果目标文件或目录被删除或移动，符号链接就会变成“死链接”，无法再访问目标。

使用场景

快捷方式：通常用来创建文件或目录的快捷方式，尤其是跨分区或网络共享时。
开发和测试：程序开发中，常用符号链接来指向某些配置文件或资源，方便调试和测试。
备份和迁移：可以使用符号链接将某些文件指向新的位置，而不需要更改程序代码。

创建符号链接

在 Windows 11 中，可以通过以下命令在 命令提示符（或 PowerShell）中创建符号链接：

创建文件符号链接：

bashCopy Code
```
mklink link_path target_path
```
- link_path：符号链接文件的路径。
- target_path：目标文件或目录的路径。
例如，要在 C:\ 创建一个指向 D:\Documents\myfile.txt 的符号链接，可以使用：

bashCopy Code
```
mklink C:\myfile.txt D:\Documents\myfile.txt
```
创建目录符号链接（/D 参数）：

bashCopy Code
```
mklink /D link_path target_path
```
例如，创建指向 D:\Documents 目录的符号链接：

bashCopy Code
```
mklink /D C:\Documents D:\Documents
```

注意事项

权限要求：在 Windows 10/11 中，创建符号链接通常需要管理员权限，或者需要启用开发者模式。
符号链接与快捷方式的区别：快捷方式是 Windows 图形用户界面中的特殊文件，而符号链接是文件系统级别的对象，操作系统直接支持。快捷方式依赖于用户的界面交互，而符号链接是透明的，应用程序和操作系统能够识别并处理它。

2. 硬链接（Hard Link）

定义

硬链接是一个指向同一文件内容（数据块）的目录项。在 NTFS 文件系统中，文件实际上是由其文件名和文件数据两部分组成的。硬链接允许多个文件名指向相同的文件数据块。硬链接并不指向路径，而是直接指向文件的数据区域。

特点

指向文件内容：硬链接并不像符号链接那样指向路径，而是指向文件的物理数据块。多个硬链接实际上是同一个文件的不同名称。
跨分区不支持：硬链接不能跨分区或不同磁盘创建，它们只能在同一个文件系统（同一分区）内有效。
无法指向目录：除非是管理员权限，否则硬链接不能用于目录（在 Linux 中可以创建目录硬链接，但 Windows 中不允许）。
不易损坏：由于硬链接指向的是文件的实际内容，因此文件的删除不会影响其他硬链接。只有所有指向文件的硬链接都被删除时，文件的实际数据才会从磁盘中删除。
无法区分链接：不同的硬链接在文件系统中是等同的，操作系统无法区分它们。它们共享相同的文件内容和文件属性（如时间戳、大小）。

使用场景

备份和副本：硬链接非常适用于创建文件副本，而不会浪费额外的磁盘空间，因为它们指向相同的数据区域。
文件版本管理：多个硬链接可以用来管理文件的不同版本，所有版本指向相同的底层数据。

创建硬链接

在 Windows 11 中，硬链接可以使用 mklink 命令与 /H 参数来创建：

创建硬链接：
bashCopy Code
```
mklink /H link_path target_path
```
例如，创建一个硬链接 C:\myfile.txt 指向 D:\Documents\myfile.txt：
bashCopy Code
```
mklink /H C:\myfile.txt D:\Documents\myfile.txt
```

注意事项

必须在同一分区内：硬链接无法跨分区或跨磁盘使用。
无法为目录创建硬链接：在 Windows 中，硬链接只能用于文件，而不能用于目录（除了特殊的系统目录）。
数据共享：如果你删除了其中一个硬链接，文件的数据不会丢失，其他硬链接仍然可以访问这些数据。

符号链接 vs 硬链接

特性	符号链接（Symbolic Link）	硬链接（Hard Link）
指向	指向文件或目录的路径	直接指向文件数据块
跨分区支持	支持跨分区（可以指向不同驱动器）	不支持跨分区（只能在同一分区内）
指向对象	可以指向文件和目录	只能指向文件，不能指向目录
删除链接	删除符号链接不会删除目标文件或目录	删除任何硬链接都不会删除文件数据，直到最后一个硬链接被删除
易损坏性	如果目标文件或目录被删除，符号链接变为死链接	无法“损坏”，只要至少有一个硬链接存在，数据仍然有效
创建方法	`mklink`（符号链接）	`mklink /H`（硬链接）

符号链接（symlink） 适用于需要指向不同位置（包括跨分区）的文件或目录，灵活性高，但需要管理目标路径的存在性。
硬链接（hard link） 则适用于在同一分区内创建多个文件名引用相同数据的场景，所有硬链接指向相同的底层文件数据，删除硬链接不会影响数据本身，直到最后一个硬链接删除。

选择哪种链接类型，取决于你的具体需求：是否需要跨分区、是否需要指向目录、是否关心链接是否会“损坏”等因素。

Windows 系统自带的压缩算法 支持情况的简明：

压缩格式	支持情况	说明
ZIP	支持（内置功能）	Windows Explorer、PowerShell 支持，常见压缩格式，广泛使用
CAB	支持（内置功能）	Windows 安装文件常用格式，支持通过命令行工具如 `expand` 解压
LZ	支持（通过 CAB 文件）	LZ 压缩算法用于 CAB 格式中的数据压缩
MSI	支持（内置功能）	Microsoft Installer 使用的压缩格式，支持解压和安装应用程序
TAR	支持（Windows 10/11 的 WSL 或使用 PowerShell）	原本是 Unix/Linux 常用的格式，Windows 通过 Windows Subsystem for Linux (WSL) 或 PowerShell 支持
GZ	支持（通过 WSL 或工具）	GZIP 格式，通常用于 Unix/Linux 系统，Windows 需要额外工具或 WSL 支持
XZ	支持（通过工具或 WSL）	高压缩比的压缩格式，需要额外工具或 WSL 支持
7z	不原生支持，但可通过 7-Zip 等第三方软件支持	高压缩比压缩格式，Windows 需安装第三方软件（如 7-Zip）来支持
RAR	不原生支持，但可通过 WinRAR 等第三方软件支持	高压缩比，常见于文件分发，需安装第三方软件（如 WinRAR）

说明：

ZIP 格式：Windows 原生支持 ZIP 格式压缩和解压。用户可以直接使用 Windows 资源管理器（右键菜单）来创建、提取 ZIP 文件。
CAB 格式：常用于 Windows 安装程序，系统提供了 expand 命令行工具用于解压 CAB 文件。
MSI 格式：是 Windows 安装程序的标准格式，Windows 提供了专门的安装和解压工具，使用 .msi 扩展名。
TAR、GZ、XZ：这些格式通常用于 Unix 和 Linux 系统，Windows 10 和 Windows 11 提供了 Windows Subsystem for Linux (WSL) 来支持这些格式的压缩和解压。也可以通过安装第三方工具（如 7-Zip）来支持这些格式。
RAR 和 7z 格式：这些格式不是 Windows 原生支持的，但可以通过第三方工具（如 7-Zip、WinRAR）来实现。

Windows 系统原生支持的压缩格式主要包括 ZIP 和 CAB 格式，对于其他压缩格式，如 RAR、7z、TAR 和 GZ，用户需要安装额外的第三方工具或者启用 WSL 来进行处理。

posted @ 2024-11-09 21:34 suv789 阅读(2621) 评论(0) 收藏举报

刷新页面返回顶部

suv789

Windows 11 对于 BZip2、Gzip、XZ 和 Zstandard 这些压缩格式的支持情况如下表所示：Windows 系统自带的压缩算法 支持情况的简明表格：Windows 自带 tar.exe 解析 macOS PKG 完整底层原理全解析

Windows11 新版资源管理器右键菜单（7‑Zip 新版外壳扩展）解构

一、菜单分层与接口归属

二、图中 7‑Zip 两个菜单项底层链路对比

三、注册表对应项

四、常见故障现象分析

五、时序简版

ExplorerCommand 与 IContextMenu 外壳扩展对比

一、基础定位对照表

二、调用逻辑时序拆解

1）IContextMenu 传统链路

2）IExplorerCommand 现代链路（7‑Zip 新版采用）

三、关键能力差异

四、7‑Zip 实际行为对照两套接口

五、常见坑点

六、开发选型总结

新版 7‑Zip Windows11 右键「压缩到…」解构

一、核心依赖文件（64‑bit 默认安装路径 C:\Program Files\7‑Zip\）

二、注册表注册链路（新版 Win11 现代菜单）

三、完整逻辑调用时序（从右键单击 → 压缩完成）

快速菜单（直接 “压缩到 7z 文件”）和【其他选项】的区别

四、UI 界面字段和底层参数映射（对话框每个控件对应 7z.dll 参数）

五、关键底层特性与坑点

六、故障排查对应模块

Windows 自带 tar.exe 解析 macOS PKG 完整底层原理全解析

一、基础背景：Windows tar.exe 的出身

二、macOS .pkg 安装包的本质：XAR 归档

三、libarchive 解析 XAR 的完整技术链路

四、实操命令（Windows 环境直接运行）

1. 查看 PKG 内部文件列表

2. 完整解压 PKG 到指定文件夹

3. 进一步解压 Payload 提取软件本体

五、关键技术边界与限制

六、和 7-Zip 的核心差异对比

七、典型应用场景

7‑Zip 存档格式 & 压缩方法完整解构

一、存档格式（容器）解读

二、压缩方法（算法层）逐条拆解

压缩级别 -mx=N

三、容器与算法的合法组合（7‑Zip 约束）

常见错误组合

四、符号链接、硬链接选项与容器的关系

五、对应命令行示例

六、选型速查建议

7-Zip「创建存档」tar 系列选项完整解构

一、底层原理

1. tar 通用基础结构（所有子格式共用骨架）

2. 4 种 tar 子格式底层差异

3. 7-Zip 内部实现原理

二、依赖文件 & 依赖关系

✅ 核心依赖文件（7-Zip 本体）

✅ 系统依赖

❌ 不依赖

三、完整逻辑链路（从你截图的操作出发）

四、配套链

1. 生态配套（跨平台兼容）

2. 上下游配套工具

五、边界（硬性限制、坑点）

1. ustar 硬边界（最容易踩坑）

2. GNU tar 边界

3. PAX 边界

4. Windows 平台通用边界

5. 和 Windows 自带 tar.exe（libarchive）的核心边界区分

六、选型建议（直接落地）

1. BZip2 (Block-sorting compression algorithm)

2. Gzip (GNU zip)

3. XZ (LZMA2 compression)

4. Zstandard (Zstd)

1. 符号链接（Symbolic Link, symlink）

定义

特点

使用场景

创建符号链接

注意事项

2. 硬链接（Hard Link）

定义

特点

使用场景

创建硬链接

Windows 11 对于 BZip2、Gzip、XZ 和 Zstandard 这些压缩格式的支持情况如下表所示：Windows 系统自带的压缩算法支持情况的简明表格：Windows 自带 tar.exe 解析 macOS PKG 完整底层原理全解析

一、核心依赖文件（64‑bit 默认安装路径 `C:\Program Files\7‑Zip\`）

压缩级别 `-mx=N`