简介：GARbro-v1.5.44.2904 是一款面向游戏汉化组、MOD制作者与资源解包玩家的专业工具，支持npk、DAT、npa、NSA、RPA等多达五十余种游戏压缩封包格式，既可创建和提取各类封包，也能直观查看和修改压缩包内文件，并可将电脑上无法播放的音频、图片等多媒体资源提取转换为常见格式，解决了多类游戏资源难以直接访问的痛点。包内共56个文件，以35个dll动态库作为核心运行组件，配合10个lst列表文件对应不同封包解析规则，另有dat数据文件、config配置文件、txt说明文档及GUI主程序exe，整体仅9.22MB，解压后即可运行。已有1400人学习/下载。资源附带多语言界面与README文档，启动GARbro.GUI.exe后通过图形化操作即可完成浏览、提取与转换，无需编写命令。无论新手还是进阶用户，都可以借助内置的格式列表快速定位所需功能，适合用于游戏素材提取、汉化文本修改及MOD制作等实践。
1. 为什么拆这个包：npk 提取、DAT 提取、NPA/NPK、fullyt1r、RPA 卡住的都不只是新手
拿到一批pack.npk和pack.npa文件时，我第一个反应是用解压软件硬开，结果只得到一堆乱码文件名，连图片头都扫不出来。后来才发现，这类文件根本不是标准压缩包，而是游戏引擎自定义的归档格式；DAT 更离谱，同一个扩展名在不同引擎里可能是图片包、音频包、脚本包，也可能是加密索引。GARbro 这个工具解决的就是这件事：它把归档识别、内部预览、多媒体转换集中到一个界面里，覆盖 KiriKiri 系的 NPA/NPK、Ren'Py 系的 RPA、各类 DAT 和 fullyt1r 相关的加密变体，适合游戏汉化、CG 整理、资源逆向复用的人直接用。这篇笔记不讲虚的，只讲怎么打开、提取、转换、避坑。
2. 认准工具的底细再动手：目录结构、启动方式与格式匹配机制
2.1 先别急着双击 exe：目录里每个文件都在干不同的活
解压这份包之后，第一眼会被一堆 DLL 和 LST 文件吓到，但真正决定 GARbro 能不能认出某种格式的，不是GARbro.GUI.exe本身，而是它旁边那套格式描述文件。我一般会先把目录结构捋一遍，确认「壳」和「核」没被拆散。
从文件清单里能直接看出四个关键部件：
| 文件 | 职责 | 常见坑 |
|---|---|---|
GARbro.GUI.exe | 主界面程序，负责文件浏览、预览、导出交互 | 单独替换 exe 不会让工具变强，它不带格式解析能力 |
GameRes.dll | 核心解析库，所有格式的解包逻辑都在这里 | 与ArcFormats.dll版本不一致会导致部分格式识别失败 |
ArcFormats.dll | 格式适配器容器，按需加载各类归档格式实现 | 删除或改名后，工具立刻退回「裸数据」状态 |
Formats.dat | 格式注册表，记录签名、偏移、掩码等识别参数 | 升级工具时必须连同它一起替换，否则新版 dll 配旧注册表会翻车 |
各类.lst | 引擎专属的文件列表，比如necopack.lst、kirikiri_bracon.lst | 某些私用格式要依赖.lst里的映射信息才能还原内部文件名 |
README.txt里通常写明了运行环境和命令行入口，建议先花五分钟读一遍，不用跳着来。我见过有人把Formats.dat当成缓存文件删掉，结果整个工具只能当十六进制查看器用，这类问题不是 bug，是目录结构被破坏。
2.2 打开 NPK / NPA / RPA：如果连「打开文件」这一步都走错，后面全是白费
GARbro 的打开逻辑和普通压缩软件不太一样，它不是根据扩展名硬猜，而是先读文件头，再拿Formats.dat里的签名表去匹配。所以同一个.npk文件，只要内部结构属于 KiriKiri 系，工具就会自动识别；匹配失败时，它会把文件当作原始二进制流显示。
标准流程分三步：
- 双击
GARbro.GUI.exe启动主界面。 - 点击
File → Open，选择目标.npk或.npa文件。 - 在左侧目录树里逐层展开，右侧会自动显示内部文件列表。
这里有个很容易忽略的动作：直接把文件拖进窗口也能打开，而且比 Open 更快。内部文件的可视化在业界普遍是「支持预览」的，但我一般会再补一步：双击具体的图片文件，确认预览区能正常渲染，再开始批量导出，避免后面提取完才发现掩码没对上、图片全是噪点。
对于 RPA 文件，同一套打开流程同样适用，因为 GARbro 会把 Ren'Py 归档当作另一种可识别容器处理。打开后如果看到.rpyc这类脚本文件，预览区多半是乱码，这属于正常现象，脚本内容要单独走反编译流程，后面第 3 章会专门展开。
2.3 命令行调用：先把帮助读出来，再拼批处理参数
手头这批文件多了之后，逐个用 GUI 点开显然不现实。GARbro 支持命令行调用，方便把提取动作固化到批处理里。但不同版本对参数的命名有差异，我的习惯是先读帮助，再写参数，避免靠记忆背错了提取目录。
# 1. 先输出当前版本的命令行帮助，确认可用参数名 .\GARbro.GUI.exe -h | Out-File -Encoding utf8 cli_help.txt # 2. 打开帮助文本，确认提取、列表、输出目录参数的具体写法 Get-Content cli_help.txt这段代码的逻辑是：把命令行帮助落盘到本地文本，然后再读取，目的是让后面要写的批量脚本有据可依，而不是拍脑袋猜参数。如果你拿到的版本支持-extract <infile> <outdir>这类写法，批量提取一个 NPK 包的命令就是两步：
$gar = ".\GARbro.GUI.exe" $pkg = "F:\assets\pack.npk" & $gar -extract $pkg "F:\assets\out"$gar是主程序路径，$pkg是包文件路径，最后一个参数是输出目录。执行时注意输出目录不要放在包文件同级目录下，免得提取结果和原始包混在一起，后面整理素材的时候很难分清哪些是源文件、哪些是产物。
2.4 转换多媒体：把引擎私有格式转成通用格式再进工作流
很多包内图片用的是带自定义调色板的格式，PS 直接打不开；音频则可能是带 loop 点的 OGG 变体，播放器识别不了。GARbro 的转换能力就是用来处理这种情况的。
操作路径是：选中内部文件，右键Convert，再选目标格式。图片这边我一般转成png，因为它是无损格式，适合后续进修图工具；音频转成wav或标准ogg，视后续处理需求而定。下面这张表是我常用的转换方案：
| 源类型 | 推荐输出 | 理由 |
|---|---|---|
带签名头的位图（.gr等） | png | 无损、图层信息完整保留、通用性强 |
| 普通索引图 | png或bmp | 避免二次压缩导致文字边缘发虚 |
| 带 loop 点的音频 | 标准ogg | 保留循环信息，适合游戏替换场景 |
| 多轨 BGM | wav | 方便在音频编辑器里分轨处理 |
转换时注意：不要直接在原列表里覆盖保存，输出目录单独建一个converted文件夹，后续做资源回写时，这份转换产物还能当备份用。转换失败的条目通常会留在列表里不动，不会报错打断流程，所以每次转换完要多看一眼右侧状态。
3. DAT 提取与 fullyt1r / RPA 场景：先识别再动手
3.1 DAT 文件：先认引擎，再谈提取
DAT 是这套工具里最容易让人误判的类型。同一个.dat，在不同引擎里可能是图片打包、音频归档、配置文件集合，也可能是带索引的加密容器。GARbro 的处理逻辑不是靠扩展名，而是靠文件头签名和目录配套文件共同判断。
从项目正文的文件列表看，典型配套结构是NCFileMap.dat + NCFileMap.idx，这类成对出现的文件说明引擎把文件索引单独拆了出来。遇到这种情况，索引文件必须和 DAT 放在同一目录，且不能随意改名。GARbro 读取 DAT 时，会先尝试加载同名.idx，如果索引缺失或文件名对不上，工具只能按签名识别出一小部分文件，其余内容会以裸数据形式呈现，提取出来的图片大概率是花屏。
DAT 提取的完整落地步骤：
- 把
.dat和同目录下的.idx、.lst放在一起，确认文件名前缀一致。 - 打开 GARbro，拖拽
.dat到主窗口。 - 在左侧目录树里查看是否出现了「可识别的文件结构」，而不是单一的二进制块。
- 右键根节点，选择导出整个容器到独立目录。
如果第 3 步发现工具只识别出一个孤零零的文件，先别急着提取，回退检查索引文件。一些引擎会把索引信息直接嵌在 DAT 末尾，工具也能识别，但这种情况下 DAT 文件体积通常异常大，打开时会明显卡顿一下。
3.2 fullyt1r 标识：KiriKiri 系加密包的识别特征
fullyt1r在 KiriKiri 引擎资源里常见于带加密掩码的运行时标识，它直接影响 NPA/NPK 包内文件的读取方式。遇到这类包时，GARbro 会走一段专门的掩码处理分支，代码上通常表现为对文件头做 XOR 后再解析内部条目。
实操层面的表现是：打开带 fullyt1r 特征的 .npk 文件时，状态栏会出现对应的引擎标识，此时左侧文件列表里的文件名往往是一串哈希值或短编号，因为原始文件名写在加密区。这种包直接全部导出当然可以，但文件名会丢。
我的处理方式是多做一步「重命名映射」：先把包内所有文件导出到一个临时目录，再从Formats.dat或同目录.lst里找回原始文件名，最后按映射批量重命名。这一步看着麻烦，但能保住素材的语义信息，后面整理 CG 时省非常多时间。
这里要提一个重要边界：fullyt1r 只是标识，不是完整加密方案。GARbro 能识别并提取不代表能还原所有带该标识的变体，如果包内文件导出后全是相同字节的重复数据，说明掩码版本较新且未在格式注册表里登记，只能等工具版本更新或手动补掩码。
3.3 RPA 包：Ren'Py 系归 Ren'Py，别拿 KiriKiri 流程硬套
RPA 是 Ren'Py 归档，头部会带RPA-版本号，常见有RPA-2.0、RPA-3.0等。GARbro 打开 RPA 没有任何问题，关键是提取之后的内容处理逻辑和 NPA/NPK 完全不同。
对比一下这三类容器的处理差异：
| 容器类型 | 引擎归属 | 内部常见内容 | 提取后重点 |
|---|---|---|---|
.npk | KiriKiri 系 | 图片、音频、脚本 | 注意掩码保护和文件名映射 |
.npa | KiriKiri 系 | 数据文件、存档相关 | 依赖.idx索引，目录完整性敏感 |
.rpa | Ren'Py 系 | .rpy、.rpyc、图片、音频 | 脚本需要额外反编译，归档本身不负责 |
RPA 里的.rpyc文件提取出来后，GARbro 的任务就结束了。.rpyc是编译后的字节码，需要按对应的 Ren'Py 版本找运行时反编译成.rpy源码。这里最容易出现的误解是「RPA 提取完 = 脚本可读」，实际远不是这样。我的建议是：提取完先按RPA-版本号建个目录，把脚本文件单独放一处，后续反编译时就不会和图片素材混在一起。
3.4 完整工作站流程：把识别、提取、归档一次跑完
用到真实项目里，我不会手动一个个点，而是写一个批处理脚本把目录下所有目标容器扫一遍，再交给 GARbro 批量提取。这段 PowerShell 是可抄作业的：
$gar = ".\GARbro.GUI.exe" $root = "F:\game_assets" $outRoot = "F:\extracted" Get-ChildItem -Path $root -Recurse -Include *.npk, *.npa, *.dat, *.rpa | ForEach-Object { $name = $_.BaseName $dest = Join-Path $outRoot $name New-Item -ItemType Directory -Path $dest -Force | Out-Null & $gar -extract $_.FullName $dest }这段脚本的逻辑是：递归扫描根目录下所有npk/npa/dat/rpa文件，对每个文件单独建输出目录，再调用主程序提取。-extract后面第一个参数是输入文件绝对路径，第二个参数是输出目录。如果当前版本的参数名不同，按 2.3 的方式先跑一次帮助再改成实际签名。批处理跑完后，记得检查目录数量是否和源包数量一致，多目录或空目录通常说明某个容器没有被正确识别。
4. 避坑与常见问题：版本、路径、掩码、加密变体
4.1 打开 .npk 报 unsupported format 或直接识别失败
现象：同一份 .npk 在别人电脑上能正常打开，自己这边打开后只显示一个二进制块，或者直接弹 unsupported format。
原因：GARbro 对格式的识别依赖Formats.dat和ArcFormats.dll的版本匹配。游戏新变体的加密标识没进旧注册表时，工具只能按裸数据处理。你单把GARbro.GUI.exe换成新版没用，格式描述文件不配套，识别逻辑还是走老的。
解决：整套工具目录一起升级，重点核对Formats.dat和ArcFormats.dll的修改时间是否与其他核心文件一致。我在某实战项目中遇到过类似问题，后来把整个目录重新解压覆盖，问题当场消失。从那次以后，我每次升级都整包替换，绝不只换单文件。
4.2 中文路径 / 带空格的目录导致崩溃或导出中断
现象：打开文件正常，但批处理提取到一半窗口消失，或导出时提示找不到路径；人工用 GUI 操作时，某些深层目录里的文件无法预览。
原因：工具对非 ASCII 路径的处理存在边界问题，中文路径、特殊符号路径会在内部文件表映射时产生偏移错误，尤其是带.lst的引擎包更明显。
解决：把游戏本体整个复制到一个纯英文短路径下再提取，例如D:\work\pkg，不要放在桌面带中文用户的路径里。输出目录同样保持英文。这条是血泪经验，极其廉价但极其有效。
4.3 DAT 文件提取出的图片全是黑屏或噪点
现象：DAT 能打开，文件列表也列出了图片，但预览是花的，导出后图片无法正常显示。
原因：DAT 容器内的图片通常做了掩码处理或依赖同目录索引文件；索引缺失时，GARbro 虽然能扫到文件边界，但没法正确还原调色板和像素排列。
解决：检查同目录是否存在.idx和.lst，确认它们和 DAT 文件同名。我一般会在提取前先对照目录文件列表，确认配套索引齐全，再执行导出。如果确认齐全但图片仍花，进而验证这个 DAT 是不是变种加密；这种情况只能等工具更新，短期内先把裸数据留档，不用反复试。
4.4 RPA 提取出的 .rpyc 反编译失败或版本不匹配
现象：从 RPA 里提出来一堆.rpyc文件，拿反编译工具去还原.rpy源码时报错。
原因：RPA 是归档容器，不负责脚本反编译；.rpyc的字节码版本必须和 Ren'Py 运行时版本对齐，版本差一点都会翻车。
解决：先看 RPA 头部版本号，再去匹配对应版本的 Ren'Py 环境。要记住，GARbro 只完成「把脚本从包里掏出来」这一步，反编译是另一个环节的事，不要指望一个工具做完所有事。
4.5 大文件提取到一半跳出一堆 skip
现象：批量提取一个体积很大的容器时，日志里出现大量 skipped files，但包本身没有显示损坏。
原因：文件表被截断，或包内个别条目数据长度与表头不一致。这类情况多发生在这个源包在打包过程中出错，而不是工具 bug。
解决：先把提取日志导出，按 skip 状态过滤出失败清单，再检查这些文件在包内的偏移是不是连续的。我一般会对照失败清单里的文件数量来判断这是小概率损坏还是整体损坏；如果是零星几条，直接忽略继续用；如果大量失败，说明包已损坏，重下源文件比反复提取更省时间。
5. 进阶：把提取流程固化成一个可重复执行的归档流程
前几章解决的是「怎么打开、怎么提出来」，这一章说一个我自己沉淀下来的习惯：每次接到新资源包，先建一张格式检查表，而不是直接开提。
第一步是打开项目包里的supported.html，它是这个版本里记录格式覆盖范围的说明页面。我会先确认目标格式是否落在支持列表里，如果落在列表里再动手；如果不在，先查引擎变体信息，判断是自己补参数还是等版本更新。这一步能省掉大量无效尝试。
第二步是提取后的完整性校验，我用一段很短的 PowerShell 检查输出目录里有没有 0 字节文件：
Get-ChildItem "F:\extracted" -Recurse -File | Where-Object { $_.Length -eq 0 } | Select-Object FullName这段脚本会把所有空文件路径列出来。出现 0 字节文件时，基本可以断定对应的包内条目在解包时没读到数据，根据文件数量决定补提取还是放弃。没有空文件时再核对总数，一般 GUI 统计栏会有包内文件总数，提取出的文件数要和它一致才宣布收工。
第三步是把取证结果写进批处理日志。我会让脚本在每次提取完自动生成一个 CSV 清单，记录包名、提取时间、文件数、失败数，这样后续再有人用同一份资源时，不用重复踩坑。
说一个真实的教训：我一度以为提取完就万事大吉，结果在某个项目 X 里发现部分音频少了 loop 点信息，导致游戏替换后音乐循环时明显断裂。从那以后，我每次提取完都会强制走一遍「格式覆盖核对 → 空文件检查 → 输出清单留档」这三步，再进入转换工作流。希望这段流程能帮到你，也希望能少走一次我当时的弯路。
本文还有配套的精品资源，点击获取
