简介TextureUnpacker-x86-64v1.0是一款面向Unity开发者和图形设计师的纹理集拆分工具主要解决从plistpng合成大图中还原独立小图的问题适用于需要管理图集、单独编辑精灵或优化游戏资源的场景。压缩包共157个文件约12.79MB包含主程序exe以及运行必需的75个dll、61个xml配置另有config、resources等类型整体是一个Windows 64位可直接运行的工具包目录结构清晰免去额外安装依赖的麻烦。工具通过解析plist坐标和帧信息把大图准确切割为多个独立pngdll负责图像编码与解析逻辑xml记录图集元数据与运行配置这些文件协同工作便于后续维护和替换。已有2923人学习/下载对于经常处理Unity图集、批量拆分Sprite或维护游戏资源的美术和程序人员而言这是一份省时省力的实用工具可避免手工裁剪和反复导入导出的繁琐流程。1. TextureUnpacker 是什么一个把封闭资源里的贴图“抠”出来的命令行工具拿到一个游戏的资源包你会发现大多数贴图根本不是 .png也不是 .jpg而是封在自研打包格式里的 DDS、KTX甚至是一段没有文件名的裸像素数据。想改贴图、想复用旧项目的美术资产、想给某个老游戏做 Mod第一步都得先把纹理从包里解出来。TextureUnpacker-x86-64v1.0就是干这个的命令行工具扫输入目录、按纹理文件头特征识别格式、把位图数据还原成可编辑的文件。它解决的核心问题很具体解包不是解压缩。Zip 解出来可能还是 DDS你缺的是把 DDS 从容器里完整切割出来的逻辑而这个切割逻辑最怕的就是格式识别错位。v1.0 定位在 x86-64 平台优先保证大资源包环境下的识别与切割正确性适合做 Mod、做资产归档、做纹理逆向学习的人先用起来。2. 解包原理先知道贴图藏在哪里再谈怎么识别格式2.1 纹理在资源包里的三种常见形态先要搞清楚纹理藏在哪。我接触过的资源包大都是三种形态。第一种是标准容器比如 Zip、PAK、Bundle纹理像普通文件一样存在里面解包器要做的就是读出目录结构、按条目切割第二种是二进制大包几十个纹理按偏移顺序拼在一个文件里没有目录解包器得靠扫描特征来切分第三种是裸数据段连文件头都被剥掉了只有宽高和像素格式作为线索。解包器处理这三种形态的方式完全不同。第一种靠容器格式解析第二种靠魔数扫描加偏移计算第三种靠参数指定格式和尺寸后强行解码。很多解包失败不是工具不行而是你根本没告诉它资源包属于哪一种。我一般会先用十六进制工具打开资源包看前几百字节有 PK 开头的是 Zip有常见容器标识的是 Bundle全乱码就按裸数据段处理。这里还要提一个容易误判的点资源包内部可能混合多种形态。同一个包里一部分纹理以独立条目存在另一部分以连续块拼在一起。解包器如果只支持一种容器解析方式面对混合包就只能处理其中一部分这时候把它当二进制大包扫描反而能救回另一半。所以拿到资源包第一件事是确认形态而不是急着跑命令。2.2 文件头与纹理元数据解包器识别格式的真正依据不管贴图最终以什么形式存只要它还是完整的纹理文件文件头就能透露几乎所有信息。DDS 头四字节是 44 53 44 20也就是 ASCII 的 DDS 加空格KTX 开头是 AB 4B 54 58PNG 则是 89 50 4E 47。解包器识别格式不是看扩展名而是看这几个魔数。TGA 比较特殊没有固定魔数靠 18 字节头里的图像类型和色深字段判断。真正影响解包质量的是文件头里的元数据DDS 在偏移 12 和 16 的位置分别存高度和宽度偏移 84 附近是像素格式标识比如 DXT1、BC3、BC7。这几个字段决定切割后数据怎么解码。识别错一个字符后面整段像素数据都是乱的。下面的表是我常用的对照参考格式魔数尺寸位置像素格式位置主要解包难点DDSDDS (44 53 44 20)偏移 12(height)/16(width)偏移 84 附近的 FourCCmipmap 层级与压缩数据块KTXAB 4B 54 58偏移 36/40偏移 28 附近的 glInternalFormat字节序与压缩格式TGA无固定魔数18 字节头偏移 12/14偏移 2 的色深字段RLE 行压缩处理PNG89 50 4E 47偏移 16/20IHDR 内靠魔数确认基本不会错解包后多为成品少见这张表的价值在于排查解出的文件打不开先用 hexdump 对着表看文件头对不对。如果 DDS 的 FourCC 位置读出的是空字节多半是偏移算错了如果 TGA 高度读出 0多半是容器解析漏了一层头。格式识别有时候像玄学但其实每一步都有据可查只是需要你把文件头一行行读出来。2.3 为什么 x86-64 优先大包、偏移寻址与内存映射v1.0 选择只在 x86-64 平台发布不是顺手而是因为解包这类工具天然受地址空间限制。一个游戏资源包随随便便几个 GB32 位进程的虚拟地址空间上限是 4 GB想用内存映射方式把整个包映射进地址空间很容易撞上限。x86-64 下虚拟地址空间大得多可以把大文件分段映射按偏移只读需要的那部分数据。另外解包过程要计算大量的 64 位偏移。纹理在包里的位置往往超过 2 GB32 位下用 32 位整数去存偏移一旦包超过 4 GB 直接溢出即使没溢出也要到处小心符号位。x86-64 版本把偏移、长度、块大小全按 64 位处理。血泪经验告诉我这类问题在 32 位版本里是修不完的坑今天修了读取明天又在写入时炸。所以我在选型时看到工具只有 x86-64 版本通常会认为这是优点而不是缺点。它意味着工具作者已经把大文件场景放在第一位而不是先兼容老环境。你要用的场景如果是解手游小包32 位也能跑一旦面对 PC 游戏的大型资源包x86-64 是刚需。3. 首次实战用 TextureUnpacker 解出第一张贴图的最小命令3.1 运行环境与输入准备先把资源包拆到目录TextureUnpacker-x86-64v1.0的输入是目录而不是单个文件所以第一步是先把资源包解到目录。如果外层是 Zip 或 APK先解压如果是 PAK 或者 Bundle确认里面是不是加密内容未加密的话解包器可以直接扫目录。注意解包器的工作方式是扫描目录里的文件而不是直接读取外层压缩包所以外层 Zip 必须提前解开。实际操作中我一般会先建一个干净的目录结构比如 input/ 放原始包unpacked/ 放解包输出preview/ 放转换后的预览图。路径里别带空格和中文这一点在 Windows 上尤其重要命令行工具处理带空格路径需要额外转义出错后排查起来很浪费时间。把输入准备好比调工具参数更影响成功率。再补充一个习惯先放一个只含少量文件的子目录进去试跑不要一上来就扫整个大包。等确认格式识别没问题、输出文件能正常打开再全量跑。这样即使翻车也只需要在小目录里排查不会浪费一次全量解包的时间。3.2 最小命令v1.0 的命令行签名与日志怎么看准备好目录之后解第一张图出来的最小命令是这样TextureUnpacker-x86_64 -i ./input -o ./unpacked --autodetect on --debug 1命令的意思-i 指定输入目录-o 指定输出目录输出目录不存在会自动创建--autodetect on 开启格式自动识别让工具自己去扫文件头--debug 1 把日志级别调到 1能看到识别到哪些格式、从哪个偏移切出来的。Windows 下可执行文件名是 TextureUnpacker-x86_64.exe调用方式不变。跑完之后unpacked 目录里会出现按偏移命名、带格式后缀的文件比如 0000_0x0012_DXT1.dds。日志里看到 DDS found at offset 0x0012, 2048x2048, BC1 这类输出就说明识别正常。如果日志只有一行 File not found 或者全是 unrecognized先别怀疑工具回去检查输入目录是不是空的、路径是不是写对了。我一般会把 --debug 开到 1 以上跑第一遍看的是识别率而不是最终文件。第一遍解出的文件只要能打开几张说明整个流程是通的如果日志里格式名称乱七八糟说明自动识别的判定条件需要调这时候才轮到参数上场。3.3 三个高频参数autodetect、raw-offset 与 debug 级别v1.0 的命令行参数不算多但真正常用的就这几个。我把它们列成一个表方便对照参数作用典型场景注意点--autodetect on/off是否按文件头特征扫描识别格式资源包是混合内容时开 on裸数据段时关掉手动指定格式on 时扫描慢不要对大目录反复开高日志--raw-offset 字节指定从某个偏移开始当作纹理头文件被加壳或头部被削掉时偏移不对解出的图一定是花的先 hexdump 确认--debug 0-3日志详细程度第一次跑用 1定位问题用 2-3级别 3 会输出每个候选块的信息日志文件会很大--out-format dds|png|tga输出的封装格式需要给美术预览图时直接出 png转换可能有重采样要校验原尺寸这几个参数的调整顺序也有讲究。先按默认跑出第一轮把频率高的错误格式单独拎出来处理不要一上来就关掉 --autodetect 然后手动猜格式那是高级排错才做的事。--raw-offset 更是如此它需要你先确认文件头实际位置否则填一个大概值解出来的一定是花图。debug 级别只在排错时调高平时用 1 就够了。4. 解包之后怎么用批量重命名、批量转换与两套输出4.1 批量重命名把偏移命名的输出改成 宽x高_格式.dds解包器默认按偏移命名比如 0000_0x0012_DXT1.dds方便定位但不好管理。真要存档或给美术用我习惯按 宽x高_格式.dds 重命名。这个操作不需要解包器支持一个小 Python 脚本就能做import struct from pathlib import Path def rename_by_size(directory: str): out Path(directory) for f in out.glob(*.dds): with open(f, rb) as fh: header fh.read(128) # DDS 文件头固定 128 字节 if header[:4] ! bDDS : # 魔数不对直接跳过 continue # 高度在偏移 12宽度在偏移 16 height, width struct.unpack_from(II, header, 12) # FourCC 在偏移 84DXT1/BC3/BC7 都在这里 fourcc header[84:88].decode(latin1, errorsreplace) new_name out / f{width}x{height}_{fourcc}_{f.stem}.dds f.rename(new_name) if __name__ __main__: rename_by_size(./unpacked)逻辑说明先读每张 DDS 的文件头高度和宽度分别在第 12 和 16 字节格式标识在 84 字节附近拿到这三个信息后重新拼文件名宽乘高的表达方式一看就知道是 UI 图还是大贴图。参数上唯一要改的就是目录路径换成你自己的输出目录。注意只处理 .ddsPNG 和 TGA 不需要走这段。4.2 批量转 PNG给美术的预览图怎么出改完名之后下一步通常是转 PNG 给美术预览。常见做法是先尝试直接用解包器的 --out-format png 输出让解包器在切割时顺带完成封装转换如果解包器不把压缩格式转码才考虑用外部工具批量转。我一般会优先用解包器直接出 PNG少一道工具链就少一个出错环节。用外部工具时我走的是 ImageMagick 的 mogrify命令是这样magick mogrify -format png -path ./preview ./unpacked/*.ddsmogrify 会把 unpacked 下的 DDS 批量转成 PNG 放到 preview 目录原文件不动。这个命令跑得快但在某些旧版本 ImageMagick 上对 BC7 的支持不稳定转换出来的预览图可能是花的。所以我的习惯是先用解包器输出 DDS确认 DDS 头没问题最后用 mogrify 转预览一旦预览图发花直接怀疑转码器而不是源文件。转码前还有个检查动作先看解包日志里有没有格式识别警告。如果日志里大量出现 BC1但原资源明明有透明通道那就不是 ImageMagick 的问题是解包器把 BC3 误判成了 BC1。这时候调转码参数没有用必须回到解包环节重新识别。4.3 两套输出策略程序用 DDS美术用 PNG解包结果怎么用取决于给谁。给程序做集成或继续压缩处理保留 DDS 原格式最稳因为 DDS 里的压缩格式、mipmap 层级、轴序信息在转换过程中很容易丢给美术做贴图修改给 PNG 就行美术工具链对 PNG 的兼容性最好改完再导回 DDS。我一般会据此定两条输出规则。第一条解包器一律先输出 DDS不直接出 PNG因为 PNG 一旦生成原压缩信息和 mipmap 就没了想反悔只能重新解包。第二条PNG 只作为交付给美术的预览资产放到 preview 目录里和原始 DDS 分开管理。这样程序拿原始格式美术拿预览格式两边不打架。这里有一个容易忽略的点同一张贴图可能需要两套输出而解包器如果只支持一种输出格式那就先出 DDS 再转 PNG顺序不能反过来。反过来会丢失压缩信息这个没有后悔药。同理如果 DDS 里带 mipmap 链转 PNG 之前最好确认预览图用的是第几层 mip默认导出第一层大图往往不是美术想要的。5. 避坑TextureUnpacker 的 4 类高频问题与排查路径5.1 黑图与噪点格式识别对了偏移却错了现象解出的 DDS 能打开但内容全是花屏噪点RGB 通道乱成一团。原因文件头识别正确但切割数据时起点偏移差了几个字节。常见于带 mipmap 的纹理切割逻辑把 mip 头也算进了像素数据或者外层容器头长度没扣除导致整张图整体错位。解决先用 --raw-offset 微调起始位置单独对一张图反复测试。定位时用 hexdump 看纹理头实际位置比如xxd -l 32 -s 0x1a2b ./input/somefile.bin参数 -l 32 表示读 32 字节-s 0x1a2b 表示从该偏移开始读。对比读出来的内容是不是 DDS 头是的话把这个偏移填进 --raw-offset重新解一次。一般偏差在 4 到 16 字节之间调一次就能好偏差大说明容器解析逻辑根本没生效需要先解容器再解纹理。5.2 unknown format 刷屏自定义魔数与二次加密现象日志里大量输出 unknown format但包里明显有贴图。原因资源包做过二次封装纹理文件头被套了一层自定义结构或者魔数不是标准值工具内置的识别库没覆盖。这种情况在自研引擎的游戏里非常常见引擎作者通常会魔改文件头来防盗。解决先别急着放弃工具。用 hexdump 在文件里搜索 DXT1、BC7 这类 ASCII 字符串找到之后手动指定偏移和格式。如果整个文件都搜不到标准魔数基本可以确定纹理头被改写了需要先做一层预处理把自定义头剥掉。把文件后缀改成 .dds 再让工具扫是碰运气因为工具认的是文件头不是后缀遇到 DDS 这种方式基本无效。5.3 大文件解到一半进程被杀内存分配与并发设置现象解包跑到一半进程直接消失没有任何报错或者提示内存不足。原因大纹理解码时按尺寸预分配内存工具默认并发数过高时多个大纹理同时分配内存峰值直接爆掉。这类问题在解 UI 图集或超大场景贴图时尤其明显。解决先把并发调到 1确认单个大文件能正常解再把并发逐步调高找到当前机器能承受的阈值。另外一个务实做法是分批解包把一个很大的资源包按子目录拆成多份每次只解一份避免峰值叠加。x86-64 的地址空间再大物理内存也是有限的解包工具最容易挂的就是在这个环节。5.4 透明通道变黑alpha 不是丢了是被跳过了现象解出的 PNG 里原本透明的区域变成纯黑或者 alpha 全变 0。原因切割出来的数据其实是 BC3 或 BC7带 alpha 通道但输出 RGB 时工具只取了颜色通道把 alpha 跳过了。这不是数据损坏是输出选项问题重跑就能解决。解决优先用 DDS 输出DDS 会把 alpha 所在的压缩通道完整保留再在转换预览图时把 alpha 单独导出。如果输出 DDS 之后 alpha 还是黑的检查输入格式是不是 BC1BC1 本身就不带 alpha识别成 BC1 的文件源数据里可能根本没有 alpha 位。这时候要回到格式识别环节看是否把 BC3 误判成了 BC1。6. 进阶用校验脚本当门禁一键走完解包到归档6.1 用 Python 读 DDS 头做解包结果的完整性校验解包完成之后我最看重的是校验而不是数量。解包工具输出 1000 张图里混进 50 张花图肉眼很难发现但校验 DDS 头一眼就能揪出来。下面这个脚本遍历目录下所有 DDS读取宽高、格式标识并检查头四个字节是不是 DDS 魔数import struct import sys from pathlib import Path def check_dds(root: str): bad 0 for p in Path(root).rglob(*.dds): with open(p, rb) as f: h f.read(128) # DDS 头固定 128 字节 if h[:4] ! bDDS : # 魔数缺失说明切割位置不对 print(f[BAD] {p}: header magic missing) bad 1 continue height, width struct.unpack_from(II, h, 12) fourcc h[84:88].decode(latin1, errorsreplace) print(f[OK] {p.name}: {width}x{height}, {fourcc}) print(fdone, {bad} bad files) if __name__ __main__: check_dds(sys.argv[1])跑完之后看两类输出一是 BAD 文件说明解包器切出来的东西根本不是 DDS二是 fourcc 列表里有没有意外的 BC1。BC1 不带 alpha如果你记得原图有透明通道那就要回查识别环节了。6.2 把解包到归档做成一条流水线校验脚本跑通后我习惯把整套动作固定成一条流水线解包、改名、校验、转预览、归档每一步输出的目录严格分开。哪一步出问题就在哪个目录里排查不用从头再跑。这条流水线不需要复杂的编排工具用脚本按顺序调一遍就行。我现在拿到任何资源包都会先解一个子目录跑一遍校验脚本把识别率确认了再全量解包。这个习惯帮我避开了很多次批量转换后的返工也是我给别人交接资源时的标准动作每张图的格式、尺寸、来源都能说清楚。希望帮到你。本文还有配套的精品资源点击获取