exbsa提取工具：二进制归档解包、索引解析与批量校验

简介：ExBSA 提取工具面向 BISHOP 社 GALGAME（视觉小说）资源解包与二次分析场景，适合想查看、备份或研究游戏内图像、音频、剧本等素材的爱好者与开发者，也能帮助理解 BSA 档案的打包结构与资源管理方式。压缩包共 6 个文件，以 3 个可执行程序、2 份 C++ 源码和 1 份说明文档为主，整体仅 36KB，体积轻量，便于快速取用；其中可执行程序对应不同版本，源码可供阅读实现逻辑并做定制修改，说明文档则交代使用注意事项。已有 2483 人学习或下载。通过解包与配套的脚本处理能力，读者可提取 BSA 内容、核对版本差异，并在此基础上进行资源整理、本地化或 MOD 研究，兼顾实用性与学习参考价值。

1. 拿到 exbsa 提取工具的第一反应，往往是错的

第一次接触 exbsa 提取工具的人，八成会先双击可执行文件，然后看到一个黑窗口刷出几行 usage 就没了下文。这类归档提取工具的通病在于——最难的部分（偏移计算、分块拼接、命名还原）全藏在参数后面，而不是藏在代码里。exbsa 是一类带索引表的二进制归档格式，常见于客户端资源打包：贴图、配置、音频、脚本被塞进单个容器，头部记魔数和版本，中间是索引表，后面跟数据块，部分条目还会走 zlib 压缩。这份工具能把这些容器拆回目录树，并还原原始文件名和层级。适合两类人：手上有一批 .exbsa 却打不开的资源维护者，以及需要把归档内容接进自己流水线的工程师。下面按「先跑通、再拆解、后批量、最后避坑」的顺序走一遍。

2. 先跑通最小闭环：环境、依赖与第一次解包

在动真实数据之前，一定要先建立一个能重复验证的最小闭环。很多人上来就把整个资源目录丢进去跑，结果中途报错，输出目录里一半是完整文件、一半是 0 字节残片，根本分不清是工具的问题还是数据的问题。我的习惯是先挑一个体积最小的包，输出到一个全新的空目录，跑完立刻检查三件事：条目数是否和--list一致、有没有 0 字节文件、CRC 校验是否全绿。这三件事过了，再谈批量。

2.1 为什么用命令行版本而不是现成 GUI

exbsa 提取工具的图形界面版本不是不能用以，而是它在三种场景下会拖后腿：一是批量处理，GUI 一般只支持单文件拖拽，几百个包靠手点不现实；二是可复现，命令行参数能写进脚本、能进版本库，GUI 的勾选项只能截图；三是出错定位，命令行会把每个条目的偏移、压缩大小、解压结果打到日志里，GUI 往往只弹一个「提取失败」。

我一般用的环境是 Python 3.8 以上，标准库就够：struct负责二进制解包，zlib负责解压，hashlib和binascii负责校验，csv负责导清单。不需要装第三方包，也就避开了「换台机器装不上」这类玄学问题。资源包里通常自带requirements.txt，可以先跑一次pip install -r requirements.txt确认，但核心解析逻辑本身不依赖它。

# 确认解释器版本，低于 3.8 会因为 struct 的部分格式符行为差异出问题 python --version # 只装工具自身声明的依赖，不额外装东西 pip install -r requirements.txt # 看一眼工具支持哪些参数，重点看 --list / --no-overwrite / --include python exbsa_extract.py --help

这段命令的逻辑很简单：先用版本号排除环境问题，再装依赖，最后把参数表打出来。参数表一定要在跑真实数据之前看，因为不同构建版本的 exbsa 提取工具在参数命名上会有出入，比如有的版本用-o表示输出目录，有的版本-o是 overwrite 开关、输出目录要写-d。这一步省下来，后面就是成倍的时间。

2.2 单文件解包：从容器到目录树

最小闭环的核心是一条命令。挑样本包里最小的那个文件，输出目录用一个全新的路径，并且强制不开覆盖。

# 单文件最小闭环：输入一个样本包，输出到干净目录，禁止覆盖已有文件 python exbsa_extract.py ./samples/demo.exbsa \ -o ./out/demo_20240101 \ --no-overwrite \ --log ./out/demo_20240101/extract.log # 只看清单不落盘，用来和真实输出做条目数比对 python exbsa_extract.py ./samples/demo.exbsa --list > ./out/demo_20240101/manifest_raw.txt # 比对条目数与输出文件数，两边对不上说明有跳过或失败 wc -l ./out/demo_20240101/manifest_raw.txt find ./out/demo_20240101 -type f ! -name '*.log' ! -name 'manifest_raw.txt' | wc -l

-o后面跟的是输出根目录，工具会在这个目录下按包内虚拟路径重建层级；--no-overwrite是关键，它保证已存在的文件不被覆盖，第二次跑同一个包时能立刻看出「这次是不是真的多提了东西」；--log把每个条目的偏移、压缩前后大小、校验结果写进日志，出问题时这是唯一的黑匣子；--list只解析索引表、不写文件，用来在真正解包之前先摸清条目总数和命名规律。

跑完之后不要只看「成功」两个字。打开日志，抽三条记录核对：偏移是否落在文件长度范围内、压缩大小是否小于等于原始大小、CRC 是否匹配。这三项任意一项异常，说明后面批量跑一定会翻车，先在这里停下来。

2.3 参数怎么给：过滤、扁平化与输出策略

真实场景里很少有人需要把整个包原样倒出来。多数时候只要某几类文件，这时候过滤参数就派上用场。需要注意的是：--include匹配的是包内虚拟路径，不是磁盘路径；--flatten会把所有文件平铺到一层，重名文件会被加后缀或直接覆盖，取决于工具实现。

过滤之后最稳妥的做法是走两段式：先出清单，再用文本工具筛，最后按筛出来的名单逐个提。这样每一步都能留痕。

# 第一段：导出完整清单 python exbsa_extract.py demo.exbsa --list > manifest.txt # 第二段：用 grep 挑出需要的类型，只留第一列的虚拟路径 grep -E '\.(png|json)$' manifest.txt | awk '{print $1}' > wanted.txt # 第三段：按名单精确提取，避免整包解出几百个用不上的文件 while read -r p; do python exbsa_extract.py demo.exbsa -o ./out/pick --only "$p" --no-overwrite done < wanted.txt

这里--only是按单个虚拟路径精确提取，如果你的工具版本没有这个参数，就退回整包解包再用白名单过滤，代价是多一次磁盘写入。while read循环里没有加并行，是因为并行提取同一个包会争抢同一个输出目录，除非每个任务单独给输出目录，否则不要图快。

3. 拆开文件头与索引表：exbsa 的四个关键字段

工具能跑通不代表你理解了它。当遇到「清单里有、解出来是空」或者「解出来的文件打不开」这类问题时，唯一能定位的办法是把容器拆到字段级别。exbsa 这类归档的骨架基本固定：文件头 → 索引表 → 数据区，变数集中在版本号之后的字段顺序、大小端、以及索引表偏移的基准点。下面这段探测脚本只读不写，用来看清头部到底长什么样。

3.1 先用十六进制确认魔数与版本

不要相信文档，先看字节。用xxd或 Python 打出前 64 字节，人眼确认魔数是不是EXBSA、版本号落在哪两个字节、后面紧跟的是条目数还是索引偏移。这一步花两分钟，能省掉后面两小时。

# 打出前 64 字节，左边十六进制、右边 ASCII，方便同时看魔数和可读字段 xxd -l 64 ./samples/demo.exbsa

如果看到前 5 个字节是45 58 42 53 41，对应 ASCII 就是EXBSA，说明魔数没跑偏。紧跟其后的 2 字节通常是版本号，再往后 4 字节是条目数，然后是 8 字节的索引表偏移。但不同构建会把「条目数」和「索引长度」对调，也会把偏移改成相对文件尾的负偏移。判断办法很朴素：按你猜的字段读出来的数值，丢回文件里做边界检查，条目的偏移加大小不能超过文件总长，条目的偏移不能小于头部长度。

# exbsa_probe.py —— 只读头部，不做任何写入 import struct import sys MAGIC = b"EXBSA" HEADER_FMT = "<5sHIQ" # 魔数5 + 版本2 + 条目数4 + 索引偏移8，小端不填充 HEADER_LEN = struct.calcsize(HEADER_FMT) # 19 def probe(path: str) -> None: with open(path, "rb") as f: head = f.read(HEADER_LEN) f.seek(0, 2) total = f.tell() magic, version, count, index_off = struct.unpack(HEADER_FMT, head) print(f"file={path} size={total}") print(f"magic={magic!r} version={version} entries={count} index_off={index_off}") # 三条边界检查，任何一条不过说明字段位置猜错了 if magic != MAGIC: print("[fail] 魔数不匹配，字段布局可能整体偏移") if not (HEADER_LEN <= index_off < total): print(f"[fail] 索引偏移 {index_off} 越界，可能基准点不是文件头") if count <= 0 or count > 1_000_000: print(f"[fail] 条目数 {count} 不合理，可能读成了索引长度") if __name__ == "__main__": probe(sys.argv[1])

HEADER_FMT里的<表示小端并且不填充，这一点必须显式写出来，否则struct会按原生对齐在H和Q之间插空字节，读出来的索引偏移直接错位。calcsize算出的 19 是真实头部长度，如果你换成5sH I Q（带空格）结果一样，但换成不带<的写法就会变成 24，这就是很多人第一次拆包读出一堆乱数的原因。

3.2 索引表解析：偏移、压缩大小、原始大小

确认头部之后，索引表的每条记录一般长这样：名称长度（2 字节）→ 名称（UTF-8）→ 数据偏移（8 字节）→ 原始大小（4 字节）→ 压缩大小（4 字节）→ CRC32（4 字节）。总计 22 字节加上名称长度。这个布局不是唯一解，但它是同类归档里最常见的一种，先用它套，套不上再调整字段顺序。

import struct from dataclasses import dataclass @dataclass class Entry: name: str offset: int raw_size: int pack_size: int crc32: int def read_index(path: str): with open(path, "rb") as f: buf = f.read() _, version, count, index_off = struct.unpack_from("<5sHIQ", buf, 0) pos = index_off entries = [] for _ in range(count): # 名称长度 + 名称 (name_len,) = struct.unpack_from("<H", buf, pos) pos += 2 name = buf[pos:pos + name_len].decode("utf-8", errors="replace") pos += name_len # 偏移、原始大小、压缩大小、CRC offset, raw_size, pack_size, crc = struct.unpack_from("<QIII", buf, pos) pos += 20 # 每条记录都做一次边界检查，早失败好过晚失败 if offset + pack_size > len(buf): raise ValueError(f"{name} 数据区越界: {offset}+{pack_size} > {len(buf)}") if pack_size > raw_size: raise ValueError(f"{name} 压缩后大于原始大小，字段顺序可能反了") entries.append(Entry(name, offset, raw_size, pack_size, crc)) return version, entries

这段代码里有三个判断比解析本身更重要。第一，offset + pack_size > len(buf)拦住的是「索引偏移基准猜错」；第二，pack_size > raw_size拦住的是「原始大小和压缩大小两个字段顺序对调」，这种情况解出来的文件会整片截断；第三，名称解码用了errors="replace"而不是严格模式，因为真实包里混着 GBK 编码的老资源，严格模式会直接抛异常把整批任务打断，替换成占位符反而能让后面的条目继续解出来，事后按日志里的替换标记单独修。

3.3 分块与对齐：为什么条目之间有空洞

解出几条记录之后，把偏移排个序，你会发现相邻条目之间并不紧挨着，中间有几十到几百字节的空隙。这些空隙通常来自三件事：按 16 字节或 512 字节做对齐填充、存放分块表、以及存放附加的元信息（比如资源类型标记）。对齐填充本身不影响提取，但如果你写的是「从上一个条目末尾读到下一个条目开头」这种按顺序切片的逻辑，就会把这些填充字节一起写进文件，解出来的 PNG 头部多出一堆零，打开直接报格式错误。

判断有没有分块表，看同一个条目的压缩数据解压时是否报zlib.error: Error -3 while decompressing data。如果单个条目很大（超过几百 KB）且必然报这个错，多半是数据被切成多个 chunk 存放，索引里的offset指向的是 chunk 表而不是数据本体。chunk 表的典型结构是「chunk 数量 + 每个 chunk 的偏移与长度」，需要先读表、再按表拼接、最后统一解压。

import zlib def read_entry(buf: bytes, e: Entry) -> bytes: blob = buf[e.offset:e.offset + e.pack_size] # 先判断是不是裸数据：能直接对上 CRC 就不要走解压 if e.pack_size == e.raw_size: return blob # 尝试整块解压，失败则按 chunk 表拼接 try: return zlib.decompress(blob) except zlib.error: (chunk_count,) = struct.unpack_from("<I", blob, 0) parts = [] p = 4 for _ in range(chunk_count): coff, clen = struct.unpack_from("<QI", blob, p) p += 12 parts.append(blob[coff:coff + clen]) return zlib.decompress(b"".join(parts))

顺便说一句，pack_size == raw_size时直接返回裸数据这个分支，能挡掉一类常见误判：有些条目标记了压缩但实际是存储模式，硬解压会报错，而工具如果没做这个判断，就会把这类文件全标成失败。CRC 校验放在拿到完整字节之后做，binascii.crc32(data) & 0xFFFFFFFF和索引里的值比对，不匹配的条目单独列出来，不要混在成功列表里。

4. 批量提取：几百个包一次跑完还不乱

单包跑通之后，真正的工程量在批量。几百个 .exbsa 摆在一个目录里，命名规则不统一、版本号参差、个别包损坏，直接写个 for 循环一把梭，结果就是跑到第 60 个崩掉，前面 59 个的输出不知道哪些完整哪些残缺。批量脚本的核心不是「跑得快」，而是「跑挂了能知道挂在哪、重跑不用从头来」。

4.1 遍历、隔离与失败重试

我一般会把批量任务拆成三层：外层遍历包文件，中层对每个包起一个独立输出目录，内层捕获异常并写进失败清单。独立输出目录是关键，它保证了单个包失败不会污染其他包的结果，重跑时只需要按失败清单补。

import csv import subprocess import sys import time from pathlib import Path ROOT = Path("./corpus") # 所有 .exbsa 所在目录 OUT = Path("./out") # 输出根目录 FAIL = Path("./out/_failed.csv") # 失败清单，重跑依据 def run_one(pkg: Path) -> tuple[bool, str]: dst = OUT / pkg.stem # 每个包一个独立目录，避免互相覆盖 dst.mkdir(parents=True, exist_ok=True) cmd = [ sys.executable, "exbsa_extract.py", str(pkg), "-o", str(dst), "--no-overwrite", "--log", str(dst / "extract.log"), ] for attempt in range(3): # 最多重试三次 r = subprocess.run(cmd, capture_output=True, text=True) if r.returncode == 0: return True, "" time.sleep(1 + attempt) # 退避，避开偶发的文件句柄占用 return False, (r.stderr or r.stdout).strip()[:500] def main() -> None: pkgs = sorted(ROOT.rglob("*.exbsa")) fails = [] for i, pkg in enumerate(pkgs, 1): ok, msg = run_one(pkg) print(f"[{i}/{len(pkgs)}] {pkg.name} {'ok' if ok else 'FAIL'}") if not ok: fails.append({"file": str(pkg), "error": msg}) with FAIL.open("w", newline="", encoding="utf-8") as f: w = csv.DictWriter(f, fieldnames=["file", "error"]) w.writeheader() w.writerows(fails) print(f"失败 {len(fails)} 个，清单见 {FAIL}") if __name__ == "__main__": main()

rglob("*.exbsa")会递归子目录，如果你的语料是平铺的，换成glob更快。dst = OUT / pkg.stem用包名做目录名，前提是包名唯一，重复的话要加父目录名拼进去。重试三次加退避，是为了对付 Windows 上「文件被另一个进程占用」这类非确定性失败——这种失败重跑一次就好，但如果脚本不重试，它会老老实实记成失败，让你以为包坏了。失败清单用 CSV 而不是直接打印，是为了后面能用while read循环精确重跑：

# 按失败清单逐个重跑，输出到 _retry 目录，不碰上一次的结果 tail -n +2 out/_failed.csv | cut -d, -f1 | while read -r f; do python exbsa_extract.py "$f" -o "./out/_retry/$(basename "$f" .exbsa)" --no-overwrite done

4.2 文件名还原：哈希名、序号名与路径分隔符

批量之后最容易出问题的是命名。包内文件名有三种常见形态：完整虚拟路径（ui/icon/close.png）、扁平哈希名（a3f9c1e2.bin）、序号名（000123.dat）。完整路径直接重建层级就行；哈希名需要靠内容特征反推类型，比如看文件头魔数判断是 PNG 还是文本；序号名则要结合索引表里的原始扩展名字段，如果没有这个字段，就只能靠内容嗅探。

路径分隔符也得处理。包内路径可能用反斜杠，直接拼到输出目录上在 Linux 下会变成文件名的一部分，生成一堆名字里带\的怪文件。统一替换成正斜杠再拼接，是批量场景下的固定动作。

import mimetypes from pathlib import Path, PurePosixPath def safe_target(root: Path, virtual_path: str) -> Path: # 反斜杠统一成正斜杠，避免不同平台生成的路径不一致 vp = virtual_path.replace("\\", "/").lstrip("/") # 拦住路径穿越：任何 .. 段直接拒绝，防止写到输出目录之外 parts = [p for p in PurePosixPath(vp).parts if p not in ("", ".", "..")] if not parts: parts = ["_unnamed"] target = root.joinpath(*parts) # 兜底：解析后的绝对路径必须仍在输出根目录之下 if not str(target.resolve()).startswith(str(root.resolve())): raise ValueError(f"路径穿越风险: {virtual_path}") return target def sniff_ext(head: bytes) -> str: # 只覆盖最常见的几类，其余交给原始扩展名 if head.startswith(b"\x89PNG\r\n\x1a\n"): return ".png" if head.startswith(b"\xff\xd8\xff"): return ".jpg" if head[:4] == b"PK\x03\x04": return ".zip" if head[:5] in (b"<?xml", b"{\"") or head[:1] in (b"{", b"["): return ".json" return ""

safe_target里两层防护缺一不可：第一层过滤掉..段，第二层用resolve()做最终比对。只做第一层不够，因为符号链接和大小写差异在某些文件系统上会绕过字符串判断。哈希名的处理要注意，sniff_ext只是辅助，最终命名建议保留原名加嗅探出的后缀，比如a3f9c1e2.bin.png，这样既不丢原始标识，又能被看图工具直接打开。

4.3 归档、去重与清单生成

批量跑完，输出目录里往往有大量重复内容。同一个贴图在不同包里存了三四份的情况非常普遍，直接合并会浪费空间，也不利于后续比对。我一般会在提取完成后做一轮哈希去重，同时生成一份总清单，把「包名 → 虚拟路径 → 输出路径 → 大小 → CRC」记全，后面无论做版本比对还是资源审计都靠这张表。

import hashlib import csv from pathlib import Path def build_manifest(out_root: Path, manifest: Path) -> None: rows = [] for p in out_root.rglob("*"): if not p.is_file() or p.name.endswith(".log") or p.name == manifest.name: continue h = hashlib.sha256(p.read_bytes()).hexdigest() rows.append({ "path": str(p.relative_to(out_root)), "size": p.stat().st_size, "sha256": h, }) with manifest.open("w", newline="", encoding="utf-8") as f: w = csv.DictWriter(f, fieldnames=["path", "size", "sha256"]) w.writeheader() w.writerows(rows) # 按哈希分组，组内多于一条即为重复 seen = {} for r in rows: seen.setdefault(r["sha256"], []).append(r["path"]) dup = {k: v for k, v in seen.items() if len(v) > 1} print(f"总文件 {len(rows)}，重复组 {len(dup)}")

sha256而不是md5，是为了避免后续做跨版本比对时出现碰撞误判，代价是慢一点，但在几千个文件的量级上差别可以忽略。relative_to保证清单里记的是相对路径，换机器之后清单还能用。重复组不要急着删，先出一份报告，很多重复其实是不同分辨率或不同语言版本的同名资源，删错了很难找回。

5. 提取翻车的五类现场：现象、原因与解决

下面这五条都是我在真实语料上撞过的，按出现频率从高到低排。每条都按「看到什么 → 为什么 → 怎么办」写，遇到同类现象可以直接对号入座。

5.1 解出来一堆 0 字节文件

现象：输出目录结构完整、文件名也对，但每个文件都是 0 字节，ls -l一排全是 0。

原因：索引表读到了，但数据区切片时偏移基准搞错了。最常见的是索引里的offset是相对数据区起点而不是相对文件头，工具直接拿它去seek，读到的是索引表自己的字节，解压后自然为空；另一种是把压缩大小读成了 0。

解决：先打印第一条记录的offset和文件总长做比对，如果offset明显小于头部长度（19 字节），基本可以确认基准点不对，需要加上数据区起点；如果offset正常但pack_size是 0，说明字段顺序里大小字段位置读偏了，按 3.2 的布局逐个字段试。定位之前在日志里把这三个值打出来，比盲目改代码快得多。

5.2 文件名乱码，中文变成问号或方块

现象：英文名正常，中文名显示成???或者一堆替换字符，输出路径里出现\ufffd。

原因：包内名称编码不统一。新版本用 UTF-8，老资源用 GBK，工具一刀切按 UTF-8 严格解码，遇到非法字节直接抛异常或者替换成占位符。

解决：解码改成「先严格 UTF-8，失败回退 GBK」的两段式，并且在日志里记录回退次数。回退之后仍要检查一遍结果里有没有替换字符，有的话说明两种编码都不是，需要按实际字节做映射。不要图省事直接用errors="ignore"，那会把整个文件名吃掉一部分，生成一堆同名文件互相覆盖。

def decode_name(raw: bytes) -> tuple[str, str]: # 返回 (名称, 使用的编码)，便于统计和事后修正 try: return raw.decode("utf-8"), "utf-8" except UnicodeDecodeError: return raw.decode("gbk", errors="replace"), "gbk"

5.3 大文件解到一半报 zlib 错误

现象：小文件全部正常，几百 KB 以上的条目必然报zlib.error: Error -3 while decompressing data: invalid distance too far back。

原因：数据被切成多个 chunk 存放，索引里的偏移指向的是 chunk 表而不是压缩数据本体，工具把整张表当压缩流喂给 zlib，自然解不动。

解决：按 3.3 的逻辑先读 chunk 数量，再逐块读偏移和长度，拼接之后统一解压。判断依据是错误是否只在大条目上出现、且错误码稳定。拼接时注意 chunk 之间的顺序，有些包把 chunk 表按写入顺序存、数据块按逆序存，需要按偏移排序后再拼。

5.4 第二次跑把第一次的结果覆盖了

现象：重跑同一个包之后，输出目录里的文件时间戳全变了，之前手工修过的几个文件被还原成原始版本。

原因：工具默认覆盖同名文件，--no-overwrite没开，或者开了但输出目录和上一次是同一个。

解决：输出目录带日期或批次号，批量脚本里用pkg.stem做子目录名，天然隔离；单文件操作时强制加--no-overwrite，并且在跑之前先find 输出目录 -type f | wc -l记一下数量，跑完再数一次，数量对不上立刻停。这条看起来是操作习惯问题，但翻车成本最高——原始包还在，手工修过的结果没了就是没了。

5.5 包内路径带..，文件写到了输出目录外面

现象：输出目录里文件数比清单少，但在输出目录的上一级、甚至更远的地方发现了陌生文件。

原因：包内虚拟路径里带了../段，工具直接做字符串拼接，路径穿越把文件写到了预期之外的位置。这类包可能是打包时出错，也可能是刻意构造的。

解决：所有虚拟路径在拼接之前必须先规范化，过滤掉..和空段，拼接后再用resolve()做一次包含性检查，不通过的直接拒绝并记日志。不要因为「自己的语料应该没问题」就跳过这层校验，批量场景下只要有一个包带这种路径，排查起来就够折腾半天。

6. 进阶：校验、二次识别与一条固定动作

提取跑通只是第一步，真正决定输出能不能直接用的，是校验和二次加工。我一般会在批量结束之后做三件事，按顺序来。

第一件是全量 CRC 对账。把索引表里的 CRC32 和实际写出文件的 CRC 逐条比对，输出一张差异表。差异表为空说明提取链路干净；有差异时要看差异集中在哪些包上，如果集中在某几个包，多半是那几个包的格式版本不同，单独拆；如果分散在所有包里，说明压缩分支的判断逻辑有问题。

第二件是内容嗅探补后缀。哈希名的条目提取出来是.bin，用 4.2 里的sniff_ext过一遍，能识别出 PNG、JPEG、ZIP、JSON 的就补上对应后缀，识别不出的保留原名并在清单里标unknown。这一步看起来琐碎，但它直接决定了后面能不能批量预览、能不能被其他工具链识别。

第三件是生成一份可复跑的配置。把这次用的参数（包括过滤规则、编码回退策略、chunk 阈值）写成一份 JSON，和输出放在一起。下次遇到同一批来源的包，直接读配置跑，不用再回忆当初是怎么设的。

# 固化本次参数，下次同源包直接复用 cat > ./out/extract_profile.json <<'EOF' { "include": ["*.png", "*.json", "*.bin"], "encoding_fallback": ["utf-8", "gbk"], "chunk_threshold_bytes": 262144, "no_overwrite": true, "verify_crc": true } EOF # 复跑时带上配置，参数不再靠记忆 python exbsa_extract.py ./corpus/new_batch/*.exbsa -o ./out/batch_02 --profile ./out/extract_profile.json

chunk_threshold_bytes这个阈值不是拍脑袋定的，是拿历史语料统计出来的：超过这个大小还整块解压失败的条目占比会跳变，低于它基本不会触发分块。这个值因包而异，第一次用建议先设大一点（比如 1MB），看日志里分块失败的分布再往下调。

一个具体技巧：不确定某个包该不该整包解的时候，先跑--list加--dry-run（如果你的版本支持），只出清单不落盘，看条目数和类型分布再决定。我曾经在一个 200MB 的包上直接开解，跑完发现里面 90% 是无用的中间产物，白占磁盘还拖慢了后面的比对。从那以后我每次批量之前都强制先走一遍 dry-run 出清单，确认条目类型分布再动手。希望帮到你。

本文还有配套的精品资源，点击获取