简介这是一份面向冒险岛玩家的 WZ 编辑器改版源码包内容对应 Harepacker-resurrected 项目主线分支。工具以 C# 编写在原有版本基础上优化了用户界面并支持修改游戏密钥可配合密钥数据管理功能处理加密资源适合想自定义游戏数据、研究 WZ 文件结构或开展二次开发的进阶玩家。压缩包内共 619 个文件其中 380 个 .cs 源代码文件是核心学习对象另有 135 个 .resx 界面资源、65 个 .png 图标、10 个 .xaml 布局文件以及少量配置、说明文档和项目工程文件整体仅 3.64 MB目录结构清楚下载后可直接阅读。目前已有 515 人学习/下载。源码覆盖主窗体、信息编辑器、地图保存器等多个功能模块代码中的工程文件和引用关系已配置完整既可以直接编译成可运行工具也可以在其上继续扩展或修复问题是理解冒险岛数据编辑流程的一份实用参考资料。1. Harepacker-resurrected-master 是给谁用的从 WZ 文件到客户端动刀旧版 Harepacker 在 JDK 8 上能跑换到新机器就罢工客户端版本一更新WZ 文件结构一改工具直接不认。Harepacker-resurrected-master 这类复活版就是答案社区把原版源码接过来升级依赖保证新版客户端和现代 JDK 下还能继续拆 WZ。这个方向的实用价值在于MapleStory 这类老游戏把皮肤、UI、地图、技能动画全锁在 WZ 资源包里做客户端改版、汉化、画质修正、活动素材替换都绕不开它配合 WZEDITOR 视图和 anchor 锚点编辑一个文件就能精确定位到某个按钮或图片的位置。适合做客户端资源研究的从业者和想搞懂 WZ 内部结构的学习者。2. 跑通 Harepacker-resurrected-master源码构建与首次挂载 WZ这一章的目标不是让你知道有这个东西而是把它真正跑起来看到 Node Tree 出现在屏幕上。这里我会按「WZ 格式先立住 → 从源码构建 → 首次打开文件」的顺序走每一步都给你能直接复现的命令和参数。2.1 WZ 文件的三个层级文件、img、节点WZ 不是普通文件夹而是一个自定义归档格式。整个客户端所有资源通常集中在 Data 目录下里面散落着 Map.wz、Character.wz、UI.wz 这些大文件单个文件可以上 GB。理解 WZ 必须从三个层级入手最外层是 .wz 文件本身相当于一个只读归档归档内部是一堆 .img 条目每个 img 类似一个逻辑目录img 里才是真正的节点树也就是你在 Harepacker 里展开后看到的层层叠叠的结构。img 之下每个节点都有类型常见的是 Property、Canvas、UOL、Vector 这四类。Property 存属性值比如字符串、整数、浮点Canvas 存位图资源也就是你看到的游戏图片附带宽高和格式信息UOL 是引用节点指向另一个节点常用于复用具名资源Vector 是二维坐标专门存 x、y。这套结构本身是老游戏资源管理里常见的设计——把图片、布局、动画参数混在一个文件里加载时一次性读入内存。resurrected 分支和旧版的核心差别就在解析层。旧版 Harepacker 遇到新版客户端里某些新加密的字符串节点会直接抛异常或读成乱码resurrected 把解密逻辑和节点解析流程重新对齐过这才让老工具在新客户端上重新可以打开。你不需要理解加密算法本身但要知道一个事实WZ 的二进制布局在历次版本里一直在变选择一个持续维护的分支比用最后发布的旧版更省心。2.2 从源码构建Maven 命令与分支切换常见做法是直接下载编译好的 release 包但如果你想确认这个 New_nan 分支到底做了什么修改或者希望给工具加自己的插件逻辑就需要从源码构建。Harepacker 是 Java 项目Maven 管理依赖构建命令很直接# 克隆仓库后进入项目根目录 git clone 你的 Harepacker-resurrected 仓库地址 cd Harepacker-resurrected # 想落在标题里的 New_nan 分支就切过去 git checkout New_nan # 跳过测试打包生成可执行 jar mvn clean package -DskipTests打包完成后产物在 target 目录下常见的启动方式是java -Xmx4g -jar target/Harepacker.jar。参数含义拆开看-Xmx4g把 Java 堆上限设为 4GB这是打开大 WZ 文件的关键Map.wz 这类文件动辄 1GB 以上默认堆大小 256MB 根本不够用。-DskipTests跳过单元测试只为了快速出包如果你跑mvn clean package不带这个参数大概率会在测试阶段卡一会儿不是报错是测试本身比较慢。切换分支前记得git status看下工作区是否干净有未提交改动时git checkout会拒绝切换或要求先 stash。我第一次处理这种项目时就因为改了源码没提交切分支被拦还以为是仓库坏了其实一条git stash就能解决。如果你不需要任何分支特性直接用 release jar 跳过本节也不影响后续操作。2.3 首次挂载 Data 目录分清 wz 文件与 image 目录启动成功后第一步不是急着打开某个 wz而是确认你的客户端资源目录结构。老客户端资源通常在 Data 目录下里面直接放着 Map.wz、UI.wz 这些文件。但有些客户端版本会把资源拆成 Data 和 Data\image 两个部分后者保存的是解包出来的图片文件实际加载时还是以 wz 为准。在 Harepacker 里用File → Open指向 Data 目录工具会自动识别该目录下的所有 wz 文件并载入左侧资源树。这里有一个我刚开始踩过的误区看到 Data 目录学问大就以为要把所有 wz 一次性全打开。实际上你只需要按需打开具体文件。改 UI 布局就只开 UI.wz新手调整角色外观才需要 Character.wz地图相关是 Map.wz。全部加载不仅慢还会消耗大量内存32 位 JDK 下直接 OOM。首次打开还会遇到一个现象左侧树会看到一堆crc、header这样的隐藏节点。这些是 WZ 文件格式自带的元数据节点Harepacker 默认显示它们是为了调试方便。你正常编辑时建议在Tools → Options里勾选隐藏系统节点否则改错位置的风险会大幅增加。隐藏它们之后剩下的就是干净的 img 和节点树这时才算真正进入编辑状态。3. WZEDITOR 视图里的核心操作从 Node Tree 定位到修改资源Harepacker 的编辑器视图习惯叫 WZEDITOR 风格左侧是节点树右侧是预览区底部是节点属性面板。这一章把节点类型讲透再给出一条完整的图片替换链路最后说清楚 XML 导出在整个工作流里的位置。你会发现大部分修改工作其实发生在替图和改属性两个动作上。3.1 Node Tree 的四类节点与它们的用途边界WZEDITOR 能被称为「编辑器」而不是「查看器」核心就在于左侧这棵节点树可以直接改写。树的根是打开的 wz 文件下一层是各个 img再往下就是成千上万个属性节点。四类节点在树上的图标不同但很多新人只看名字会忽略它们的本质区别。Property 节点属性容器。常见的是一个img下先有一堆字符串属性比如name、version随后才是子节点。这类节点双击右侧属性面板即可改改完立刻写回。Canvas 节点真正的位图。它下面通常挂着width、height、format等子节点真正的图像二进制数据藏在节点内部树上看不见。右键预览区可以看到渲染效果。UOL 节点路径引用。例如某张技能图标写的是../../../Skill.img/xxx/icon它自己不存图只在游戏加载时跳转。修改 UOL 指向就能让多个位置共享同一张素材。Vector 节点坐标值下面只有 x、y 两个整数属性。UI 布局里大量使用anchor 就是它的一种。理解这四类节点能避免一个典型翻车场景你想改某张图找到的是一个 UOL 节点然后在 UOL 上替换 PNG。Harepacker 对 UOL 节点右键是不会有「替换 PNG」选项的因为 UOL 根本不含位图数据正确做法是顺着 UOL 指向找到真正的 Canvas 再改。你可以在节点树里右键 UOL →Go to Target跳转到引用目标这也是我改图标最常用的跳转操作。3.2 替换一张 PNG 的完整流程不用导出也能改替图是 WZ 编辑里最高频的操作。以替换角色某个装备的外观为例完整的操作路径是打开 Character.wz → 找到对应装备的 img → 展开到icon或sample子节点 → 右键 Canvas 节点。步骤是这样的在左侧树上定位到目标 Canvas 节点确认右侧预览显示当前图像。右键该节点选择Replace PNG...。在弹出的文件选择框里选中你的新 PNG。Harepacker 会在节点属性面板显示新的宽高确认尺寸和原图一致。改完后不要直接CtrlS建议File → Save As...输出成 clone.wz 做验证。这里最关键的是第四步的尺寸检查。游戏客户端加载 WZ 时会根据 Canvas 节点记录的宽高分配纹理区域。如果你替换的 PNG 比原图大游戏运行时可能只显示左上角部分或者因为纹理越界直接闪退。所以我在替换前都会先看一眼原图宽高用图像工具把新图缩放到完全一致再导入而不是依赖编辑器自动适配。另一个被很多人忽略的参数是format子节点。Harepacker 替换 PNG 时会自动把 PNG 转成 WZ 内部使用的图像格式但 format 值决定压缩和通道方式。老客户端常见的是0表示普通位图某些版本用1表示带透明度压缩。如果你替换后预览正常、游戏里却显示成黑块先回来检查 format 是否需要同步修改这是个典型的黑匣子问题。3.3 用 XML 导出留底与做版本 diffHarepacker 支持把任意 img 导出为 XML 文件这个功能在改 UI 类资源时尤为重要。UI.wz 这类文件里几乎没有大位图绝大部分内容是属性节点和 Vector 坐标XML 能完整反映结构而 Character.wz 这类含大量 Canvas 的文件导出 XML 时图片数据不会写进 XML只保留节点引用所以不要指望用 XML 做地图资源的备份。导出操作是右键任意 img 节点 →Export...→ 选 XML 格式。导出的文件是一个纯文本树结构上跟你在 Harepacker 里看到的层级完全一致。拿到 XML 之后你可以用任意 diff 工具对比两个客户端版本的改动也能在版本升级后快速找到新增的 UI 节点。我处理移植素材的常规流程是旧客户端导出 XML → 新客户端导出 XML → diff → 把差异对应的节点手动在新客户端里补上。这个过程看起来绕但它能避免直接在新版本里手动找节点尤其当你面对的是 UI.wz 里几百个长得差不多的按钮节点时diff 结果比人眼可靠得多。注意 XML 导出的编码默认是 UTF-8Windows 下用记事本打开会乱码配合 VS Code 或 Notepad 查看并在脚本处理时统一用 UTF-8 读写。4. Anchor 锚点系统UI 错位问题的坐标解剖Anchor 是标题里最具体的功能点也是实际项目里改 UI 布局时最常打交道的节点。这一章我会把坐标系讲清楚然后给出一条定位和修改 anchor 的完整路径最后落到一个可以复现的登录界面按钮修正案例。4.1 坐标系与 Anchor 的计算逻辑老游戏 UI 布局里控件很少用「绝对像素坐标」直接定位而是用「相对父节点的偏移」。anchor 就是这个偏移值的载体它是一个 Vector 节点里面的 x、y 表示当前控件的左上角相对父级内容区域左上角的偏移量。简单说anchor 定义了「这个控件放在父容器里的哪个位置」。多层嵌套时最终渲染位置是逐级累加的结果。一个按钮位于某个 Group 下Group 又有自己的 anchor 指向另一个面板那么按钮最终位置 面板 anchor Group anchor 按钮 anchor。理解这个累加逻辑非常关键因为它解释了为什么你改了某个按钮自己的 anchorUI 纹丝不动——问题可能出在某一级父节点的 anchor 被写死成了固定值。在 WZ 里anchor 节点通常直接命名为anchor但注意不是所有叫 anchor 的节点都是坐标。有些节点是 Int 类型表示「使用默认锚点编号」需要到资源的另一处映射表里查具体含义。这是最容易产生玄学感的细节明明改了数字却没效果其实你改的是编号索引不是坐标偏移。4.2 在 UI.wz 中定位 Anchor 节点的两种路径打开 UI.wz 后所有的界面都挂在各个 img 下例如 Login.img、CashShop.img、StatusBar.img。定位 anchor 有两种路径我分别说适用场景。第一种是按界面名逐层找展开 Login.img找到你关心的控件比如Login.img/BtnLogin再展开 BtnLogin 节点通常下面就是anchor子节点。这种方式适合你已知界面名称、想快速查看某个控件锚点的场景。树展开后直接双击 anchor会弹出一个坐标编辑框填 x、y 即可。第二种是全局搜索如果你只知道要改什么图片不确定它在哪个界面用CtrlShiftF打开搜索面板输入图片名或节点名Harepacker 会遍历当前打开的 wz 文件给你列出所有命中位置。这种方式适合改素材前先确认「这个 UI 元素被哪些界面复用」——复用意味着你改一个节点多个界面的同一控件都会动。定位时还要分清anchor和origin。Canvas 节点下也有origin但那是图片绘制的基准点决定图片从哪个像素作为 (0, 0)和 UI 布局的 anchor 是两码事。我见过有人为了移动按钮去改origin把整张图的绘制位置搞乱原因为两者中只有一个名字翻译成「锚点」实际语义完全不同。4.3 实操把登录界面按钮调回正确位置假设你拿到一个改过的客户端发现登录按钮比原版偏右了 20 像素。目标是把它移回原位。操作路径是打开 UI.wz → 展开 Login.img → 找到按钮节点 → 打开 anchor 编辑框 → 记录当前 x 值 → 减 20 → 保存。记录修改前的值非常建议做因为不记录的话你改完发现不对想还原就得靠记忆往回改。这时候你会发现 UI 布局里坐标是叠加的一次改两个值还是能算回来但改第三处的时候记忆就开始不可靠了。具体的修改参数没有标准答案不同客户端版本按钮的 anchor 值都不一样。你需要自己做一次基准测量先在游戏里截一张正常状态的图再用 Harepacker 定位按钮的 anchor把 x、y 记下来。之后每次微调都以这个值为基准而不是靠肉眼临场猜。保存时注意直接覆盖 UI.wz 会让客户端文件变大一点但改动必须生效需要覆盖。建议输出为 clone.wz测试确认后再替换原文件。加载验证时游戏日志会记录资源加载失败你看日志里有没有UI.wz/login.img/BtnLogin相关报错就能判断是节点路径变了还是坐标值超出了合法范围。5. 修改 WZ 的避坑指南闪退、错位、丢图、卡加载这一章是我实际改版的血泪经验堆出来的。每个坑都按「现象 → 原因 → 解决」写你在照着做的时候提前避开至少能省下半天排查时间。5.1 替换 PNG 后游戏闪退尺寸与格式不是差不多就行现象替换一张 PNG 并保存后客户端启动到加载角色界面直接闪退日志没有任何明确报错。原因替换的 PNG 尺寸比原图大游戏按原宽高分配纹理越界读取触发崩溃或者新 PNG 的通道顺序与原图不一致游戏端做了非法内存访问。解决替换前用图像工具把新图缩放到与原图完全一致注意检查透明通道保存后先输出 clone.wz 测试。我自己的标准是宽高必须逐像素一致通道数也必须一致格式上不依赖 Harepacker 自动转换先在外部处理好再导入。5.2 anchor 改了但 UI 纹丝不动改错了节点或父级偏移现象双击 anchor把 x 从 100 改成 80保存进游戏按钮位置完全没有变化。原因第一你改的是某个被 UOL 引用的节点游戏实际加载的是另一个路径的 Canvas 和 anchor第二按钮外层父节点还有一个未揭示的偏移抵消了你的修改第三你改的 anchor 是 Int 类型的索引值而非 Vector 坐标。解决在节点树上顺着父级逐层检查确实确认路径再用全局搜索定位同名的所有 anchor集中比较它们的值后决定改哪一个。5.3 导出 XML 再导入后丢图XML 不背二进制的锅现象把某个含图片的 img 导出为 XML脚本改完之后再导入保存出来的 wz 里对应图片全变空白。原因Harepacker 的 XML 导出格式只包含属性节点和结构信息Canvas 的位图二进制数据并不会写进 XML 文件。你做的实际上是「用一份没有图像的 XML 覆盖了原节点」位图自然丢失。解决区分用途——属性修改和小型 UI 调整可以用 XML 导入导出带大量位图的 Map.wz、Character.wz 相关修改不要走 XML 流程直接在 GUI 里改完保存。需要批量迁移位图时用右键Export Images把图导出为 PNG 目录导入时再逐张替换而不是整体导 XML。5.4 加载大 WZ 文件卡死Java 堆内存与 GC 参数现象打开 Map.wzHarepacker 界面卡在加载进度条持续五分钟无反应系统内存却占用极高。原因默认 Java 堆太小GC 频繁触发 Full GC编辑器几乎在「假死」状态。解决启动时带上-Xmx参数常见做法是给到 4GB 到 8GB8GB 适合地图类大文件。命令我推荐写成java -Xms2g -Xmx8g -jar Harepacker.jar-Xms让 JVM 启动时就分配好基础堆减少前期的扩容和 GC 压力。另外确认你用的 JDK 是 64 位版本32 位 JDK 永远无法使用超过 4GB 堆。如果内存仍然吃紧就只打开需要修改的 wz不要整个 Data 目录全部挂在树上。6. 用 XML 批处理批量调 anchor以及我的备份习惯最后一章给一个能直接抄的进阶技巧当你要调整的不止一个按钮而是整个界面上几十处 anchor 时用 Python 脚本批量处理 XML 远比在 GUI 里逐个双击修改靠谱。import sys import xml.etree.ElementTree as ET # 用法: python move_anchor.py ui.xml 20 # 作用: 把 XML 中所有名为 anchor 的 Vector 节点 x 值统一右移 20 像素 tree ET.parse(sys.argv[1]) dx int(sys.argv[2]) for elem in tree.iter(): if elem.tag vector and elem.get(name) anchor: x int(elem.get(x, 0)) dx elem.set(x, str(x)) tree.write(sys.argv[1], encodingutf-8, xml_declarationTrue)脚本逻辑很简单解析 XML 树遍历所有vector标签筛选nameanchor的坐标节点修改 x 属性写回原文件。.iter()会递归访问所有嵌套层级保证深层的 anchor 也能扫到。dx可以是负数表示左移只改 x 不改 y需要纵向移动时把逻辑扩到y属性即可。执行前务必先复制一份原始 xml 做备份脚本会把源文件原地覆盖没有后悔药。这个脚本的适用场景是有边界条件的只有像 UI.wz 这种几乎不含位图的文件导出 XML → 批量改 → 再导入才安全。如果文件里有大量 Canvas回到第 5.3 节的坑——XML 里没有图像数据导入会把位图抹掉。所以我会先用第 3.3 节的流程确认目标文件适合 XML 编辑再决定走这条路。备份习惯是我改任何客户端资源都不会省的一步。我的做法是在修改前把整个 Data 目录复制一份放在旁边命名Data_backup然后用 clone.wz 做验证确认无误后删掉备份。听起来简单但很多人翻车在「改完直接覆盖原文件游戏起不来手边没有备份只能重新下客户端」。那次我花了两小时重新下载资源之后所有改动一律先输出 clone.wz。希望帮到你。本文还有配套的精品资源点击获取