简介这份资源面向游戏开发与逆向工程爱好者提供将大话西游WAS资源文件导出为PNG图片的C#源码工具解决游戏内部资源难以解析、提取和二次利用的问题。压缩包共45个文件约344KB以cs源码、exe可执行程序、pdb调试文件、resources资源、config配置及resx窗体资源为主另含sln与csproj工程文件可直接用Visual Studio打开编译运行。源码完整呈现读取WAS二进制数据、解析文件头、解密数据、提取图像并转换为PNG的流程同时涉及WDF资源处理思路便于读者理解游戏资源封装结构。已有209人学习下载适合希望掌握游戏文件格式解析、资源导出与逆向分析技巧的开发者参考也可作为扩展处理其他游戏资源格式的基础框架。1. 大话西游 WAS 导出 PNG从 WDF 资源包到可用图片的完整路径手里有一份大话西游的 WDF 资源包想把它里面的 WAS 贴图导成 PNG这件事听起来像个小工具需求实际动手会发现中间隔着好几层WDF 是打包容器WAS 是里面的精灵/贴图单元PNG 才是最终能看的图片。标题里那句「C# 源码」才是关键——它意味着这不是让你去用某个现成软件点两下而是给你一条能用代码批量跑通的路。适合谁适合手上有资源包、想批量导出做素材整理、做二次开发或者单纯想把老资源存成通用格式的人。我一般会先把 WDF 的容器结构摸清楚再处理 WAS 的解码最后才是 PNG 编码落盘顺序反了会一直卡在「读出来是乱码」这一步。2. WDF 容器与 WAS 贴图先搞清楚你在读什么2.1 WDF 不是图片格式是资源打包容器很多人第一次拿到 WDF 文件双击打不开就以为文件坏了。其实 WDF 是大话西游客户端用来打包资源的容器格式里面按索引存放着大量子资源WAS 就是其中一类。你可以把它理解成一个没有压缩的归档文件头部有文件数量、索引表偏移索引表里每条记录指向一个子资源的偏移和长度。真正决定你能不能导出成功的是索引表的解析是否正确而不是后面 PNG 怎么存。常见做法是先读文件头拿到索引区起始位置和条目数然后按固定步长遍历索引表。不同版本的 WDF 头部字段长度可能不一样所以第一步不是写解码而是用十六进制工具看一眼头部确认字段宽度。这一步偷懒后面所有偏移都会错位导出来的全是碎片。// 读取 WDF 头部确认索引区位置与条目数量 using (var fs new FileStream(wdfPath, FileMode.Open, FileAccess.Read)) using (var br new BinaryReader(fs)) { // 头部前 4 字节通常是标识用来快速判断是不是合法 WDF string magic new string(br.ReadChars(4)); if (magic ! WDFP magic ! WDFX) // 具体标识以实际文件为准 throw new InvalidDataException(不是预期的 WDF 容器); int fileCount br.ReadInt32(); // 子资源条目数 int indexOffset br.ReadInt32(); // 索引表起始偏移 fs.Seek(indexOffset, SeekOrigin.Begin); for (int i 0; i fileCount; i) { int offset br.ReadInt32(); // 子资源数据偏移 int length br.ReadInt32(); // 子资源长度 // 这里先只打印确认偏移是否落在文件范围内 Console.WriteLine($条目 {i}: offset{offset}, length{length}); } }这段代码的重点不在解码而在验证。magic用来快速排除拿错文件的情况fileCount和indexOffset决定你遍历的范围每条记录的offset和length必须满足offset length 文件总长否则说明字段宽度猜错了。参数上唯一需要你手动确认的是标识字符串和索引步长这两个值不同版本可能不同用十六进制工具对照一次就能定下来。2.2 WAS 贴图的像素布局与调色板WAS 本身不是标准图片它更像一段带描述信息的像素数据。常见结构是先有一段头信息说明宽高、像素格式、是否带调色板然后才是像素数据。像素格式可能是 32 位带 Alpha也可能是 8 位索引色加一张调色板。你如果直接把整段数据当 RGBA 读出来的图会花得没法看这就是典型的「格式没对上」。判断格式的可靠办法是看头部里的位深字段和调色板标志。位深 32 一般直接按 BGRA 或 RGBA 读位深 8 就必须先读调色板再用索引去查颜色。这里有个容易翻车的点调色板颜色顺序可能是 BGRA 而不是 RGBA红蓝通道对调后整张图会偏色肉眼一看就知道。// 解析 WAS 头部并取出像素数据兼容 32 位与 8 位索引色 byte[] wasData File.ReadAllBytes(wasPath); using (var ms new MemoryStream(wasData)) using (var br new BinaryReader(ms)) { int width br.ReadInt16(); int height br.ReadInt16(); byte bitDepth br.ReadByte(); // 32 或 8 byte hasPalette br.ReadByte(); // 0 或 1 int pixelCount width * height; byte[] pixels; if (bitDepth 32) { pixels br.ReadBytes(pixelCount * 4); // 每像素 4 字节 } else { // 8 位索引色先读调色板再读索引 int paletteCount hasPalette 1 ? 256 : 0; byte[] palette br.ReadBytes(paletteCount * 4); byte[] indices br.ReadBytes(pixelCount); pixels new byte[pixelCount * 4]; for (int i 0; i pixelCount; i) { int pi indices[i] * 4; // 注意通道顺序BGRA 转成 RGBA pixels[i * 4 0] palette[pi 2]; pixels[i * 4 1] palette[pi 1]; pixels[i * 4 2] palette[pi 0]; pixels[i * 4 3] palette[pi 3]; } } // 此时 pixels 已是 RGBA 顺序可交给 PNG 编码 }逻辑上先读头再决定分支避免用同一套读取方式硬套所有文件。参数里bitDepth和hasPalette是分叉依据width、height决定后续数据长度如果读出来的像素数和预期对不上基本就是头部字段宽度错了。通道顺序那三行是血泪经验调色板里存的是 BGRA直接当 RGBA 用就会偏色。3. 用 C# 把 WAS 像素写成 PNG编码与批量导出3.1 选 System.Drawing 还是自己写 PNG 编码C# 里把像素写成 PNG最省事的是System.Drawing.Bitmap构造好位图直接Save成 PNG 就行。它在 Windows 上稳定代码量少适合快速验证。但它依赖 GDI在非 Windows 环境或者服务端批量跑的时候可能受限。另一种做法是自己按 PNG 规范写块好处是不依赖平台坏处是要处理 CRC 和 zlib 压缩工作量大。我一般会分两步先用System.Drawing把单张图跑通确认像素解析没问题确认后再决定要不要换成自写编码器做跨平台批量。这样排错成本最低不会一上来就陷进 PNG 块结构里。// 把 RGBA 像素写成 PNG先用 System.Drawing 验证 using System.Drawing; using System.Drawing.Imaging; Bitmap bmp new Bitmap(width, height, PixelFormat.Format32bppArgb); BitmapData data bmp.LockBits( new Rectangle(0, 0, width, height), ImageLockMode.WriteOnly, PixelFormat.Format32bppArgb); // 把 pixels 拷进位图缓冲区 System.Runtime.InteropServices.Marshal.Copy(pixels, 0, data.Scan0, pixels.Length); bmp.UnlockBits(data); bmp.Save(outputPngPath, ImageFormat.Png); bmp.Dispose();PixelFormat.Format32bppArgb必须和你的像素顺序一致否则颜色会错。LockBits比逐像素SetPixel快很多批量导出时差距非常明显。Save的第二个参数指定 PNG 编码器不指定的话可能按扩展名猜容易出意外。3.2 批量导出时的目录组织与命名单张能导之后真正要面对的是成百上千个 WAS。批量导出最容易乱的是命名和目录结构同名覆盖、层级丢失、导出到一半中断。我的习惯是按 WDF 文件名建一级目录按索引号或资源名建二级目录PNG 文件名带上原始索引这样出问题能回溯到具体条目。// 批量导出按容器名和索引组织输出目录 string outRoot Path.Combine(outputDir, Path.GetFileNameWithoutExtension(wdfPath)); Directory.CreateDirectory(outRoot); for (int i 0; i entries.Count; i) { var entry entries[i]; byte[] raw ReadEntry(wdfPath, entry.Offset, entry.Length); if (!IsWas(raw)) continue; // 跳过非 WAS 资源 var img DecodeWas(raw); string name ${i:D5}_{entry.Name}.png; string path Path.Combine(outRoot, name); SavePng(img, path); }i:D5保证索引号定长排序时不会出现 1、10、2 这种乱序。IsWas用来过滤非贴图资源避免把配置数据也当图片解。ReadEntry按偏移和长度读不要一次性把整个 WDF 读进内存大文件会直接吃满内存。3.3 导出结果的快速校验导完不是就结束了得快速判断有没有导错。最直接的办法是抽几张图看尺寸和透明度尺寸和 WAS 头部里的宽高一致透明区域正常颜色不偏。如果发现大量图尺寸是 0 或者全黑基本是头部解析或像素格式判断出了问题回到第 2 章那两个分支去查。校验项正常表现异常时优先排查图片尺寸与 WAS 头部宽高一致头部字段宽度是否读错透明通道背景透明边缘干净位深是否为 32 位颜色与游戏内观感接近调色板通道顺序文件数量与 WAS 条目数吻合索引遍历范围4. 导出 WAS 到 PNG 的避坑与排查4.1 现象导出的图全是花屏或斜条纹原因通常是像素步长和宽度不匹配。WAS 每行像素可能有对齐填充不是严格的width * 字节数。如果按紧凑布局读行与行之间就会错位形成斜条纹。解决办法是先确认每行实际字节数按行读取再拼接而不是一次性读整块。4.2 现象图片能看但颜色整体偏蓝或偏红这是通道顺序问题。调色板或像素数据里存的是 BGRA你按 RGBA 解释红蓝就对调了。解决方式是在解码阶段统一转成 RGBA转换只做一次后面 PNG 编码不再动通道。不要在两处都转会转两次又变回去。4.3 现象批量导出到一半程序崩溃多半是内存问题。把整个 WDF 读进byte[]再处理遇到大容器直接爆内存。改成按条目偏移用FileStream.Seek读取每次只读当前条目处理完就释放。另外Bitmap用完必须Dispose否则 GDI 对象堆积也会崩。4.4 现象部分条目读出来长度为 0 或负数索引表解析错了。可能是条目步长不对或者索引区偏移算错。用十六进制工具对照头部和索引区确认每条记录的字段数和字节序。小端序读成大端序也会出现这种离谱数值。4.5 现象导出的 PNG 在别的工具里打不开如果用了自写 PNG 编码常见原因是 CRC 没算对或者 zlib 数据块不完整。先用System.Drawing导一张对比能打开说明像素没问题是编码器的问题。批量场景下优先用成熟库别在 PNG 块结构上耗太久。5. 进阶把导出流程做成可复用的小工具走到这里单次导出已经能跑通。真正省时间的是把它做成一个能反复用的小工具命令行传 WDF 路径和输出目录内部自动遍历、过滤、导出、记录日志。我一般会加一个--only-was开关默认只导 WAS避免把无关资源也写出来再加一个--index参数只导指定索引方便定位问题条目。验证工具有没有做对有个简单办法拿同一个 WDF 跑两次对比输出文件的哈希。如果两次不一致说明流程里有不确定因素通常是命名冲突或者并发写。批量导出不要盲目开多线程磁盘 IO 和 GDI 对象都不是线程安全的串行反而更稳。// 命令行入口wdf2png wdf路径 输出目录 [--index N] static void Main(string[] args) { string wdfPath args[0]; string outDir args[1]; int? onlyIndex null; for (int i 2; i args.Length - 1; i) { if (args[i] --index) onlyIndex int.Parse(args[i 1]); } var exporter new WdfExporter(wdfPath, outDir); exporter.Export(onlyIndex); // 传 null 表示全部导出 }onlyIndex为 null 时全量导出指定时只处理那一条排查单张图特别有用。参数解析这里写得比较朴素实际用可以换成成熟的命令行库但核心逻辑不变路径进、目录出、可选过滤。一个我自己的习惯每次改完解码逻辑先只导 10 张看效果确认没问题再放开全量。全量跑一次可能几分钟改一次跑一次很浪费时间。另外导出目录不要放在系统盘根目录权限和路径长度都可能出玄学问题。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/9 23:51:04 · 阅读 1.2k C# 实现大话西游 WDF 资源包 WAS 贴图批量导出 PNG 完整教程
简介这份资源面向游戏开发与逆向工程爱好者提供将大话西游WAS资源文件导出为PNG图片的C#源码工具解决游戏内部资源难以解析、提取和二次利用的问题。压缩包共45个文件约344KB以cs源码、exe可执行程序、pdb调试文件、resources资源、config配置及resx窗体资源为主另含sln与csproj工程文件可直接用Visual Studio打开编译运行。源码完整呈现读取WAS二进制数据、解析文件头、解密数据、提取图像并转换为PNG的流程同时涉及WDF资源处理思路便于读者理解游戏资源封装结构。已有209人学习下载适合希望掌握游戏文件格式解析、资源导出与逆向分析技巧的开发者参考也可作为扩展处理其他游戏资源格式的基础框架。1. 大话西游 WAS 导出 PNG从 WDF 资源包到可用图片的完整路径手里有一份大话西游的 WDF 资源包想把它里面的 WAS 贴图导成 PNG这件事听起来像个小工具需求实际动手会发现中间隔着好几层WDF 是打包容器WAS 是里面的精灵/贴图单元PNG 才是最终能看的图片。标题里那句「C# 源码」才是关键——它意味着这不是让你去用某个现成软件点两下而是给你一条能用代码批量跑通的路。适合谁适合手上有资源包、想批量导出做素材整理、做二次开发或者单纯想把老资源存成通用格式的人。我一般会先把 WDF 的容器结构摸清楚再处理 WAS 的解码最后才是 PNG 编码落盘顺序反了会一直卡在「读出来是乱码」这一步。2. WDF 容器与 WAS 贴图先搞清楚你在读什么2.1 WDF 不是图片格式是资源打包容器很多人第一次拿到 WDF 文件双击打不开就以为文件坏了。其实 WDF 是大话西游客户端用来打包资源的容器格式里面按索引存放着大量子资源WAS 就是其中一类。你可以把它理解成一个没有压缩的归档文件头部有文件数量、索引表偏移索引表里每条记录指向一个子资源的偏移和长度。真正决定你能不能导出成功的是索引表的解析是否正确而不是后面 PNG 怎么存。常见做法是先读文件头拿到索引区起始位置和条目数然后按固定步长遍历索引表。不同版本的 WDF 头部字段长度可能不一样所以第一步不是写解码而是用十六进制工具看一眼头部确认字段宽度。这一步偷懒后面所有偏移都会错位导出来的全是碎片。// 读取 WDF 头部确认索引区位置与条目数量 using (var fs new FileStream(wdfPath, FileMode.Open, FileAccess.Read)) using (var br new BinaryReader(fs)) { // 头部前 4 字节通常是标识用来快速判断是不是合法 WDF string magic new string(br.ReadChars(4)); if (magic ! WDFP magic ! WDFX) // 具体标识以实际文件为准 throw new InvalidDataException(不是预期的 WDF 容器); int fileCount br.ReadInt32(); // 子资源条目数 int indexOffset br.ReadInt32(); // 索引表起始偏移 fs.Seek(indexOffset, SeekOrigin.Begin); for (int i 0; i fileCount; i) { int offset br.ReadInt32(); // 子资源数据偏移 int length br.ReadInt32(); // 子资源长度 // 这里先只打印确认偏移是否落在文件范围内 Console.WriteLine($条目 {i}: offset{offset}, length{length}); } }这段代码的重点不在解码而在验证。magic用来快速排除拿错文件的情况fileCount和indexOffset决定你遍历的范围每条记录的offset和length必须满足offset length 文件总长否则说明字段宽度猜错了。参数上唯一需要你手动确认的是标识字符串和索引步长这两个值不同版本可能不同用十六进制工具对照一次就能定下来。2.2 WAS 贴图的像素布局与调色板WAS 本身不是标准图片它更像一段带描述信息的像素数据。常见结构是先有一段头信息说明宽高、像素格式、是否带调色板然后才是像素数据。像素格式可能是 32 位带 Alpha也可能是 8 位索引色加一张调色板。你如果直接把整段数据当 RGBA 读出来的图会花得没法看这就是典型的「格式没对上」。判断格式的可靠办法是看头部里的位深字段和调色板标志。位深 32 一般直接按 BGRA 或 RGBA 读位深 8 就必须先读调色板再用索引去查颜色。这里有个容易翻车的点调色板颜色顺序可能是 BGRA 而不是 RGBA红蓝通道对调后整张图会偏色肉眼一看就知道。// 解析 WAS 头部并取出像素数据兼容 32 位与 8 位索引色 byte[] wasData File.ReadAllBytes(wasPath); using (var ms new MemoryStream(wasData)) using (var br new BinaryReader(ms)) { int width br.ReadInt16(); int height br.ReadInt16(); byte bitDepth br.ReadByte(); // 32 或 8 byte hasPalette br.ReadByte(); // 0 或 1 int pixelCount width * height; byte[] pixels; if (bitDepth 32) { pixels br.ReadBytes(pixelCount * 4); // 每像素 4 字节 } else { // 8 位索引色先读调色板再读索引 int paletteCount hasPalette 1 ? 256 : 0; byte[] palette br.ReadBytes(paletteCount * 4); byte[] indices br.ReadBytes(pixelCount); pixels new byte[pixelCount * 4]; for (int i 0; i pixelCount; i) { int pi indices[i] * 4; // 注意通道顺序BGRA 转成 RGBA pixels[i * 4 0] palette[pi 2]; pixels[i * 4 1] palette[pi 1]; pixels[i * 4 2] palette[pi 0]; pixels[i * 4 3] palette[pi 3]; } } // 此时 pixels 已是 RGBA 顺序可交给 PNG 编码 }逻辑上先读头再决定分支避免用同一套读取方式硬套所有文件。参数里bitDepth和hasPalette是分叉依据width、height决定后续数据长度如果读出来的像素数和预期对不上基本就是头部字段宽度错了。通道顺序那三行是血泪经验调色板里存的是 BGRA直接当 RGBA 用就会偏色。3. 用 C# 把 WAS 像素写成 PNG编码与批量导出3.1 选 System.Drawing 还是自己写 PNG 编码C# 里把像素写成 PNG最省事的是System.Drawing.Bitmap构造好位图直接Save成 PNG 就行。它在 Windows 上稳定代码量少适合快速验证。但它依赖 GDI在非 Windows 环境或者服务端批量跑的时候可能受限。另一种做法是自己按 PNG 规范写块好处是不依赖平台坏处是要处理 CRC 和 zlib 压缩工作量大。我一般会分两步先用System.Drawing把单张图跑通确认像素解析没问题确认后再决定要不要换成自写编码器做跨平台批量。这样排错成本最低不会一上来就陷进 PNG 块结构里。// 把 RGBA 像素写成 PNG先用 System.Drawing 验证 using System.Drawing; using System.Drawing.Imaging; Bitmap bmp new Bitmap(width, height, PixelFormat.Format32bppArgb); BitmapData data bmp.LockBits( new Rectangle(0, 0, width, height), ImageLockMode.WriteOnly, PixelFormat.Format32bppArgb); // 把 pixels 拷进位图缓冲区 System.Runtime.InteropServices.Marshal.Copy(pixels, 0, data.Scan0, pixels.Length); bmp.UnlockBits(data); bmp.Save(outputPngPath, ImageFormat.Png); bmp.Dispose();PixelFormat.Format32bppArgb必须和你的像素顺序一致否则颜色会错。LockBits比逐像素SetPixel快很多批量导出时差距非常明显。Save的第二个参数指定 PNG 编码器不指定的话可能按扩展名猜容易出意外。3.2 批量导出时的目录组织与命名单张能导之后真正要面对的是成百上千个 WAS。批量导出最容易乱的是命名和目录结构同名覆盖、层级丢失、导出到一半中断。我的习惯是按 WDF 文件名建一级目录按索引号或资源名建二级目录PNG 文件名带上原始索引这样出问题能回溯到具体条目。// 批量导出按容器名和索引组织输出目录 string outRoot Path.Combine(outputDir, Path.GetFileNameWithoutExtension(wdfPath)); Directory.CreateDirectory(outRoot); for (int i 0; i entries.Count; i) { var entry entries[i]; byte[] raw ReadEntry(wdfPath, entry.Offset, entry.Length); if (!IsWas(raw)) continue; // 跳过非 WAS 资源 var img DecodeWas(raw); string name ${i:D5}_{entry.Name}.png; string path Path.Combine(outRoot, name); SavePng(img, path); }i:D5保证索引号定长排序时不会出现 1、10、2 这种乱序。IsWas用来过滤非贴图资源避免把配置数据也当图片解。ReadEntry按偏移和长度读不要一次性把整个 WDF 读进内存大文件会直接吃满内存。3.3 导出结果的快速校验导完不是就结束了得快速判断有没有导错。最直接的办法是抽几张图看尺寸和透明度尺寸和 WAS 头部里的宽高一致透明区域正常颜色不偏。如果发现大量图尺寸是 0 或者全黑基本是头部解析或像素格式判断出了问题回到第 2 章那两个分支去查。校验项正常表现异常时优先排查图片尺寸与 WAS 头部宽高一致头部字段宽度是否读错透明通道背景透明边缘干净位深是否为 32 位颜色与游戏内观感接近调色板通道顺序文件数量与 WAS 条目数吻合索引遍历范围4. 导出 WAS 到 PNG 的避坑与排查4.1 现象导出的图全是花屏或斜条纹原因通常是像素步长和宽度不匹配。WAS 每行像素可能有对齐填充不是严格的width * 字节数。如果按紧凑布局读行与行之间就会错位形成斜条纹。解决办法是先确认每行实际字节数按行读取再拼接而不是一次性读整块。4.2 现象图片能看但颜色整体偏蓝或偏红这是通道顺序问题。调色板或像素数据里存的是 BGRA你按 RGBA 解释红蓝就对调了。解决方式是在解码阶段统一转成 RGBA转换只做一次后面 PNG 编码不再动通道。不要在两处都转会转两次又变回去。4.3 现象批量导出到一半程序崩溃多半是内存问题。把整个 WDF 读进byte[]再处理遇到大容器直接爆内存。改成按条目偏移用FileStream.Seek读取每次只读当前条目处理完就释放。另外Bitmap用完必须Dispose否则 GDI 对象堆积也会崩。4.4 现象部分条目读出来长度为 0 或负数索引表解析错了。可能是条目步长不对或者索引区偏移算错。用十六进制工具对照头部和索引区确认每条记录的字段数和字节序。小端序读成大端序也会出现这种离谱数值。4.5 现象导出的 PNG 在别的工具里打不开如果用了自写 PNG 编码常见原因是 CRC 没算对或者 zlib 数据块不完整。先用System.Drawing导一张对比能打开说明像素没问题是编码器的问题。批量场景下优先用成熟库别在 PNG 块结构上耗太久。5. 进阶把导出流程做成可复用的小工具走到这里单次导出已经能跑通。真正省时间的是把它做成一个能反复用的小工具命令行传 WDF 路径和输出目录内部自动遍历、过滤、导出、记录日志。我一般会加一个--only-was开关默认只导 WAS避免把无关资源也写出来再加一个--index参数只导指定索引方便定位问题条目。验证工具有没有做对有个简单办法拿同一个 WDF 跑两次对比输出文件的哈希。如果两次不一致说明流程里有不确定因素通常是命名冲突或者并发写。批量导出不要盲目开多线程磁盘 IO 和 GDI 对象都不是线程安全的串行反而更稳。// 命令行入口wdf2png wdf路径 输出目录 [--index N] static void Main(string[] args) { string wdfPath args[0]; string outDir args[1]; int? onlyIndex null; for (int i 2; i args.Length - 1; i) { if (args[i] --index) onlyIndex int.Parse(args[i 1]); } var exporter new WdfExporter(wdfPath, outDir); exporter.Export(onlyIndex); // 传 null 表示全部导出 }onlyIndex为 null 时全量导出指定时只处理那一条排查单张图特别有用。参数解析这里写得比较朴素实际用可以换成成熟的命令行库但核心逻辑不变路径进、目录出、可选过滤。一个我自己的习惯每次改完解码逻辑先只导 10 张看效果确认没问题再放开全量。全量跑一次可能几分钟改一次跑一次很浪费时间。另外导出目录不要放在系统盘根目录权限和路径长度都可能出玄学问题。希望帮到你。本文还有配套的精品资源点击获取