Go debug/pe.File.StringTable 怎样读取 COFF 字符串表

用 Go 分析 PE 或 COFF 文件时，debug/pe.File.StringTable 不是一个普通的字符串数组：它保存的是 COFF 字符串表的内容，读取位置要使用符号记录里的偏移值。最稳妥的做法是先用 pe.Open 打开文件，再把偏移交给 file.StringTable.String(offset)；如果目标是解析符号名称，优先调用 COFFSymbol.FullName(file.StringTable)，让标准库处理短名称和长名称两种编码。

这篇只讨论字符串表的读取和符号名解析，不涉及 DLL 加载、重定位或修改 PE 文件。还要先接受一个现实：很多最终链接好的 PE 可执行文件并没有可用的 COFF 符号表，这时 StringTable 为空并不代表 Go 代码写错，而是输入文件本身没有这段元数据。

先分清三个容易混淆的对象

debug/pe.File 会把几个相关结果放在一起：

如果只是展示符号名称，遍历 file.Symbols 通常更简单；如果要解释“为什么这个名称要去字符串表查”，或者要保留辅助符号和原始名称字段，就使用 file.COFFSymbols 配合 file.StringTable。

用 StringTable.String 按偏移读取

COFF 字符串表的偏移包含前面的 4 字节长度字段，因此有效起始偏移通常从 4 开始，而不是从 0 开始。标准库的实现会先减去这 4 个字节，再从表内找到以 NUL 结束的字符串；传入小于 4 或超出范围的偏移会返回错误。

package main

import (
	"debug/pe"
	"fmt"
	"log"
	"os"
)

func main() {
	path := os.Args[1]
	file, err := pe.Open(path)
	if err != nil {
		// 输入不是可识别的 PE 文件时，先保留原始错误，方便定位文件来源。
		log.Fatal(err)
	}
	defer file.Close()

	if len(file.StringTable) == 0 {
		// 没有符号表或字符串表时，直接说明元数据缺失，不伪造读取结果。
		fmt.Println("文件没有可用的 COFF 字符串表")
		return
	}

	// 偏移 4 表示字符串表长度字段之后的第一个位置。
	name, err := file.StringTable.String(4)
	if err != nil {
		// String 会检查偏移是否落在字符串表的有效范围内。
		log.Fatal(err)
	}
	fmt.Printf("第一个字符串：%s\n", name)
}

这里的 4 只是演示字符串表的第一个合法逻辑起点，不代表每个文件在这个位置都一定有完整名称。真实解析应当从符号记录拿到偏移，并把错误当作输入格式异常处理。

长符号名交给 COFFSymbol.FullName

COFF 符号的名称字段只有 8 个字节。名称较短时，它直接放在 sym.Name；名称较长时，前 4 个字节为零，后 4 个字节保存字符串表偏移。手工解析这两个分支容易漏掉小端序和空名称情况，标准库已经提供了 FullName。

package main

import (
	"debug/pe"
	"fmt"
	"io"
	"log"
)

func printCOFFSymbols(r io.ReaderAt) error {
	file, err := pe.NewFile(r)
	if err != nil {
		// NewFile 只负责解析输入，不接管 ReaderAt 的关闭责任。
		return err
	}
	defer file.Close()

	for index := range file.COFFSymbols {
		symbol := &file.COFFSymbols[index]
		name, err := symbol.FullName(file.StringTable)
		if err != nil {
			// 偏移越界通常说明符号记录与字符串表不匹配，不能静默跳过。
			return fmt.Errorf("解析第 %d 个 COFF 符号失败: %w", index, err)
		}
		if name == "" {
			// 空名称可能是无名记录或特殊元数据，展示时单独标记。
			log.Printf("符号 %d 没有名称", index)
			continue
		}
		fmt.Printf("%d: %s\n", index, name)
	}
	return nil
}

如果通过 pe.Open 打开文件，就把 *pe.File 中已经填充的 COFFSymbols 传给同样的循环即可。使用 pe.NewFile 时，调用方负责提供 io.ReaderAt；示例没有替它关闭底层文件。

直接调用 String 时要处理哪些边界

StringTable.String 的错误边界很明确，实际代码可以按下面几类理解：

• 偏移小于 4：它还落在字符串表的长度字段范围内，不能作为字符串起点。
• 偏移超过表尾：符号记录引用了不存在的字符串，继续切片会掩盖输入损坏。
• 表长度不超过 4：只有长度字段，没有有效字符串内容，标准库会把它视为没有可读字符串。
• 没有 COFF 符号表：File.StringTable 可能为空，最终 PE 文件缺少调试或链接元数据时尤其常见。

因此，判断“读不到字符串”时不要只看 len(file.StringTable)。还要结合 file.FileHeader.PointerToSymbolTable、NumberOfSymbols 和 len(file.COFFSymbols) 看输入是否真的带有可解析的 COFF 符号记录。

什么时候应该使用 Symbols 而不是 StringTable

如果业务目标只是生成符号索引、打印名称或做简单过滤，file.Symbols 更省事，因为标准库已经在构造 Symbol 时调用了 FullName，并移除了辅助符号记录。只有下面几类需求，才值得直接保留 StringTable 和 COFFSymbols：

小结

File.StringTable 是 COFF 字符串表的访问入口，String(start) 的参数是包含 4 字节长度字段语义的偏移，不要把它当成普通切片下标。解析符号名时，优先使用 COFFSymbol.FullName(file.StringTable)；只做展示时直接使用已经整理好的 file.Symbols。遇到空表或偏移错误，先判断输入文件是否真的包含 COFF 符号元数据，再决定是报告缺失还是处理损坏记录。

相关问题

为什么 StringTable.String(0) 会报错？

因为 COFF 字符串表的前 4 个字节用于存放表长度，Go 文档规定传入的偏移包含这段长度字段，所以有效起点不能小于 4。

所有 PE 文件都有 StringTable 吗？

不是。没有 COFF 符号表或表长度只有 4 字节时，字符串表可能为空。最终可执行文件和仍保留链接元数据的对象文件，在这方面不能一概而论。

已经有 file.Symbols，为什么还要看 COFFSymbols？

Symbols 适合业务使用，名称已被转换；COFFSymbols 才保留原始名称字段和辅助符号，适合排查长名称偏移或研究文件结构。