照例，是用HEDIT打開一個(gè)PKX文件來看。
開頭是一句話，這個(gè)文件格式是一個(gè)叫做ZERO的程序員創(chuàng)建的，仰視ZERO三秒！接下來繼續(xù)。
從MOTIONDATA這個(gè)文件夾來看，這里面都是動(dòng)畫動(dòng)作相關(guān)的數(shù)據(jù)。在HEDIT里面，可以看到PKX里面有很多動(dòng)作的名字。然后，跳過這些動(dòng)作名字，可以看到熟悉的"DFX"三個(gè)字母，那些都是TGL文件。
取得DFX的OFS，在前面的表里查找，不過令人失望，里面找不到。
拉到文件尾，很多包裹文件都把文件列表放在文件尾。這時(shí)，我們看到了以字母順序排列的動(dòng)作表。從第一個(gè)名字向上找，找到一個(gè)DFX，就是TGL文件，我們按照TGL文件格式往下推導(dǎo)，結(jié)束點(diǎn)正好在第一個(gè)名字前面。所以我們可以得到文件列表數(shù)據(jù)接口的起點(diǎn)，就是名字的第一個(gè)字節(jié)開始。
我繼續(xù)往下找到第二個(gè)名字，計(jì)算下兩個(gè)名字的距離是284字節(jié)。根據(jù)名字長度沒有標(biāo)記來判斷，這個(gè)文件列表是固定長度的數(shù)據(jù)結(jié)構(gòu)。
繼續(xù)，根據(jù)文件頭上那個(gè)表的第一個(gè)元素的名字猜測，他的數(shù)據(jù)在第一個(gè)DFX文件處。我找到第一個(gè)元素的文件列表中的數(shù)據(jù)，對(duì)比他的DFX文件數(shù)據(jù)的OFS和LENGTH，發(fā)現(xiàn)它的OFS和LENTH保存在文件列表數(shù)據(jù)結(jié)構(gòu)的第0x104位置。從那里開始，順序存儲(chǔ)著64位的Ofs和32位的原始大小，以及32位的壓縮后大小。當(dāng)然這只是猜測。
接下來，我計(jì)算了下尾部的所有文件列表數(shù)據(jù)的長度，除以單個(gè)列表數(shù)據(jù)結(jié)構(gòu)長度，得到了一個(gè)文件數(shù)目。然后，回到頭部，來尋找這個(gè)數(shù)據(jù)。
很顯然，肯定有這個(gè)數(shù)據(jù)的。最終我在 ofs為0x108的地方找到了，是一個(gè)32位的整數(shù)。而他前面，是64位的包文件總長度。用這兩個(gè)，加上文件列表的數(shù)據(jù)結(jié)構(gòu)長度，就可以定位到文件列表的位置了。
好了，有了以上數(shù)據(jù)，PKX文件就可以解開了。不過仍然還有很多數(shù)據(jù)是未知含義的，不過這不影響我們解開PKX文件。下面是文件格式的整體描述：
@packinfo(0x100) {
int64 = packsize
int32 = filecount
int32 = 0
int32 = 2
} * 1
@filedata {}
@infotable(packsize-filecount*284) {
char[10] = name
@filepos(+0x104) {
int64 = offset
int32 = originsize
int32 = compresssize
}
} * filecount
這次挺簡單的，就沒工具了。最后再說下，解出來的是TGL文件。