楼主，我想问一下这个可以对付日文游戏吗
刮大风 发表于 2014-7-9 10:04 static/image/common/back.gif
楼主，我想问一下这个可以对付日文游戏吗
笨笨猪软件的解包和打包功能处理的是游戏引擎问题，与游戏本体的英文、德文或日文无关，是可以对付的，但基准字库全部是中文系统，在制作日文字库方面恐怕是不行的。
楼主的工具能解包《王国保卫战》吗？（Kingdom Rush）http://bbs.3dmgame.com/thread-4370067-1-1.html
这个游戏文本不算太多，却一直没汉化
本帖最后由 SiMaKuangBiao 于 2014-7-10 07:54 编辑
2014-07-10
笨笨猪软件自动解包打包功能的代码实现。
在笨笨猪软件的整体功能分类中，自动解包打包的代码实现是比较简单的，仅通过定义一个TGamePackage类型即可实现（TGamePackage类同时也用于自动打包），TGamePackage类的声明如下所示：
TGamePackage=class(TObject)
private
TypeComboBox:TComboBox;//指向解包界面的解包类型下拉框
UnpackageGrid:TStringGrid;//指向解包界面的文件信息网格
PackageGrid:TStringGrid;//指向打包界面的文件信息网格
ProgressBar:TProgressBar;//指向通用提示窗口的进度条
APTSMKBForUnpackage:TAPTSMKBData;//笨笨猪解包记录，保存打包时依赖的信息
APTSMKBForPackage:TAPTSMKBData;//笨笨猪打包记录，保存解包时填写的依赖信息
GamePackageInfos:array of TGamePackageInfo;//游戏资源包格式匹配数组
FileTypes:array of TFileType;//文件类型匹配数组
procedure InitFileTypes();//初始化文件类型匹配数组
function GetFileTypeName(var GamePackageFile:TFileStream;FileTypePosition:Cardinal):string;overload;//获取文件类型名称
function GetFileTypeName(var Decompress:TMemoryStream;FileTypePosition:Cardinal):string;overload;//获取文件类型名称
procedure ClearAPTSMKBForUnpackage();//清除笨笨猪解包记录
procedure ClearAPTSMKBForPackage();//清除笨笨猪打包记录
procedure SaveAPTSMKB(UnpackagePaths:string;SaveFlag:Byte);//保存数据文件
procedure ReplacePathChar(ReplaceFlag:integer;FilenameCell:integer;LengthCell:integer);//替换路径分隔符
procedure Unpackage001(var GamePackageFile:TFileStream;UnpackageFlags:integer;UnpackagePaths:string);//实现PFPK解包算法
procedure Packages001(FilePaths:string; PackageOrFileFlag:integer; PackagePaths:string);//实现PFPK打包算法
procedure Unpackage002(var GamePackageFile:TFileStream;UnpackageFlags:integer;UnpackagePaths:string);//实现格瑞夫20解包算法
procedure Packages002(FilePaths:string; PackageOrFileFlag:integer; PackagePaths:string);//实现格瑞夫20打包算法
procedure Unpackage003(var GamePackageFile:TFileStream;UnpackageFlags:integer;UnpackagePaths:string;GamePackageFilename:string);//实现AUFS解包算法
procedure Packages003(FilePaths:string; PackageOrFileFlag:integer; PackagePaths:string);//实现AUFS打包算法
procedure Unpackage004(var GamePackageFile:TFileStream;UnpackageFlags:integer;UnpackagePaths:string;GamePackageFilename:string);//实现VT7A解包算法
procedure Packages004(FilePaths:string; PackageOrFileFlag:integer; PackagePaths:string);//实现VT7A打包算法
//增加新算法时需要修改和增加的函数
procedure InitGamePackageInfos();//初始化游戏资源包格式匹配数组
//这里需要增加两个函数：UnpackageXXX和PackageXXX，实现新算法的解包和打包代码
public
UnpackageID:integer;//解包算法ID
PackageID:integer;//打包算法ID
constructor Create(var TypeComboBoxs:TComboBox;var UnpackageGrids:TStringGrid;var PackageGrids:TStringGrid;var ProgressBars:TProgressBar);
procedure LoadAPTSMKB(FilePaths:string);//加载数据文件
procedure ClearUnpackageGrid();//清空解包界面网格内容
procedure ClearPackageGrid();//清空打包界面网格内容
procedure InitUnpackageGridTitle();//初始化解包界面网格标题
procedure InitPackageGridTitle();//初始化打包界面网格标题
function GetGamePackageFormatUnpackageDescription():string;//获取解包时的格式描述
function GetGamePackageFormatPackageDescription():string;//获取打包时的格式描述
function GetFileLengthString(FileLength:UInt64):string;//获取文件长度描述
function GetAPTSMKBDescription():string;//获取数据文件显示描述
function IsAutoPackage():Boolean;//检查是否可以打包
function GetResourceSize():Int64;//获取打包资源的总大小
//增加新算法时需要修改的函数
procedure CheckGamePackageFormat(GamePackageFilename:string);//检查游戏资源包格式，确定解包算法ID
function GetFileTables(GamePackageFilename:string):string;//获取文件表信息
function Unpackages(GamePackageFilename:string;UnpackagePaths:string):string;//自动解包
function Packages(FilePaths:string; PackageOrFileFlag:integer; PackagePaths:string):string;//自动打包
end;
除此之外，TGamePackage类需要定义三种记录或结构类型进行辅助，说明如下：
TGamePackageInfo = record
ID:integer;//游戏资源包格式ID
TypeName:string;//解包类型名称（智能分析或自定义独立类型）
IsAutoUnpackage:boolean;//是否实现了自动解包
IsAutoPackage:boolean;//是否实现了自动打包
Magic:string;//第一魔法值
MagicPosition:integer;//第一魔法值开始位置
MagicLength:integer;//第一魔法值长度
SubMagic:string;//第二魔法值
SubMagicPosition:integer;//第二魔法值开始位置
SubMagicLength:integer;//第二魔法值长度
FileCountPosition:integer;//文件数量开始位置
FileTablePosition:integer;//文件表开始位置
GridsTitle:array of string;//网格显示标题
UnpackageDescription:string;//解包时的格式描述
PackageDescription:string;//打包时的格式描述
end;
TAPTSMKBData = record
//结构属性（必须全部存在）
Magic1:string;//APT.SMKB固定魔法值（用于判断是否为数据文件）
SMKBVersion2:Byte;//数据文件版本，不允许低版本解析高版本
APTVersion3:Byte;//笨笨猪版本，不允许测试版解析高版本
Reserved4:Byte;//内部保留（用于加密）
ID5:Word;//算法ID
Filename6:string;//游戏资源包文件名
CreateDate7:string;//数据文件创建日期
FileCount8:Word;//文件数量（用于判断数据文件是否被转移到其他文件夹）
GamePackageSize9:Int64;//游戏资源包大小
//可选属性（根据解包算法的不同而不同）
FileTableOffset_1:Integer;//文件表起始偏移位置
FileDataOffset_2:Integer;//文件数据起始偏移位置
FileTableLength_3:Integer;//文件表长度
FileNameFlag_4:Byte;//数据文件名称存盘标记
FileHeadUnknowData_5:Cardinal;//文件头中的未知意义数据（4字节整数）
//全局属性（必须存在）
APTCRC32:Cardinal;//全局校验值
end;
TFileType=record
FileTypeMagic:string;
FileTypeMagicEx:string;
FileTypeName:string;
end;
09年的时候曾经有一位技术尝试做一个汉化平台，初步模型也出来了，然后。。。。就没有然后了。。。
2014-07-10
自动解包时TGamePackage类对象的方法调用。
1、主程序在启动时通过TGamePackage类的Create方法创建一个GamePackages对象，这是一个全局对象，与主程序具有相同的生命周期。Create方法会调用InitGamePackageInfos方法来初始化一个内部使用的数组GamePackageInfos，这个内部数组是一个TGamePackageInfo类型的结构数组，用于保存当前版本的笨笨猪软件所能提供的游戏引擎的分析数据；之后继续调用InitFileTypes方法来初始化一个内部使用的数组FileTypes，这个内部数组是一个TFileType类型的结构数组，用于保存特殊的文件类型分析信息，这个数组并不经常使用，仅在资源包中的文件表里没有明确的文件名称时才会用到；最后，初始化解包界面上的解包类型下拉列表。至此，GamePackages对象创建完毕，可以全局使用了。
2、当用户在解包界面上提供了一个资源包文件名称时，GamePackages对象将调用CheckGamePackageFormat方法来分析资源包的格式，以便确定解包算法ID，分析数据来源于内部数组GamePackageInfos，由于各个游戏引擎的分析方法并不相同，这里不再详细描述了。如果分析正确，GamePackages对象将在UnpackageID属性中返回确定的解包算法ID。
3、一旦确定了解包算法ID，GamePackages对象将调用InitUnpackageGridTitle方法来初始化解包界面上的文件表信息显示区域的网格标题，由于每种游戏引擎的文件表信息分类并不相同，因此在每次解包时都需要重置。之后继续调用GetFileTables方法来提取资源包中的文件表信息并显示。GetFileTables方法实际上是一个包装器方法，具体操作将转移到解包算法ID所对应的解包方法来最终完成。
4、一旦资源包中的文件表信息提取完成（在解包界面上可以看到），就表示此时可以顺利解包了，当用户在解包界面上提供了一个解包存盘路径时，GamePackages对象将调用Unpackages方法来完成自动解包操作。Unpackages方法实际上是一个包装器方法，具体的解包操作将转移到解包算法ID所对应的解包方法来最终完成，但是Unpackages方法必须承担另外一项重要工作，那就是为以后的自动打包做一些前期准备。因此，在转移解包操作之前，Unpackages方法将调用ClearAPTSMKBForUnpackage方法来清空APTSMKBForUnpackage属性的内容，然后使用当前解包信息将其初始化（仅初始化一部分，另外一部分由具体的解包方法初始化），APTSMKBForUnpackage属性是TAPTSMKBData结构类型变量。在每一个解包方法中，最终都会调用SaveAPTSMKB方法来保存APTSMKBForUnpackage属性的内容到磁盘文件中，此文件是随机加密的二进制文件并带有校验值，防止随意修改并影响以后自动打包的操作进程。
2014-07-12
自动打包时TGamePackage类对象的方法调用。
1、GamePackages对象不但可以自动解包，也可以自动打包，因此主程序仅创建一个GamePackages对象，用于这两种操作中，而且，自动打包操作界面与自动解包操作界面也相似。
2、当用户在自动打包界面上提供了一个想要进行打包的文件夹名称时，笨笨猪主程序将负责检查此文件夹下是否存在APTSMKB数据文件，这个数据文件就是之前的自动解包操作创建的，注意：自动打包操作只能打包由自动解包解出来的文件，不能打包用户指定的任意文件夹（其实数据文件共有两个，其中一个是陷阱文件）。若存在数据文件，GamePackages对象将调用ClearPackageGrid方法来当前清空打包界面上的文件信息显示区，这个显示区域与自动解包界面上的显示区域类似。之后继续调用LoadAPTSMKB方法来加载并解析数据文件，并保存在APTSMKBForPackage属性中，APTSMKBForPackage属性是TAPTSMKBData结构类型变量，用于保存自动打包所需要的必要信息。再之后继续调用InitPackageGridTitle方法来初始化显示区域的网格标题，由于每种资源包格式的信息并不相同，因此在进行每次自动打包操作时都需要调用。最后调用Packages方法来提取需要打包的文件，Package方法实际上是一个包装器方法，具体的打包操作将转移到打包算法ID所对应的打包方法来最终完成。每一种打包方法都具有两个分支，一个是提取需要打包的文件，一个是自动打包，这里走第一个分支。
3、一旦上述步骤完成之后，就表示自动打包操作已经完全准备好了，可以打包了。当用户在打包界面上提供了一个打包存盘路径时，GamePackages对象将调用Packages方法来进行自动打包，这时走第二个分支。
aacoz 发表于 2014-7-9 13:20 static/image/common/back.gif
楼主的工具能解包《王国保卫战》吗？（Kingdom Rush）http://bbs.3dmgame.com/thread-4370067-1-1.html
这 ...
简单看了一下，此游戏使用unity3d引擎，解包算法正在集成中，请近期关注笨笨猪的最新版本。
SiMaKuangBiao 发表于 2014-7-15 07:26 static/image/common/back.gif
简单看了一下，此游戏使用unity3d引擎，解包算法正在集成中，请近期关注笨笨猪的最新版本。 ...
帖子已收藏时刻关注更新:D感谢大神
2014-07-15
制作中文字库只是笨笨猪软件的辅助功能，在开发顺序上属于次要位置，但是在代码实现上却比较麻烦，需要解决的问题很多，困难很大，简要说明如下：
1、大部分游戏使用的字库属于图片字库，这种字库类型有一个特点，就是必须具有与图片字库相互匹配的索引文件，在这种情况下，制作中文字库的任务分配成了统筹组比较头疼的问题（这里指手工打造的情况，为了追求字库的显示效果，有些时候手工打造是必须的，因为通用字库程序达不到要求）。技术组可以很好的处理索引文件，但是并不能很好的处理图片字库（缺乏美工基础）；美工组可以很好的处理图片字库，但是并不能很好的处理索引文件（缺乏技术基础）。更主要的问题是，图片字库与索引文件的匹配关系在这种情况下并不明朗，相关匹配和重新制作（比如更换字体或大小）会占用大量时间。
笨笨猪软件倾向于技术组或统筹组来承担制作中文字库的任务，为此，第一，笨笨猪软件需要自动化美工任务（解决技术组缺乏美工基础的问题），第二，笨笨猪软件需要集成图片字库与索引文件的匹配规则，设计目标就是，任意图片字库可以匹配任意索引文件，用户的主要操作就是简单的选择。
困难点：第一，为了能够自动化美工任务，在设计时就需要确定使用何种图形开发技术；第二，与引擎算法的问题相同，匹配规则的持续集成需要较长的时间才能达到通用的程度。
2、制作中文字库功能需要基准字体才能执行后续操作，笨笨猪软件不可能提供数字化仪来让用户从零开始，也没有必要。因为笨笨猪软件运行于Windows平台，因此，使用Windows操作系统支持的字体作为基准字体是一个不错的选择，但是，制作中文字库功能本身对基准字体有着严格的标准（主要为了代码开发简洁性考虑），这些标准导致笨笨猪软件不能直接将Windows字体作为基准字体使用，必须经过必要的转换才行，说明如下：
第一，Windows字体的类型主要分两种，即位图字体和轮廓字体，笨笨猪软件只使用轮廓字体进行转换。轮廓字体又分为多种格式，包括：ttf格式（TrueTypeFont）、otf格式（OpenTypeFont）、ttc格式（TrueTypeFontCollection）、otc格式（OpenTypeFontCollection）和PostScript格式。笨笨猪软件的基准字体使用单一字体模型，因此，ttc格式和otc格式不能进行转换，从笨笨猪软件的设计上来说，基准字体倾向于使用了TrueType曲线的OTF格式，同时兼顾老式的TTF格式和使用了PostScript曲线的OTF格式。
第二，笨笨猪软件的基准字体仅支持统一码编码，因此，那些使用了GB2312编码或GBK编码的Windows字体必须经过转换才能成为基准字体。
第三，很多索引文件格式中具有facename属性，笨笨猪软件需要基准字体本身就具有可控并唯一的facename名称，以便在制作中文字库时进行修改或替换，防止在操作系统环境中引起字体冲突。
困难点：第一，需要彻底了解Windows的字体格式；第二，GB2312编码或GBK编码到统一码编码的转换规则很难设计；第三，基准字体的集成结果可能达到好几百兆大小，上传下载是一个很大的问题。
3、除了第1点提到的图片字库之外，还必须能够制作Windows系统字库（使用统一码编码，基于TrueType曲线的OTF字库）、其他格式的轮廓字库（例如：mvec格式）、二进制字库等等，总之，能够制作的字库类型需要随着游戏引擎算法的增加而增加，同时，所有的字库类型必须支持精简字库。
4、针对图片字库，笨笨猪软件需要支持字体特效，包括：常规的粗体、斜体以及旋转、阴影、描边、位图填充、自定义颜色等等。
5、为了得到更好的图形质量，笨笨猪软件主要使用Direct2D图形技术，但是这种技术仅在Windows7或以上的操作系统中才提供，作为兼容手段，笨笨猪软件同时也提供了GDIPlus图形技术，保证了制作中文字库操作上的一致性，但是，最终结果的质量是有一定差异的，这是由图形技术本身所决定的，并不是笨笨猪的问题，因此，建议在Windows7操作系统上运行笨笨猪软件。
不知道最终的版本会不会成为：通过软件汉化，然后玩自己喜欢的游戏。
hy88120 发表于 2014-7-15 18:33 static/image/common/back.gif
不知道最终的版本会不会成为：通过软件汉化，然后玩自己喜欢的游戏。
在游戏汉化过程中，笨笨猪可以解决技术问题，管理平台可以解决管理问题，但工作组（翻译组、美工组、视频组、测试组）的任务是不可能自动化的。所以，您的愿望无法实现。
SiMaKuangBiao 发表于 2014-6-28 16:55 static/image/common/back.gif
您的想法和策略很好，但是稍微有点天真了，在现实世界中不太可能实施，理由如下：
1、网站建设需要投入资 ...
我认为他的意见并不天真。其实正如你说。烂尾是汉化的一大问题。
我认为全民汉化重要的就是全民二字。说起来很简单，但实际并不简单。
比如。很多人对汉化有兴趣。但实际下决心开始做了。才发现，其工作量远非一个人能完成。程序是一方面。内容才是最关键的。
而这个时候。实际上最需要的是什么？是帮助。其实我觉得这和现在的众筹是一个性质、人的力量小吗？人的力量一点不小。
可是对这种非专业性质而言。每个人付出多少。就是一个很值得关注的问题。烂尾的主要原因之一我认为就是量超出了可接受范围的必然结果。
无论你把软件做的多么精良也无法避免这个问题。
最后，这个软件只能起到两个作用，1.汉化组的工具。2.小型，微型游戏的汉化平台。作为1.其实用处不大。专业汉化组有足够好的制作流程和经验。可能并不需要这类软件。作为2.会有一些作用。但实际上稍微靠谱一点的游戏，文本量都不会少。
其实，楼上说的这种很像众筹。我认为是一个相当值得重视的方向。每个人付出不多。但因为基数大，最后依然是个强大的力量。
而实际上。需要花心思的主要地方和你说的并无太大偏差。1，友好的技术支持。应该把汉化需要的技术等级降到大众都可以接受的程度。并尽可能友好。
2.先进的组织模式。这个是重中之中、以下是我的一些个人看法。希望与你分享。
众筹是我认为一个非常好的适合汉化的模式。我认为理想的模式是。从参与者角度出发。在平台上登陆账号后。可以选择自己喜欢的游戏。
然后查看现在项目的进度。可以看到总的进度表。和各分支的进度表。根据参与者的喜好。可以随机马上获得一份以事先切割好的工作单。或选择自己喜好的分支类别。按类别进行工作筛选。完成工作后提交。审核完成后，参与者可以获得项目贡献分，以及对整个项目进度提升的百分比数值。
贡献度就是个人的荣誉象征。将来也能基于此对贡献度大的参与者进行奖励。
在项目中，我的观点是。士气最为重要。很多时候因为项目长期看不到进展而导致士气低落。到后来不了了之。能看到项目进度不断增长，和看到自己的付出对项目进度的增长。对士气的提升是巨大的。因此快速的信息反馈尤其重要。
以上是我提出的一些个人观点。我知道很多实现起来并不简单。但砖瓦总是慢慢堆砌起来的。我想有个美好的愿望总是一个良好的开端。
与君共勉
LZ能不能搞热门的UNITY和XNB游戏解包打包……这两个是老大难，也是现在的热门工具，做了应该可以汉化很多作品
09年的时候曾经有一位技术尝试做一个汉化平台，初步模型也出来了，然后。。。。就没有然后了。。。
本帖最后由 ugogo 于 2014-7-17 12:26 编辑
笨笨猪工具箱 久闻大名啊目前这个测试版是只有解包和打包的功能么
双字节字符的显示的问题怎么解决呢
donzerog 发表于 2014-7-16 22:25 static/image/common/back.gif
LZ能不能搞热门的UNITY和XNB游戏解包打包……这两个是老大难，也是现在的热门工具，做了应该可以汉化很多作 ...
unity的算法比较复杂，分析过程需要一段时间，正好@aacoz坛友也需要，我争取7天内更新版本加入。
SiMaKuangBiao 发表于 2014-7-17 19:43 static/image/common/back.gif
unity的算法比较复杂，分析过程需要一段时间，正好@aacoz坛友也需要，我争取7天内更新版本加入。 ...
感谢无私分享，期待你的作品
wdtd 发表于 2014-7-16 22:20 static/image/common/back.gif
我认为他的意见并不天真。其实正如你说。烂尾是汉化的一大问题。
我认为全民汉化重要的就是全民二字。说 ...
感谢您的建议，所谓贪多嚼不烂，目前的重点还是先把笨笨猪做好，以期先达到通用的程度，然后是管理平台的开发，至于其他方面的考虑只能以后看情况了。
ugogo 发表于 2014-7-17 12:09 static/image/common/back.gif
笨笨猪工具箱 久闻大名啊目前这个测试版是只有解包和打包的功能么
双字节字符的显示的问题怎么解决呢
笨笨猪的测试版采取功能逐步开放的原则，稳定并完善的功能最终都会开放出来的。
关于单字节汉化的问题，由于笨笨猪注重于此功能的自动化和傻瓜化，因此需要很多单字节游戏本体来分析归一化问题，目前还在开发阶段，不会立即开放出来，关于单字节汉化的技术实现问题，随着归一化的完结，会在本贴中继续阐述和说明的。
有种开源的感觉。
uwmnth 发表于 2014-7-21 22:02 static/image/common/back.gif
有种开源的感觉。
笨笨猪是免费软件，可以自由使用或分发，但是并不开放源代码，也不承担任何责任归属问题。
2014-07-24
应几位坛友的要求，笨笨猪需要优先集成Unity3D引擎的自动解包和自动打包，因此放下了一些原来的任务，集中时间研究了一下Unity3D引擎算法，游戏本体使用aacoz坛友提供的王国保卫战（Kingdom Rush）。Unity3D引擎对assets类型的资源包的处理有多个版本，王国保卫战游戏使用了9号版本，因此笨笨猪首先集成9号版本，至于其他版本（1-8号），只要有合适的游戏本体可供研究，也将陆续集成。
总的来说，Unity3D引擎算法针对汉化任务是比较恶心的，主要体现在两个方面：第一，资源包的格式多达9个版本，以后的新引擎版本可能还要增加，这导致自动解包和自动打包也要实现多个不同版本才能处理所有使用Unity3D引擎的游戏；第二，这是最恶心的地方，Unity3D引擎对其使用的原始素材文件进行了自动分类，类型多达几百种，在生成assets资源包时还进行了序列化处理，也就是说，按照常规手段解包出来的文件并不是原始文件，而是序列化之后的文件，这种文件是不能直接用来汉化的，必须经过反序列化处理才行，而有的类型的序列化方案还有多种，互不兼容，这些不同的类型和序列化方案相互引用和叠加在一起，搞得无比复杂，这可能就是目前还没有出现针对Unity3D引擎的通用汉化程序的原因，尤其是自动打包。下面就详细说明一下本人的研究结果（仅针对9号版本），如有不当之处，欢迎同行指正。
本人所接触的大部分资源包都可以分解成三个部分，即：文件头、文件表和文件数据块，assets资源包也不例外，列举如下：
assets资源包9号版本的文件头共20字节，顺序分成5个部分。
第一部分，4字节大序端整数，表示文件表的实际长度，此值在解包时可忽略，打包时计算生成。注意：这个实际长度并不是文件表在资源包中的字节长度，原因是文件表数据在存储时需要加上文件头长度并进行16字节对齐（例如，如果文件表实际长度为5字节，那么在资源包中存储时将占用12字节，而第一部分的数值是5，不是12）。
第二部分，4字节大序端整数，表示资源包的字节长度，此值在解包时可忽略，打包时计算生成。注意：由于assets资源包的特殊性，在计算时并不是简单地文件头长度+文件表长度+文件数据块长度，而是文件头长度先加上文件表实际长度，然后进行16字节对齐，若对齐后的字节长度大于或等于4096字节，则直接加上文件数据块长度就是资源包的字节长度，否则，将对齐后的字节长度扩充至4096字节，再加上文件数据块长度。
第三部分，4字节大序端整数，表示资源包的版本号，此值在解包时可忽略，打包时自动填写。
第四部分，4字节大序端整数，表示文件数据块在资源包中的偏移位置，此值在解包时可忽略，打包时计算生成。
第五部分，4字节大序端整数，意义未知，始终为0。
assets资源包9号版本的文件表被顺序分成3个部分，即：文件表表头、文件表和文件表杂项。
第一部分，文件表表头共24字节，意义如下：8字节数据表示Unity3D引擎版本描述字符串；12字节数据意义未知，打包时原样填写；4字节整数，表示文件表中的信息项分组数量。
第二部分，常规文件表本身，其中的每一组信息项占用20字节，意义如下：4字节整数，表示文件在资源包中的索引；4字节整数，表示文件内容在文件数据块中的起始偏移位置；4字节整数，表示文件的字节长度；4字节整数，表示Unity3D引擎自动分类类型；4字节整数，表示Unity3D引擎自动分类子类型。注意：由于Unity3D引擎的文件表中不提供文件名称信息，因此在解包存盘时需要合成文件名，方式为：第一部分，去掉后缀的资源包名称；第二部分，定长索引值；第三部分，类型值；第四部分，子类型值。这样的话，解包时可以确定唯一的存盘文件名，打包时通过解析文件名就可以正确还原索引和类型，并且能够保证其在资源包中的存储顺序与解包前一致。
第三部分，文件表杂项，表示本资源包所引用的其它相关资源包的信息。解包时直接忽略，打包时原样填写即可。
assets资源包9号版本的文件数据块就是顺序存储的文件内容本身，根据对齐规则，文件数据块和文件表之间可能有一段间隔。
根据上述分析结果，笨笨猪就可以轻松实现自动解包和自动打包，但是这样直接解包出来的文件是经过了Unity3D引擎序列化处理的，不能直接进行汉化，因此，笨笨猪需要在解包时就自动进行反序列化处理，以便解包出真正的原始文件，同时，在打包时也要自动进行相应的序列化处理，以便符合Unity3D引擎的资源包规则，这样的话才能符合笨笨猪的宗旨（为汉化小白提供技术支持，任何人都可操作）。
但是，Unity3D引擎的序列化方案多达几百种，没有时间全部分析，只能进行筛选，原则是：解包时仅对可汉化数据进行反序列化处理，其他数据原样输出。所谓的可汉化数据就是那些包含对话文本数据的文件（用于中文翻译）、包含图片数据的文件（用于美工修图）、包含视频数据的文件（用于加中文字幕）、包含字库数据的文件（用于中文字库）。只要研究出Unity3D引擎对上述这些文件的自动分类类型和序列化方案（研究范围大大缩小），那么解包和打包就可以按要求进行自动化处理了。
对于Unity3D引擎的类型研究，主要参考了引擎API文档，地址如下：http://docs.unity3d.com/Documentation/Manual/ClassIDReference.html，感兴趣的可以看一下，而对于指定类型的序列化方案研究，主要通过OD调试器软件的反汇编分析进行。
根据目测观察API文档，文本文件的类型是：编号49，TextAsset，文本包；编号102，TextMesh，文本网格；编号132，GUIText，界面文本。图片文件的类型是：编号27，Texture，纹理；编号28，Texture2D，2D纹理；编号131，GUITexture，界面纹理；视频文件的类型是：编号74，AnimationClip，动画资源；编号152，MovieTexture，视频纹理；字库文件的类型是：编号128，Font，字库。接下来详细说明一下这些类型的序列化方法，研究本体是王国保卫战游戏，资源包版本是9号版本，注意：下面的序列化方法可能不适合其他版本。
提示：在所有的序列化方案中，凡是涉及到字符串的地方，其前部都有4字节的字符串实际长度指示，但字符串本身在存储时需要4字节对齐。
好帖要顶
2014-07-30
文本文件的序列化方案研究结果：
1、类型编号49，类型名称TextAsset，此类型不仅仅包括文本，还可以包含图片、视频、字库或其他数据，反序列化后统一文件后缀为xml。
此类型的序列化数据被顺序分成3个部分：第一部分，原始文件的名称（4字节整数，表示原始文件名称的实际长度，之后是原始文件名称）；第二部分，原始文件内容（4字节整数，表示原始文件的长度，之后是原始文件内容，注意：不执行对齐操作）；第三部分，原始文件的路径（4字节整数，表示原始文件路径的实际长度，若长度为0，则后面没有数据，否则是原始文件路径）。最后再执行三部分总和字节的4字节对齐。在反序列化处理时，直接将第二部分中的原始文件内容解包成存盘文件，其他部分输出到笨笨猪的数据文件中，用于打包时自动进行计算和序列化。
2、类型编号102，类型名称TextMesh，此类型包含对话文本数据，反序列化后统一文件后缀为txt。
此类型的序列化数据被顺序分成13个部分：第一部分，游戏对象指针（4字节整数，表示ID值，4字节整数，表示另一个ID值）；第二部分，对话文本（4字节整数，表示文本实际长度，之后是对话文本）；第三部分，表示Z轴偏移量（4字节浮点数）；第四部分，表示字符大小（4字节浮点数）；第五部分，表示行间距（4字节浮点数）；第六部分，表示锚点（2字节整数）；第七部分，表示对齐方式（2字节整数）；第八部分，表示Tab宽度（4字节浮点数）；第九部分，表示字体大小（4字节整数）；第十部分，表示字体样式（4字节整数）；第十一部分，表示是否为富文本（4字节布尔型）；第十二部分，字库指针（4字节整数，表示ID值，4字节整数，表示另一个ID值）；第十三部分，表示文本颜色（4字节整数）。在反序列化处理时，直接将第二部分中的对话文本解包成存盘文件，其他部分输出到笨笨猪的数据文件中，用于打包时自动进行计算和序列化。
3、类型编号132，类型名称GUIText，因为游戏本体未包含此类型，暂时无法研究。
2014-07-30
图片文件的序列化方案研究结果：
1、类型编号27，类型名称Texture，因为游戏本体未包含此类型，暂时无法研究。
2、类型编号28，类型名称Texture2D，此类型包含图片数据，反序列化后根据已知图片类型添加相应后缀名称，未知类型则原样输出（不进行反序列化）。
此类型的序列化数据被顺序分成14个部分：第一部分，表示原始文件名称（4字节整数，表示原始文件名称的实际长度，之后是原始文件名称）；第二部分，表示图片像素宽度（4字节整数）；第三部分，表示图片像素高度（4字节整数）；第四部分，意义未知（4字节整数，其值为宽度乘以高度，或最小4096）；第五部分，表示图片格式（4字节整数）；第六部分至第八部分，意义未知（4字节整数），第九部分，表示图片数量（4字节整数），第十部分，意义未知（4字节整数），第十一部分，表示图片设置（共16字节），第十二部分，意义未知（4字节整数），第十三部分，表示颜色空间（4字节整数），第十四部分，表示图像数据（4字节整数，表示图像数据大小，最小为4096字节，之后是实际的图像数据）。在反序列化处理时，直接将第十四部分中的图像数据扩展上已知图片类型的文件头后解包成存盘文件，其他部分输出到笨笨猪的数据文件中，用于打包时自动进行计算和序列化。
视频文件的序列化方案研究结果：
1、类型编号152，类型名称MovieTexture，因为游戏本体未包含此类型，暂时无法研究。
字库文件的序列化方案研究结果：
1、类型编号128，类型名称Font，此类型包含字库数据，反序列化后根据字库类型添加相应后缀名称（ttf或otf）。
此类型的序列化数据被顺序分成19个部分：第一部分，表示原始文件名称（4字节整数，表示原始文件名称的实际长度，之后是原始文件名称）；第二部分，意义未知（4字节整数）；第三部分，表示字距调整（4字节浮点数）；第四部分，表示行间距（4字节浮点数）；第五部分，表示字符间距（4字节整数）；第六部分，意义未知（4字节整数）；第七部分，意义未知（4字节整数）；第八部分，表示默认材质文件（4字节整数，表示ID值，4字节整数，表示另一个ID值）；第九部分，意义未知，估计是使用图片字库时的字符定义（4字节整数，表示字符数量，若为0，表示没有字符定义，否则每个字符将顺序占用41字节）；第十部分，表示字库图片（4字节整数，表示ID值，4字节整数，表示另一个ID值）；第十一部分，表示字距调整表（4字节整数，表示字符对数量，若为0，则后面没有子项数据，否则，之后是连续的子项，每个子项占用8字节）；第十二部分，意义未知（4字节浮点数）；第十三部分，表示字体数据（4字节整数，表示字体数据大小，若为0，则后面没有字体数据，否则之后是字体数据，难道使用外置字体？是放在系统字体目录下？还是游戏目录下？）；第十四部分，表示字体大小（4字节浮点数）；第十五部分，意义未知（4字节浮点数）；第十六部分，表示字体样式（4字节整数）；第十七部分，表示字体名称（4字节整数，表示名称数量，每一个名称是：4字节整数，表示字体名称实际长度，之后是字体名称）；第十八部分，表示相关的字体（4字节整数，表示相关字体数量，若为0，则后面没有数据了，否则，每一个相关字体数据是：4字节整数，表示ID值，4字节整数，表示另一个ID值）；第十九部分，表示字体渲染模式（4字节整数）。在反序列化处理时，直接将第十三部分中的字体数据解包成存盘文件，其他部分输出到笨笨猪的数据文件中，用于打包时自动进行计算和序列化（可能有些数据在打包时可以丢弃，比如，第九部分、第十一部分、第十三部分、第十八部分，这些可丢弃的数据包括了字体数据本身（使用外置字体？需要进一步研究），可以有效缩小字体文件的体积，而第十七部分可能是字体文件的facename属性，手工替换时是比较麻烦的，最好与笨笨猪的中文字库功能配合使用）。
音频文件的序列化方案研究结果：
1、类型编号83，类型名称AudioClip，此类型包含音频数据，反序列化后根据已知音频类型添加相应后缀名称，未知类型则原样输出（不进行反序列化）。
此类型的序列化数据被顺序分成7个部分：第一部分，表示原始文件名称（4字节整数，表示原始文件名称的实际长度，之后是原始文件名称）；第二部分，表示音频格式（4字节整数）；第三部分，表示音频类型（4字节整数）；第四部分至第五部分，意义未知（共4字节）；第六部分，意义未知（4字节整数）；第七部分，表示音频数据（4字节整数，表示音频数据的大小，之后是实际的音频数据）。在反序列化处理时，直接将第七部分中的音频数据解包成存盘文件，其他部分输出到笨笨猪的数据文件中，用于打包时自动进行计算和序列化。
针对王国保卫战游戏本体的序列化方案研究到此结束，开始编码开发。
PS：Unity引擎太麻烦了。
厉害，大神！！！
支持啊。。。。。。。
2014-08-02
表哥本人也经历过汉化组的聚散分合，感触颇深，闲来赋词一阕，与君共勉！，能看懂的且行且珍惜，看不懂的一笑而过吧。
【
忽闻合纵表哥狂。键玄黄，动穹苍。翠羽红衫，长啸縠南岗！三尺春秋弹指罢，重相见，是刘郎。
笑将泪眼看雄张。似寒霜，信无妨。猛犸临风，再铸汉家唐！永记谆谆言在耳，东北望，匿天狼。
】
:D翻页了:D