4. SMBIOS 数据结构
在 SMBIOS 开发中，真正决定“能不能被正确解析”的，不是某个字段填了什么值，而是整张表的数据结构与边界规则是否严格符合规范。BIOS 写入的每一个字节，最终都要经过操作系统、DMI 解析库、厂商工具的多层读取；任何一处对齐错误、结束标记缺失或字符串索引越界，都会导致整条记录被丢弃，甚至让解析器直接停止遍历。本节从入口点结构出发，逐层拆解 SMBIOS 的物理布局。
一、入口点结构：32 位与 64 位的双入口设计
SMBIOS 表并不是从固定地址直接开始的，而是先通过一个“入口点”告诉解析器：结构表在哪里、有多长、有多少条记录。规范定义了两种入口点：32 位入口点（EPS，Entry Point Structure）和 64 位入口点。32 位入口点通常位于 0xF0000~0xFFFFF 的 BIOS 只读区域，以锚点字符串 _SM_ 标识；64 位入口点则以 _SM3_ 标识，可位于更低或更高的地址空间，用于支持超过 4GB 的结构表寻址。
32 位入口点的关键字段包括：锚点 _SM_、校验和、结构表长度、结构表地址、结构表条目数、SMBIOS 主次版本号，以及可选的中间入口点。64 位入口点在此基础上扩展了 64 位地址字段，并保留了对旧版解析器的兼容入口。开发中最常见的错误是：只写了 32 位入口点却把结构表放到 4GB 以上，或校验和计算时漏算某个字节，导致 dmidecode 报 “No SMBIOS nor DMI entry point found”。
32 位入口点关键字段（偏移示意）
0x00 Anchor String "_SM_"
0x05 Checksum 所有字节累加为 0
0x06 Entry Point Length
0x07 Major Version
0x08 Minor Version
0x09 Max Structure Size
0x0A Entry Point Revision
0x10 Structure Table Length
0x14 Structure Table Address (32-bit)
0x18 Number of Structures
0x1A BCD Revision二、结构表头与格式化区域
入口点之后，每一条 SMBIOS 记录都由“结构表头 + 格式化区域 + 字符串区域”三部分组成。结构表头固定 4 字节：Type（类型）、Length（格式化区域长度）、Handle（16 位句柄）。其中 Length 只描述格式化区域的字节数，不包含字符串区域。格式化区域是字段的密集排列区，字段顺序、宽度、有无符号、单位都由规范按 Type 严格定义。
例如 Type 0（BIOS Information）的格式化区域包含厂商字符串索引、BIOS 版本索引、起始地址段、发布日期、ROM 大小、BIOS 特性位等；Type 1（System Information）则包含制造商、产品名、版本、序列号、UUID、唤醒类型等。解析时必须先读 Length，再按规范逐字段偏移读取，绝不能假设某字段一定存在——因为规范允许厂商在末尾追加字段，Length 可能大于基础定义长度。
结构起始 + Length 开始，二者以连续的 0x00 字节分隔。三、字符串区域、结束标记与对齐规则
字符串区域紧跟在格式化区域之后，采用“以 0x00 结尾的 ASCII 字符串序列”，并以一个额外的 0x00 表示字符串集合结束。格式化区域中的字符串字段并不直接存字符串，而是存1 起始的索引：索引 1 表示第一个字符串，索引 2 表示第二个，0 表示“无字符串”。这一点极易出错：很多开发者习惯用 0 起始下标，结果把厂商名写成了空。
每条记录的结束标记是“双 0x00”：第一个 0x00 结束最后一个字符串，第二个 0x00 表示字符串集合结束。如果某条记录没有任何字符串，则格式化区域之后直接跟两个 0x00。整张结构表的结束标记是 Type 127（End-of-Table），其 Length 通常为 4，Handle 为 0x0000，之后同样以双 0x00 收尾。
对齐规则方面，SMBIOS 结构在内存中按字节紧密排列，不插入填充字节；但结构表整体起始地址通常要求 16 字节对齐，64 位入口点还要求结构表地址按 8 字节或 16 字节对齐。字符串区域内部不要求对齐，但字符串本身建议使用可打印 ASCII，避免高位字符导致解析器误判。
四、案例：一次“记录丢失”的排障复盘
某项目在 Linux 下执行 dmidecode -t 1 只能看到 Type 0，Type 1 及之后全部消失。排查发现：Type 0 的格式化区域 Length 被误写为 0x12，但实际只填了 0x10 字节，导致解析器把字符串区域的前两个字节当成了格式化字段，随后读取字符串时越界，遇到非预期字节后提前终止遍历。修正 Length 并补齐双 0x00 后，所有记录恢复正常。
这个案例说明：Length 必须与实际写入的格式化区域字节数完全一致，字符串索引必须从 1 开始，结束标记必须成对出现。三者缺一不可。
五、常见误区清单
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 字符串索引从 0 开始 | 厂商名显示为空或错位 | 索引 1 对应第一个字符串，0 表示无 |
| Length 包含字符串区域 | 解析器偏移错乱，后续记录丢失 | Length 仅统计格式化区域字节数 |
| 只写一个 0x00 结束 | 解析器继续读取垃圾数据 | 字符串集合末尾必须双 0x00 |
| 缺少 Type 127 结束标记 | 遍历越界，工具报错 | 结构表末尾必须追加 Type 127 |
| 结构表地址未对齐 | 部分固件或 OS 拒绝解析 | 整体 16 字节对齐，64 位入口点 8/16 字节 |
dmidecode --dump-bin smbios.bin 导出原始二进制，再用十六进制工具逐字节核对入口点校验和、每条记录的 Length 与双 0x00 位置，比只看解析结果更快定位问题。掌握入口点、表头、格式化区域、字符串区域、结束标记与对齐规则这六个要素，就相当于拿到了 SMBIOS 结构表的“地图”。后续无论是新增 Type、扩展字段，还是做跨平台兼容，都可以在这张地图上精确定位、安全修改。