Go archive/zip 怎样从 ZIP 文件名编码判断 UTF-8 标志

Go 中判断 ZIP 是否声明文件名使用 UTF-8，应读取成员的 FileHeader.Flags 第 11 位：f.Flags&(1，掩码是 0x0800。若要判断名称字节本身是否合法 UTF-8，再单独调用 utf8.ValidString(f.Name)。二者回答不同问题，不能仅凭中文显示正常或 !f.NonUTF8 就推断原始标志一定置位。

官方文档：https://pkg.go.dev/archive/zip#FileHeader

先把标志声明、字节合法与编码识别分开

// f来自zip.Reader.File；第11位从0计数，掩码为0x0800。
declaredUTF8 := f.Flags&(uint16(1)

以上片段需放在已有成员对象的代码中。declaredUTF8 表示归档的声明；nameValid 表示 Go string 中当前字节是否符合 UTF-8 编码；NonUTF8 则是 archive/zip 读取后的解释字段。名称编码问题应保留这三层信息，不把它们合成一个“编码正确”的布尔值。

特别是纯 ASCII 名称，既能按 UTF-8 解码，也与一些旧编码的 ASCII 部分兼容。它没有足够信息让你从名称本身推导第 11 位是否置位。反过来，标志位置位也不能保证有缺陷的生成器真的写入了合法 UTF-8 字节。

准备一个只读的小 ZIP 样本

实验只需要 Go 工具链与一个可信的小型 sample.zip。把下一节程序保存为 main.go，程序仅列出中央目录中的成员信息；不会调用成员 Open，不会读取解压后的正文，也不会把名称当作输出文件路径。

FileHeader 同时有 Name 和 Comment。名称看起来没问题，而 Comment 含非法 UTF-8 时，Go 的 NonUTF8 判断也可能受到影响。因此检查程序应把两者分别展示。这里讨论的是成员注释，不是整个 ZIP 的归档注释。

代码示例未实际运行。不要为了对照输出而覆盖业务归档，也不要将这一程序当作完整的 ZIP 格式或内容完整性检查器。

读取 Flags，并并列打印两个字符串的合法性

package main

import (
    "archive/zip"
    "fmt"
    "io"
    "os"
    "unicode/utf8"
)

const zipUTF8Flag uint16 = 1 

# 仅查看小型可信ZIP的元数据，不解包、不改写原归档。
go run main.go sample.zip

输出包括带转义的名称、名字节十六进制表示、完整 Flags、UTF8声明、Name合法、Comment合法与 NonUTF8。十六进制表示保留观察依据，避免控制字符或显示替换字符掩盖原始字节。这里的 Flags 来自 archive/zip 读取的中央目录成员头，不是对每个本地文件头逐字节比对。

OpenReader 的错误先处理再访问 File。程序选择在错误时停止；即使返回了可关闭 reader，也只关闭而不继续使用。正常路径由 defer 关闭 ZIP，输出失败也会返回错误。没有打开成员内容，因此无需额外关闭成员 reader。

按预期组合读结果，不把 NonUTF8 当成按位取反

Go 当前读取实现会综合 Name 与 Comment 的字节：任意一个不满足其 UTF-8 检查时，将 NonUTF8 设为 true；两者仅含无需 UTF-8 扩展声明的兼容单字节字符时，可设为 false；其余合法但需要扩展编码声明的情形再参考 0x0800。所以下表应读成条件化预期，而不是已执行日志。

读取行为参考：https://go.dev/src/archive/zip/reader.go

archive/zip 会把读到的名字节保存到 Name 字符串；Go 的 string 可以容纳非法 UTF-8 字节，不会因为字段类型是 string 就自动转码。NonUTF8=true 也不等于“已经确定是 GBK”。历史工具可能使用不同地区编码，仅凭位标志或乱码外观无法可靠识别全部情况。

扩展到写入时，别把设置标志当作转换字节

写入普通中文名称时，应让 Name 和 Comment 先成为你明确希望写入的合法 UTF-8 文本，通常保留 NonUTF8=false，让 Writer.CreateHeader 按自身规则处理声明。当前写入实现对需要多字节 UTF-8 且名称与注释都合法的情况设置标志；纯兼容单字节字符则不一定主动设置。因此，不要把“Go 创建的 ZIP”理解成所有成员一定带 0x0800。

NonUTF8=true 是写入非 UTF-8 名称和注释的意图，会使写入器清除相应位；它不是“帮我转换为某个地区编码”的开关。直接改 Flags 也只改变声明，不会把原先的字节转换成 UTF-8。若原始编码不明确，保留样本和生成工具信息，比盲目尝试多次转码更稳妥。

写入行为参考：https://go.dev/src/archive/zip/writer.go

本例不生成新 ZIP，因此不涉及练习输出文件清理；保留 main.go 供读者继续试验即可。即使编码声明和字节一致，也不能证明成员正文校验正确，更不能证明归档名称适合作为本地落盘路径。

中文名显示正常，就说明第 11 位是 1 吗？

不能。显示程序可能采用自己的解释策略，合法 UTF-8 字节也可能出现在未声明的归档里。需要知道声明就读取 Flags，而不是观察终端字体。

utf8.ValidString 返回 true，能确定不是旧编码吗？

不能。一段字节可能与多种编码的有效序列重叠，ASCII 尤其明显。它只回答 UTF-8 字节合法性，不提供编码来源证明。

修改 NonUTF8 能解决读取后的乱码吗？

不能。修改布尔值不会改变 Name 已有字节，也不会自动重新解码。应根据可信的来源编码另行设计处理，本例仅保留观察数据，不实现猜测式修复。

最小判断只需一条位运算；可靠解释则要把 Flags、Name、Comment 和 NonUTF8 放在各自的位置。知道哪些是归档声明、哪些是读取器判断，才能避免把“可以解码”误写成“已经确定编码”。