FLIC帧跳转表位置由文件头flags字段第0位决定，存在时位于头长+2字节处，结构为num_frames个32位小端偏移值，指向各FRAME chunk起始而非像素数据。
FLIC帧跳转表在文件中的位置和结构怎么确认
FLIC（.fli/.flc）格式的帧跳转偏移表（Frame Offset Table）不是固定位置，它只存在于 FLIC 文件头中标记为 FLX_TYPE 或 FLC_TYPE 的完整动画中，且**仅当文件使用“chunked”编码（即包含 FRAME chunk）时才存在**。关键判断依据是文件头第12字节（0-based）的 flags 字段：若第0位为1（即 flags & 1），表示启用了帧偏移表；此时帧数（num_frames）字段（头中第6–7字节）之后紧跟着的就是该表。
常见错误是直接从文件头末尾开始读偏移，却忽略了 flags 检查——很多工具链（如旧版 libavcodec）会跳过这个标志位，导致解析出错或崩溃。
- 先读取 128 字节文件头，验证
magic是0xAF11（FLI）或0xAF12（FLC） - 检查
flags（头中 offset 12）是否含0x01；否则帧偏移表不存在，所有帧需顺序扫描FRAMEchunk 定位 - 若存在，帧偏移表起始位置 = 头长（128） + 2（
frames字段占2字节），共num_frames * 4字节，每个元素是小端 32 位无符号整数（文件内偏移）
用 C++ 读取并校验帧偏移表的典型实现
直接 fread 或 mmap 读取后必须做边界与单调性校验——FLIC 规范未禁止空帧或重复偏移，但实际播放器（如 xine、mplayer）会拒绝非递增序列。尤其注意：偏移值指向的是每个 FRAME chunk 的起始位置，而非帧像素数据开头（FRAME chunk 内还有自己的 header）。
uint16_t num_frames;
fseek(fp, 6, SEEK_SET);
fread(&num_frames, sizeof(num_frames), 1, fp);
uint8_t flags;
fseek(fp, 12, SEEK_SET);
fread(&flags, sizeof(flags), 1, fp);
<p>if (flags & 1) {
std::vector<uint32_t> offsets(num_frames);
fseek(fp, 128 + 2, SEEK_SET); // 跳过头 + frames 字段
fread(offsets.data(), sizeof(uint32_t), num_frames, fp);</p><pre class='brush:php;toolbar:false;'>// 校验：必须递增，且每个偏移 < file_size
for (size_t i = 0; i < offsets.size(); ++i) {
if (offsets[i] >= file_size || (i > 0 && offsets[i] <= offsets[i-1])) {
// 无效偏移表，降级为 chunk 扫描
}
}}
立即学习“C++免费学习笔记（深入）”；
为什么不能直接用偏移表跳转到像素数据
因为 FRAME chunk 结构本身嵌套：每个 FRAME 开头是 4 字节 chunk type（0xF100）、4 字节 size，之后才是帧 header（包括压缩方式、尺寸等）。像素数据实际位于 FRAME chunk 内部偏移约 16–20 字节处，具体取决于是否含 palette 或 extra info。直接把帧偏移表数值当作像素起始点，会导致解码器读到 chunk header 当作像素，必然解码失败。
- 正确做法：用偏移表定位每个
FRAMEchunk 起始 → 读取其size字段 → 计算像素数据起始 = chunk_start + 8（type+size）+ frame_header_len -
frame_header_len至少为 12（标准 FLIC 帧头），但若flags & 0x02（palette embedded），则需额外 + 768（256×3）字节 - 部分老游戏 FLIC（如 early Deluxe Paint）会在帧头后插入私有 chunk（如
0xF1FA），此时必须按 chunk 链遍历，不能硬算偏移
兼容性陷阱：FLI vs FLC 的帧偏移表差异
FLI（0xAF11）格式理论上不支持帧偏移表——它的规范中没有 flags 字段定义该位，但大量实际文件（尤其是 Autodesk Animator Pro 导出）会滥用 0xAF12 头部写入 FLI 内容，并启用偏移表。更麻烦的是，某些 DOS 工具生成的 FLC 会把 num_frames 设为 0，靠偏移表末尾的 0xFFFFFFFF 作为终止标记，而非依赖头中数值。
- 不要信任头中
num_frames的绝对权威；若偏移表存在，优先以表长度为准，再交叉验证最后一个有效偏移是否 - 对
0xAF11文件，若检测到flags & 1且后续数据符合偏移表结构，应按 FLC 方式解析——这是事实标准，不是 bug - Windows GDI 的
PlayMetaFile系列 API 完全忽略偏移表，只顺序解析；而 FFmpeg 的flicvideo.c在 v4.4 后才修复了对非单调偏移的 fallback 逻辑
偏移表看着简单，但真正鲁棒的解析必须混合头字段、偏移校验、chunk 遍历三重策略——任何单点假设都可能在某个 1992 年的老游戏资源包里翻车。
