简介arc_conv_r55 是一款面向开发者和数据管理员的 arc 格式压缩包专用解包与转换工具集成解包、打包、格式转换及文件清理等模块适合需要批量处理自定义压缩包的场景。包内共 415 个文件以 330 个 asm 汇编源码为主另有 c/h 源码与头文件、bat 构建脚本、inc 包含文件以及可直接运行的 exe、lib、dll 等二进制组件整体仅 2.38MB结构紧凑便于离线使用。工具自带 build.bat 与 clean.bat可自动完成编译构建和中间文件清理text_conv 负责文本编码转换arc_mod、arc_conv、arc_pack 分别承担格式扩展、转换与打包职责include 目录提供完整头文件方便二次开发。从内容预览可见汇编源码对多种 arc 变体的解包与加密逻辑均有覆盖适合深挖容器格式的读者作静态分析。已有 4523 人学习下载适合解析或生成 arc 格式资源、希望理解其内部结构的软件开发者与数据管理爱好者。1. arc_conv_r55 到底是什么一条命令把游戏素材从 .arc 里捞出来做过视觉小说汉化、画集整理或者老游戏 mod 的人大概率都遇到过同一个场景游戏目录里躺着一堆几百 MB 的 .arc 文件后缀看着像压缩包但 WinRAR 打不开图片查看器更认不出来素材全部封死在里面。arc_conv_r55 就是专门解决这个问题的命令行解包转换工具它的核心作用是把这类资源容器里的图片批量导出成 BMP 或 PNG让素材回到你能直接用的状态。这个标题里的 r55 指的是某个迭代版本号社区里这类小工具更新很快不同版本对加密变体和图像编码的支持差异不小。本文要解决的是四件事它到底能解什么、完整命令怎么写、解出来的图不对时怎么修、哪些地方最容易踩坑。适合手里已经攒了一批 .arc 文件但无从下手的人也适合想把这套解包流程接进批量素材管线的开发者。2. 先分清 ARC 的几种变体r55 能解哪一类不能解哪一类2.1 ARC 不是一种格式是一族格式把 .arc 当成单一格式是新手最容易犯的错。游戏开发社区里很多引擎为了省事直接把资源打包逻辑命名为 arc导致你拿到的 .arc 文件头、压缩算法、加密方式完全对不上。刚接触时我吃过这个亏拿一个引擎的 arc_conv 去解另一个引擎的包结果自然是解出一堆乱码文件。从实际表现看常见的 ARC 变体大致分三类变体类型典型特征解包难度纯打包型文件头有明确的文件表资源未压缩或仅 zlib 压缩最低直接遍历即可加密型文件头被改写过资源字节做过 XOR 或异或偏移中等需要密钥或算法匹配分块索引型资源按块存储索引表在文件尾部或单独脚本里较高需要先解析索引判断一个 .arc 属于哪类不需要先跑工具。用十六进制查看器打开文件看前 32 字节纯打包型的头部通常有可读的 ASCII 字符串比如文件名列表、版本号标记加密型的头部则往往是一堆没有规律的高位字节。另外看同目录有没有配套的 .tjs、.ks 或 .dat 脚本文件很多引擎会把资源索引放在这些外部文件里只给 arc_conv 传主包是不够的。2.2 r55 版本的行为差异先看 -h 再动手arc_conv_r55 这类命令行工具有一个特点作者更新版本时经常微调参数名。某个小版本里叫-o的参数到下个版本可能改成--outdir或者反过来。所以我拿到一个新版本的第一件事永远是先跑一次不带任何参数的裸命令把帮助信息打出来。arc_conv_r55.exe正常情况下这种没有参数的调用会触发帮助文本输出列出当前版本支持的模式、参数名和示例。输出可能有好几屏别嫌长直接把它重定向到文件里后面查参数时对着看arc_conv_r55.exe help.txt 21参数说明 help.txt是把标准输出写入当前目录的 help.txt 文件21表示同时把标准错误也合并进同一个文件。为什么要这样因为多数 Windows 命令行工具在参数缺失时走的是 stderr只重定向 stdout 会漏掉内容。从 r55 的帮助文本看这个版本的核心改进集中在三点对带 Alpha 通道 BMP 的支持更稳、修复了部分加密变体的解包失败、增加了输出目录自动创建逻辑。如果你手里的版本号更高或更低这三点仍然值得关注但参数名要以你自己的-h输出为准不要盲抄网上的旧命令。2.3 引擎识别与格式映射从游戏目录反推工具链如果拿到一个 .arc 文件不确定手上的 arc_conv_r55 能不能解我的习惯是先看游戏根目录结构。不同的引擎有不同的外围特征这些特征比文件头更容易判断目录下有大量 .ks 或 .txt 脚本文件说明是脚本驱动型引擎arc 里的资源多半是纯打包加轻加密。目录下有 .exe 或 .dll 名称带引擎缩写直接搜这个引擎名加上 arc extract 关键词往往能找到对口的变体支持说明。资源文件按数字序号命名比如 00000.arc、00001.arc说明这是分卷打包arc_conv_r55 能逐个解但批量脚本要考虑序号补零问题。我一般会先用-m list这类列表模式跑一遍只列出包内文件而不实际导出确认工具能正确解析文件表再正式解包。列表模式如果报错就说明这个包的变体不在 r55 的支持范围内不用再往后折腾了。3. arc_conv_r55 解包实战最小命令、参数拆解与批量脚本3.1 最小命令一条命令解出全部素材先给一个能跑通的最小命令。假设你有一个游戏目录D:\GameData里面的script.arc放的是脚本和图片资源你想把素材全部解到extracted目录下arc_conv_r55.exe -m unpack -o ./extracted ./script.arc逻辑说明-m unpack是显式指定解包模式-o ./extracted是输出目录最后的./script.arc是输入文件。r55 版本会自动创建extracted目录不需要预先手动建。参数说明如果你看到输出里出现一条条extract: file_001.bmp这样的日志说明解包正常如果直接闪退或没有任何输出先退回上一节的做法把帮助信息重定向出来核对当前版本认不认unpack这个模式名。3.2 关键参数逐个拆解模式、输出与过滤条件arc_conv_r55 的参数不算多但每个都有坑。把最常用的几个拆开讲参数作用常见坑-m unpack/-m list指定运行模式实际解包或仅列文件清单模式名小版本间会改务必先看帮助-o 目录输出目录路径含中文时可能乱码建议先用纯英文路径-outfile 文件指定导出清单到一个文本文件部分版本要求文件后缀必须是 .txt-pfs启用 PFS 格式兼容模式仅对特定引擎的包有效乱开反而解不出来-enc 编码强制指定文件名编码老游戏默认 Shift-JIS需要转 UTF-8 时用这个编码参数值得单独说。很多老游戏的 .arc 内部文件名是 Shift-JIS 编码而现代 Windows 终端默认是 UTF-8 或 GBK解出来的文件名会变成乱码。r55 版本确实支持指定编码但具体的取值写法需要通过-h确认。我一般这样处理arc_conv_r55.exe -m unpack -o ./out -enc sjis ./script.arc参数说明-enc sjis是告诉工具按 Shift-JIS 解释内部文件名这样解出来后是正常的日文或中文名。如果你不确定原包的编码可以先用-m list看文件表如果列表里显示的就是乱码再试-enc的不同取值。这个参数是我认为 r55 版本最值得优先测的一个因为文件名乱码会直接影响后续素材归类。3.3 批量处理遍历多个 .arc 的脚本写法游戏资源往往不只一个 arc 文件动画、立绘、地图、音效可能分别打包。手写十几条命令太蠢写个批量脚本才是正路。在 Windows 下我用批处理在 Linux 或 macOS 下我用 shell思路一样#!/bin/bash for arc_file in ./arcs/*.arc; do base_name$(basename $arc_file .arc) mkdir -p ./out_${base_name} arc_conv_r55.exe -m unpack -o ./out_${base_name} $arc_file if [ $? -eq 0 ]; then echo OK: $arc_file - out_${base_name} else echo FAIL: $arc_file fi done逻辑说明遍历arcs目录下所有.arc文件每个文件单独建一个输出目录。$?是上一条命令的退出码为 0 表示成功非 0 表示解包失败脚本会把失败的文件名打印出来方便排查。参数说明basename $arc_file .arc是去掉扩展名只保留文件名主体比如script.arc变成script。这样输出目录就是out_script不会混在一起。这个脚本在 Windows 下用 Git Bash 或 WSL 跑都行如果用原生 cmd语法要改成for %%f in (arcs\*.arc) do ...。批量跑的时候建议先拿一个包测试通过再全量跑否则一个参数错误会浪费大量时间。4. 解出来的图是坏的Alpha、调色板与画面偏移的三处修正4.1 透明通道丢失BMP 的 Alpha 单独成文件arc_conv_r55 解包生成的图片很多情况是带 Alpha 通道的 BMP或者更麻烦——Alpha 会被单独导出一个同名文件。如果你把解出来的图直接贴进游戏模组或画集里会发现本该透明的背景变成纯黑或纯白这就是 Alpha 没合回去。常见的表现是目录里出现xxx.bmp和xxx_alpha.bmp两个文件后者就是前者的透明蒙版。修正思路是用 Python 的 Pillow 库把两者合成一张带透明通道的 PNGfrom PIL import Image base Image.open(xxx.bmp).convert(RGBA) alpha Image.open(xxx_alpha.bmp).convert(L) base.putalpha(alpha) base.save(xxx.png)逻辑说明先把原图转成 RGBA 模式再把_alpha.bmp作为蒙版填入 Alpha 通道最后存成 PNG。这样透明部分就正确了。参数说明convert(L)是转成灰度模式因为 Alpha 蒙版本质上就是单通道亮度图白色代表不透明、黑色代表完全透明。如果你的_alpha.bmp是白色背景黑色物体的反相蒙版需要先ImageOps.invert再合否则透明区域会反过来。这个坑我踩过一次合出来的立绘像是被挖空了。4.2 调色板错位画面发绿发紫的排查思路另一个高频问题是解出来的图颜色完全不对人脸发绿、背景发紫。出现这种情况九成原因不是 arc_conv_r55 解包错了而是图片本身是索引色 BMP工具按 8 位调色板导出但原始数据其实是 4 位或带特殊调色板标志。排查手法很直接用十六进制查看器打开 BMP 头部看biBitCount字段的值。如果是0x04就是 4 位索引色0x08是 8 位。如果这个值和文件内容不匹配说明工具在解析时读错了位深。修正办法是用 Pillow 强制按正确位深重新打开from PIL import Image img Image.open(bad_color.bmp) img img.quantize(colors256, methodImage.MEDIANCUT) img.convert(RGBA).save(fixed.png)逻辑说明先用quantize重新量化调色板到 256 色再转 RGBA 输出。这能解决一部分调色板索引错位导致的偏色。参数说明MEDIANCUT是中位切分法对颜色分布不均匀的图片效果好如果偏色是整体性偏绿偏紫优先怀疑调色板项数读错用quantize不一定能完全还原这时要回到 arc_conv_r55 的参数看看有没有-bpp或-depth之类的强制位深参数。r55 的帮助信息里如果提供了这类参数优先在解包阶段修正而不是在导出后做有损补救。4.3 画面尺寸与偏移读的不是像素尺寸而是内存跨距还有一种比较隐蔽的翻车图片能打开颜色也对但画面明显被裁切了一截或者整体往右下偏移了一块。这个问题的根源通常是原素材的头部信息里记录的不是像素宽高而是内存中的跨距。老游戏图片在内存里经常要做 4 字节或 16 字节对齐于是每个扫描行末尾会塞额外字节。工具如果直接把跨距当成像素宽度读解出来的图就会呈现「斜切」效果。检验方法很简单把图宽除以 4如果能整除且画面恢复正常形状基本就是跨距问题。修正方案是在 Python 里做逐行裁剪from PIL import Image img Image.open(offset.bmp) width, height img.size real_width width // 4 # 假设多算的宽度来自 4 字节对齐 cropped img.crop((0, 0, real_width, height)) cropped.save(fixed.bmp)逻辑说明将宽度除以对齐单位截掉每行右侧的对齐填充字节。具体除以几要根据原引擎的对齐规则来常见的是 4 或 16。参数说明这个修正属于事后补救效率不高。更可靠的路径是查 arc_conv_r55 有没有-align或-stride参数如果有在解包时直接指定正确的对齐值导出的图就是正常尺寸。这一点强烈建议你在批量处理前先测试一个小包否则几百张图全部歪掉后悔药都没得吃。5. arc_conv_r55 避坑实录闪退、黑图、乱码的 4 次翻车5.1 双击窗口一闪而过像没运行一样现象在资源管理器里双击 arc_conv_r55.exe弹出一个命令行窗口零点几秒就消失了什么都来不及看。原因绝大多数情况下是参数没带。这个工具没有交互界面裸双击等于传了一个空参数给它它打印完帮助信息就退出而帮助信息在窗口关闭前你看不到。解决不要在资源管理器里双击而是在 cmd 或 PowerShell 里先切到工具所在目录再执行cd /d D:\tools\arc_conv_r55 arc_conv_r55.exe help.txt 21注意如果切目录后直接运行还是没输出检查同目录下是不是缺少运行库文件。这类工具依赖 VC 运行时的不少报错往往是0xc0000135或弹一个缺 DLL 的对话框。把所需的运行库文件放到工具的同一目录或者装对应版本的运行时问题就没了。这是新手最容易碰到的第一道坎。5.2 解包全程无报错但图片全黑或全白现象-m unpack 跑完日志全部正常文件也都导出了但图片打开是一张纯黑或纯白底图没有任何画面内容。原因这个 ARC 是加密变体资源字节做过 XOR 或偏移处理arc_conv_r55 能解析文件表但没法正确解码像素数据。表现就是文件结构对、内容不对。解决先确认这一族加密变体是否需要外部密钥文件。翻一下游戏目录里有没有 .key、.dat 之类的文件如果 arc_conv_r55 的帮助信息里带-key或-xor参数把密钥文件路径传进去再试一次。如果仍然黑图就不要硬耗了这个版本库大概率不支持该引擎的加密算法直接搜对应引擎名加 arc decrypt 关键词找专用工具更现实。5.3 解出的文件名全是乱码目录结构没法归档现象解包成功了但输出的所有文件都是.png或缂栬緫.png之类的乱码文件名后续脚本按文件名匹配全部失效。原因ARC 包内部文件名是 Shift-JIS 编码而工具默认按当前系统代码页解析两边不一致导致乱码。中文 Windows 系统代码页是 GBK解日文游戏必现。解决用-enc参数强制指定编码。常见取值是sjis或shift-jis具体写法以 r55 的帮助信息为准。如果指定编码后仍然乱码另一个应急方案是让工具按索引导出然后用-outfile生成一份清单文件脚本里按索引映射文件名。5.4 导出一部分后中断报错提示文件占用或路径过长现象批量解包跑到中段突然停住报错信息是权限不足或找不到路径重跑一遍又总是卡在同一个文件上。原因游戏本体还在运行arc 文件被进程锁定或者输出路径嵌套太深加上文件名长度超过 Windows 的 MAX_PATH 限制写文件时失败。解决先关掉游戏进程再解包这是一劳永逸的做法。路径问题则把输出目录尽量放浅层比如C:\arc_out符号说明Windows 默认路径上限是 260 个字符老游戏的资源文件经常有长名解包的子目录稍微一嵌套就会撞上限。如果真的遇到非长路径不可的场景给工具开长路径支持系统策略里启用 Win32 长路径同时工具本身要带 manifest 声明才生效。6. 把 arc_conv_r55 接进素材流水线后处理与完整性校验6.1 用 Python 批量转换并保留目录结构解包只是第一步真正让工作流顺畅的是把解包、格式转换、目录归档串成一条流水线。我常用的处理是在上一章批量解包脚本的基础上接一段 Pythonfrom pathlib import Path from PIL import Image src_root Path(./out) dst_root Path(./converted) dst_root.mkdir(exist_okTrue) for bmp_path in src_root.rglob(*.bmp): rel bmp_path.relative_to(src_root) out_path dst_root / rel.with_suffix(.png) out_path.parent.mkdir(parentsTrue, exist_okTrue) img Image.open(bmp_path) img.save(out_path) print(fconverted: {rel})逻辑说明递归遍历解包目录下的所有 BMP按原目录结构对应生成 PNG这样素材归类不会打乱。参数说明rglob(*.bmp)是递归匹配所有层级下的 BMP 文件relative_to拿到相对路径保证输出目录结构一致性。这段代码只管格式转换Alpha 合并、调色板修正都可以按第 4 章的逻辑加进去。6.2 完整性校验别等到做完才发现少图解包工具偶尔会静默跳过某些文件特别是遇到无法解析的子格式时。批量处理前先记录包内文件总数转换完再做一次数量对比是最基本的校验。更严格的做法是解出后用哈希值做比对。# 统计 src 和 dst 目录下文件数量 find ./out -type f | wc -l find ./converted -type f | wc -l参数说明如果两个数字不一致用diff -rq ./out ./converted找出具体差异文件如果数字一致但怀疑内容错乱抽几个关键文件用图像查看器人工检查。我对数量对但内容错的印象很深就是第 4 章说的跨距问题所以每次都至少抽验三个不同角色的素材确认画面完整再全量推进。6.3 我的验收习惯与工具边界现在让我回过头说一个被很多人忽略的点arc_conv_r55 是一个窄工具只负责从特定类型的 ARC 容器里提取资源。解包完成只是起点真正决定素材能不能用的是后续的 Alpha 合并、位深纠偏、尺寸校正这套流程。我现在的习惯是拿到新包先做三件事跑一次列表模式确认文件表、解出单张立绘验证尺寸和透明通道、批量跑完再抽验证颜色。这三步做完素材基本就能放心进入后续的整理或加工环节。另外一个血泪教训是解包出来的东西如果需要重新打包回游戏现在的版本大概率没有封包功能别再花时间找参数了换个思路搜专门的打包器。工具边界画清楚时间就省下来了。希望帮到你。本文还有配套的精品资源点击获取