Go archive/zip FileHeader.CreatorVersion 怎样判断 ZIP 条目来源平台

先给结论：archive/zip.FileHeader.CreatorVersion 不是一个可以直接整体打印后就下结论的版本号。它的高字节用于表达创建 ZIP 条目时采用的平台约定，低字节才是版本部分；Go 的 FileHeader.Mode() 也会根据高字节选择 Unix、FAT、NTFS、VFAT 或 macOS X 的属性解释方式。

读取 ZIP 元数据时，先拆出平台和版本，再决定是否解释 ExternalAttrs。遇到未知平台要保留原始数值，不能把一个看似熟悉的编号直接当成 Windows、Linux 或某个压缩软件。

官方地址：https://pkg.go.dev/archive/zip@go1.27.3

症状：CreatorVersion 看着像数字，实际同时编码平台与版本

ZIP 中央目录的“版本创建者”字段被 Go 映射为 uint16。如果只写 fmt.Println(f.CreatorVersion)，得到的是平台字节和版本字节拼接后的整数，无法直接回答“这个条目来自什么平台”。更麻烦的是，ExternalAttrs 的含义依赖 CreatorVersion：同一个属性位，在 Unix 与 DOS 风格的解释方式下并不相同。

因此，排查“ZIP 条目权限显示不对”或“来源平台识别错误”时，第一步不是猜压缩软件，而是把这个字段拆开。Go 1.27.3 源码中明确按 CreatorVersion >> 8 选择属性解码分支。

根因：高字节识别来源平台，低字节保留版本信息

可以把 CreatorVersion 看成两个八位字段：uint8(v >> 8) 是平台标识，uint8(v & 0xff) 是版本部分。Go 源码维护了几组常见平台约定：0 表示 FAT，3 表示 Unix，11 表示 NTFS，14 表示 VFAT，19 表示 macOS X。它们是 ZIP 生态中的约定值，不等于“当前运行 Go 程序的操作系统”。

package main

import "fmt"

// platformName 只解释 Go archive/zip 采用的常见平台约定。
func platformName(creatorVersion uint16) string {
	// 高字节是平台部分，低字节不能参与平台判断。
	switch creatorVersion >> 8 {
	case 0:
		return "FAT"
	case 3:
		return "Unix"
	case 11:
		return "NTFS"
	case 14:
		return "VFAT"
	case 19:
		return "macOS X"
	default:
		// 未知值保留数值，避免把第三方约定误报成已知平台。
		return fmt.Sprintf("未知平台(%d)", creatorVersion>>8)
	}
}

// creatorVersionNumber 提取版本部分，便于日志和诊断记录。
func creatorVersionNumber(creatorVersion uint16) uint8 {
	// 低八位是版本部分，不把它和平台编号混在一起。
	return uint8(creatorVersion & 0xff)
}

这里的重点是拆解顺序：先用高字节选择平台，再把低字节作为版本信息记录。如果只比较整个整数，两个不同平台的相同版本可能被误认为“版本不同”；如果只看低字节，又会丢掉 ExternalAttrs 所需要的平台语境。

修复：读取条目时同时输出平台、版本与属性边界

读取 ZIP 时，zip.File 内嵌了 FileHeader，可以直接访问 CreatorVersion、ExternalAttrs 和 Mode()。下面的示例把三者并排记录，便于定位“原始属性”和“Go 解释后的权限”是否来自同一平台分支。

package main

import (
	"archive/zip"
	"fmt"
	"log"
)

func main() {
	r, err := zip.OpenReader("archive.zip")
	if err != nil {
		log.Fatal(err)
	}
	defer r.Close() // 读取器持有文件资源，函数结束前必须关闭。

	for _, f := range r.File {
		creator := f.CreatorVersion
		// 先拆平台和版本，再读取依赖平台语义的权限信息。
		platform := platformName(creator)
		version := creatorVersionNumber(creator)
		fmt.Printf("name=%s platform=%s version=%d creator=0x%04x attrs=0x%08x mode=%s\n",
			f.Name, platform, version, creator, f.ExternalAttrs, f.Mode())
	}
}

Mode() 的结果适合做文件类型和权限的统一观察，但不要把它当成跨平台权限的完整还原证明。Go 源码在 Unix/macOS X 分支读取 ExternalAttrs >> 16，在 FAT、NTFS、VFAT 分支读取 DOS 风格属性；未知平台则不会自动补猜。

防复发：不要手工伪造来源平台，也不要把平台判断当成安全结论

如果是写 ZIP，优先让 FileInfoHeader 和 SetMode 根据文件信息填充相关字段。Go 的 SetMode 会把平台部分设置为 Unix，并同时写入 Unix 属性和兼容性的 DOS 属性。手工改写 CreatorVersion 后再保留旧的 ExternalAttrs，很容易制造“平台和属性不匹配”的条目。

• 日志同时记录十六进制原值、高字节平台和低字节版本，方便和第三方 ZIP 工具对照。
• 只在平台值已知时解释 ExternalAttrs；未知值保留原始属性，不强行转换。
• 平台来源只说明元数据约定，不能证明文件可信、没有恶意内容或一定来自某台设备。
• 如果业务必须跨工具兼容，保存原始 ZIP 与解析后的结构化记录，不要只保存一个平台名称。

相关问题

CreatorVersion 的低字节可以单独当成压缩格式版本吗？不可以。它是“创建者版本”字段中的版本部分，不是 FileHeader.Method 的压缩方法编号；压缩方法应单独读取 Method。

为什么同一个 ZIP 条目的 ExternalAttrs 在不同工具里显示不同？因为属性解释依赖创建平台约定，且不同工具可能写入不同的扩展属性组合。先查看 CreatorVersion 的高字节，再比较工具对该平台的解释。

未知平台值应该怎么处理？保留原始 CreatorVersion 和 ExternalAttrs，在日志中标记未知平台；不要为了显示友好而映射到最近似的已知值。

官方资料：https://pkg.go.dev/archive/zip@go1.27.3、https://raw.githubusercontent.com/golang/go/go1.27.3/src/archive/zip/struct.go。本文图示为 ImageGen 生成的静态说明图，代码用于解释字段关系，未把示例输出冒充为运行证据。