最近研究资源文件发现好几个游戏的文件都喜欢用这样的格式7 f% D0 C1 t" s; T; a" z: w1 `
6 H* D5 j: _4 n; W7 ?文件头. Y. v# ]. D/ l9 }' o
数据块(zlib)0 D5 ?3 @3 N5 C' n
文件名表5 I8 h+ r5 {- G p! |/ q) \) H) b& C
% v# g: ~! ~& b% p: A其中文件头格式为
5 R" Q( {% _$ w9 X4 v: D
1 C+ V: f% C" @9 I7 s2 J' \) MIDSTRING(P1)+资源文件版本号packver(4)+文件数量files(4)+文件名表地址指针RES_START(4)+NULL(P2)
3 n9 ?* Y( G: S! e5 p# b W4 ?4 S
文件名表格式为1 Y$ y1 n* l" o! t1 t0 j3 L
; x! o# p. m d: K% G; b$ ^* k文件名NAME(F1)+文件压缩大小ZSIZE(4)+文件解压大小SIZE(4)+文件在资源文件长度FSIZE(4)+文件数据地址偏移OFFSET(4)+filever文件版本号(4)+NULL(F2)5 p$ t8 Q+ U1 O
/ a3 n% ?: s0 Z8 q& t) M
一般情况下,文件压缩大小ZSIZE=文件在资源文件长度FSIZE,但是有时候后者较长,可能是预留空间用于更新维护。: C. Q9 b) V7 f; s3 d! b
' E y* \8 S7 i: ~, w: N这种格式的好处是,当资源文件很大的时候更新维护都比较方便,把新的文件压缩后插入数据块的末尾,然后只要在文件名表后加上更新文件的文件名表就行,然后修正文件数量,其他数据基本可以不动。
( f0 K9 K( ^; W. H! C- n' P+ d+ u: V; Z1 R& \
所以这种文件解包方法都可以这样,略有不同的可以稍微修改下; E( T7 `0 m# u
getdstring IDSTRING 0xP1( m; e" q$ @. [4 ?+ n5 M1 N
get packver long7 A% P; v g% G5 G! j8 R
get FILES long
! Y3 M1 Q5 R( Y/ m' I) [7 vget RES_START long- v6 f* j% _; q6 q% z6 n. ?) f2 }3 }
getdstring NULL 0xP25 j' S1 Q! Q" Z8 Z! |! c+ ]# ~
+ w, D" `7 P% w( a. Q9 p: g7 r
goto RES_START0 i3 F$ |5 [' P
for i = 0 < FILES) j% Q+ A2 U8 Z1 w* B
getdstring NAME 0xF1
- Z, a' o0 ]0 M( C9 Z2 b1 Aget ZSIZE long
) y3 T% \8 M1 n7 J8 Aget SIZE long( X1 H6 v+ C; M6 A5 U
get FSIZE long
7 Z" t, [! s* `; s6 l( `; sget OFFSET long* S, i7 C# e- B2 J. J
get filever long- |* ~& l7 a& b0 A, t9 T" P
getdstring NULL1 0xF24 E* a; s! s. k
clog NAME OFFSET ZSIZE SIZE q O P5 @2 _5 V
next i1 Y1 Q: Y3 E6 G
* c8 ~+ {; J& A) Z0 s' ^! S( @现在,想求高人设计个通用的打包工具,命令行或GUI都可以
0 y( `( q' @* r# P8 W( c0 y其中变量IDSTRING P1 P2 F1 F2键盘获取,其他变量根据待打包文件修正。+ c$ J0 o6 s/ m( z0 o0 E
文件版本号Packver、Filever通过读取文件录入,没有没有该文件直接置NULL,FSIZE直接等于SIZE方便处理。 |