简介CG提取工具是一套面向计算机图形学从业者、游戏逆向爱好者与3D美术人员的资源提取方案主要用于从游戏、动画及3D项目中导出图像序列、纹理贴图、模型与动画帧数据解决跨平台资产复用与逆向分析中的格式解析难题。压缩包共520个文件以325个txt说明文档与170个cui配置脚本为核心辅以dll动态库、exe可执行程序及loc、db、xml等辅助文件整体约5.56MB体积轻便却覆盖了kirikiri2、RealLive、Leaf等多家引擎的解析配置。目前已有4751人学习下载说明其在CG社区中具备一定参考价值。读者可从中获得多引擎资源解包思路、文件结构解析方法以及批量导出流程的实践参考适合具备一定编程基础、希望深入理解CG资源组织方式并提升资产处理效率的开发者与美术人员。1. 从一堆混杂资源里精准捞出 CG这个工具到底解决什么问题做过游戏拆包或者素材归档的人都有个体会真正让人头疼的不是找不到资源而是资源太多、太杂、命名混乱。一个典型的场景是你拿到一份打包好的资源目录里面混着音频、脚本、配置表、贴图还有大量你真正想要的 CG 视频或序列帧。手动一个个翻几百个文件下来眼睛都花了还容易漏。CG 提取工具就是冲着这个痛点来的——它不生产资源它只做一件事从混杂目录里按规则把 CG 类资源识别出来、提取出来、归好类。这类工具适合谁一是做素材整理和归档的从业者需要批量从资源包里分离出视频或图像序列二是做二次创作或技术研究的人需要快速定位 CG 文件而不想写一堆正则三是刚接触资源提取的新手想找一个能直接跑、参数看得懂、出错能排查的轻量方案。它不依赖特定引擎核心逻辑是文件特征识别加规则过滤所以通用性比较强。下面我从原理到实操把这份工具拆开讲清楚。2. CG 提取的核心逻辑特征识别与规则过滤怎么配合2.1 为什么不能只靠扩展名判断很多人第一反应是提取 CG 不就是找 .mp4、.png、.jpg 这些后缀吗实际干过就知道资源包里的文件经常被改名、加密或者去掉扩展名。常见做法是结合文件头特征magic number来判断真实类型。比如 MP4 文件头通常是00 00 00 18 66 74 79 70或00 00 00 20 66 74 79 70PNG 是89 50 4E 47。CG 提取工具一般会先读文件前若干字节匹配已知的视频和图像特征库再结合扩展名做二次确认。这样即使文件被改名成 .dat也能识别出来。另一个维度是路径和命名规则。很多项目会把 CG 放在特定目录下比如movie/、cg/、cutscene/或者文件名里带op、ed、cg_这类前缀。工具会把这些规则做成可配置的权重综合打分。单一规则容易误判多规则加权才能把准确率拉上来。2.2 提取流程的四个阶段一个完整的提取流程通常分四步扫描、识别、过滤、导出。扫描阶段遍历目标目录收集文件路径、大小、扩展名、前 16 字节等元信息。识别阶段用特征库匹配真实类型同时记录匹配到的规则。过滤阶段根据用户配置的规则比如只要视频、只要大于 1MB、只要路径包含 cg做筛选。导出阶段把选中的文件复制或移动到输出目录并按类型或来源分文件夹。下面是一个简化的 Python 实现展示核心识别逻辑import os import shutil # 常见 CG 文件头特征十六进制 MAGIC_SIGNATURES { b\x00\x00\x00\x18ftyp: mp4, b\x00\x00\x00\x20ftyp: mp4, b\x89PNG\r\n\x1a\n: png, b\xff\xd8\xff: jpg, bRIFF: avi, # 需进一步判断 } def detect_type(filepath): 读取文件头返回推测的类型 with open(filepath, rb) as f: header f.read(16) for sig, ftype in MAGIC_SIGNATURES.items(): if header.startswith(sig): return ftype return None def extract_cg(src_dir, dst_dir, min_size1024*100): 扫描目录提取疑似 CG 文件 os.makedirs(dst_dir, exist_okTrue) count 0 for root, _, files in os.walk(src_dir): for name in files: path os.path.join(root, name) # 跳过过小文件减少噪音 if os.path.getsize(path) min_size: continue ftype detect_type(path) if ftype in (mp4, png, jpg): # 按类型分目录存放 sub os.path.join(dst_dir, ftype) os.makedirs(sub, exist_okTrue) shutil.copy2(path, os.path.join(sub, name)) count 1 print(f提取完成共 {count} 个文件)这段代码里MAGIC_SIGNATURES是特征库detect_type负责读文件头做匹配extract_cg遍历目录并按类型导出。min_size参数用来过滤掉图标、缩略图这类小文件默认 100KB实际用的时候可以根据资源规模调整。注意RIFF开头的文件可能是 AVI 也可能是 WAV需要再读后续字节判断这里简化处理了。2.3 规则配置的粒度控制工具好不好用很大程度上看规则配置够不够细。我一般会把规则分成三类包含规则、排除规则、大小规则。包含规则比如path contains cg或type in [mp4, png]排除规则比如name contains icon或path contains ui/大小规则比如size 500KB。三类规则按优先级依次执行先包含再排除最后卡大小。这样既能捞得全又能把明显不是 CG 的东西挡在外面。配置建议用外部文件JSON 或 YAML管理不要硬编码在脚本里。改规则不用动代码也方便不同项目复用。下面是一个 JSON 配置示例{ include: { path_keywords: [cg, movie, cutscene, op, ed], types: [mp4, png, jpg] }, exclude: { name_keywords: [icon, thumb, logo], path_keywords: [ui/, font/, config/] }, size: { min_bytes: 102400, max_bytes: 524288000 } }include里的path_keywords是路径包含匹配只要路径里出现任意一个词就纳入候选。exclude优先级更高命中就跳过。size用来卡上下限上限一般设 500MB 左右防止把超大资源包误当 CG 导出来。这套配置跑一遍基本能把大部分项目里的 CG 捞干净。3. 动手跑一遍从安装到批量导出的完整步骤3.1 环境准备与依赖安装这份工具的核心逻辑用 Python 就能实现不需要额外装重型库。推荐 Python 3.8 以上标准库的os、shutil、json足够覆盖大部分场景。如果你需要处理更多格式比如识别 WebP 或 AVIF可以装pillow做辅助判断。安装命令很简单# 创建虚拟环境可选但推荐 python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate # 安装可选依赖 pip install pillow虚拟环境不是必须的但如果你机器上同时跑多个项目隔离一下能避免版本冲突。pillow只在需要深度识别图像格式时用到纯靠文件头匹配的话可以不装。3.2 配置文件的编写与参数说明把上一节的 JSON 配置保存为cg_rules.json放在脚本同目录。几个关键参数需要根据实际情况调参数作用建议值注意事项path_keywords路径包含匹配cg/movie/cutscene词太短容易误判比如 op 会命中 optionstypes文件类型白名单mp4/png/jpg按项目实际格式增减min_bytes最小文件大小100KB太小会捞进图标太大会漏掉短 CGmax_bytes最大文件大小500MB防止把整包资源当单个文件导出path_keywords里的词建议用完整单词或带分隔符的形式比如cg_、/cg/避免op这种短词误伤。如果项目里 CG 命名没有规律可以先用工具跑一遍全量扫描看看识别结果再调规则。3.3 执行提取与结果验证脚本入口加一个命令行参数解析方便指定源目录和输出目录import argparse import json def load_rules(path): with open(path, r, encodingutf-8) as f: return json.load(f) def match_rules(filepath, ftype, rules): 按规则判断是否提取 path_lower filepath.lower() name_lower os.path.basename(filepath).lower() # 排除规则优先 for kw in rules[exclude].get(name_keywords, []): if kw in name_lower: return False for kw in rules[exclude].get(path_keywords, []): if kw in path_lower: return False # 包含规则 included False for kw in rules[include].get(path_keywords, []): if kw in path_lower: included True break if not included and ftype not in rules[include].get(types, []): return False # 大小规则 size os.path.getsize(filepath) if size rules[size][min_bytes] or size rules[size][max_bytes]: return False return True if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--src, requiredTrue, help源目录) parser.add_argument(--dst, requiredTrue, help输出目录) parser.add_argument(--rules, defaultcg_rules.json, help规则文件) args parser.parse_args() rules load_rules(args.rules) # 后续调用 extract_cg 并传入 rules跑的时候命令是python extract.py --src ./game_assets --dst ./cg_output --rules cg_rules.json执行完检查cg_output目录里面应该按mp4/、png/、jpg/分好了。如果发现漏提取先看规则里的path_keywords是不是没覆盖到如果提取多了检查exclude是不是写得太窄。验证阶段建议抽几个文件用播放器或图片查看器打开确认不是损坏文件。4. 避坑指南CG 提取中常见的五个翻车点4.1 文件头匹配误判把音频当视频导出来现象输出目录里混进了 .wav 或 .ogg 文件明明规则里只写了 mp4。原因某些容器格式的文件头特征重叠比如 RIFF 开头的既可能是 AVI 也可能是 WAV只匹配前四个字节就会误判。解决对 RIFF 这类模糊特征继续往后读 8 个字节判断是AVI还是WAVE。代码里加一层二次确认别偷懒。4.2 路径关键词太短命中无关目录现象规则里写了op结果把options/、open_world/里的文件全捞进来了。原因短词做包含匹配时边界不清晰。解决改成带分隔符的形式比如/op/、op_或者用正则加单词边界\bop\b。我一般会先跑一遍 dry-run把命中路径打印出来看一眼再正式导。4.3 大文件复制到一半中断输出目录残留半成品现象提取过程中程序报错退出输出目录里有个不完整的文件下次跑又重复复制。原因shutil.copy2不是原子操作中断后会留下部分数据。解决先复制到临时目录成功后再os.rename到目标位置。或者加一个.tmp后缀复制完再改回来。这样即使中断也不会污染正式输出。4.4 符号链接导致无限递归现象扫描目录时程序卡死或报递归深度超限。原因源目录里有指向父目录的符号链接os.walk默认会跟进去。解决os.walk加参数followlinksFalse或者手动判断os.path.islink跳过。这个坑在 Linux 环境下特别常见Windows 的快捷方式一般不会触发。4.5 编码问题导致中文路径报错现象Windows 上跑脚本遇到中文目录名抛UnicodeDecodeError。原因Python 在某些环境下默认编码不是 UTF-8。解决在脚本开头加import sys; sys.setdefaultencoding(utf-8)Python 2 遗留写法Python 3 里更稳妥的做法是所有文件操作显式指定encodingutf-8路径用pathlib.Path处理。我习惯在open和json.load里都带上编码参数省得后面排查。5. 进阶技巧用哈希去重和增量提取把效率拉满规则跑通之后下一步要解决的是重复提取和全量扫描太慢的问题。我一般会加两个机制哈希去重和增量记录。哈希去重是对每个候选文件算 MD5 或 xxHash存到一个集合里遇到相同哈希就跳过。这样即使同一份 CG 在多个目录里出现也只导出一份。xxHash 比 MD5 快很多适合大文件场景。import hashlib def file_hash(filepath, chunk_size8192): 计算文件 MD5分块读取避免大文件占内存 h hashlib.md5() with open(filepath, rb) as f: while True: chunk f.read(chunk_size) if not chunk: break h.update(chunk) return h.hexdigest() # 在提取循环里维护一个 seen_hashes 集合 seen_hashes set() # ... fh file_hash(path) if fh in seen_hashes: continue seen_hashes.add(fh)增量提取则是把已处理文件的路径和修改时间记到一个 JSON 文件里下次跑的时候先加载跳过没变化的文件。这样第二次扫描能快好几倍尤其适合资源目录很大、只更新了少量文件的场景。记录格式大概是这样{ processed: { /assets/cg/op.mp4: {mtime: 1690000000, hash: abc123...}, /assets/cg/ed.png: {mtime: 1690000100, hash: def456...} } }每次跑完把新的记录写回去下次对比mtime和hash一致就跳过。注意mtime在某些文件系统上精度不够最好结合size一起判断。这套机制加上去之后我处理几十 GB 的资源目录基本几分钟就能跑完一轮。还有一个实用技巧是输出报告。提取结束后生成一个 CSV记录每个文件的源路径、目标路径、类型、大小、哈希方便后续核对和回溯。报告里再统计一下各类型的数量和总大小一眼就能看出这次提取有没有异常。从那以后我每次跑提取都强制走一遍哈希去重和报告生成再也没出现过重复导出或者漏文件的情况。希望帮到你。本文还有配套的精品资源点击获取