水平有限,谁有兴趣谁做下去

本来以为我可以很容易的编一个支持中文的解压软件出来,没想到自己学艺不精,编出来的软件慢得要死(大概要10分钟以上吧,还可能死机) 。
一直都不大会DEPHI(没有认真学过),对于在stream中如何搜索指定字符串不太懂,自己编的算法又不行 。如果用逐字节的读取方法,又会太慢 。
现在贴出来我对GX10N备份DAT文件结构的一点点心得 。
首先要有一款16进制的编辑器,如HEX Workshop 。
在DAT文件中,所以library(前集中讲到包含铃声和图片)的文件,都是以4C420100开头的 。4C42的ASC码即为LB(library的缩写) 。JAVA以JV(4A56)开头,电话本则以PB(5042)开头 。
那么要搜寻出图片和铃声,首先就要找出4C420100的地址 。
用HEX32打开手机备份文件DAT,如图 。
按下F3,搜索4C420100,类型选“十六进制数值” 。
搜索结果如下 。(屏幕右下为查找结果栏,当然也可以是比较、检验、书签和输出等 。)
双击00002F71,可以立即跳转到该地址 。
可以看到从2F70开始,第五个字节“0D”为该文件在手机中的序号(自动取得的) 。
而十六进制串值300031002D00310031002D00300034005F00320030002D00350030002D00330036002E006A0070006700的ASC码为0.1.-.1.1.-.0.4._.2.0.-.5.0.-.3.6...j.p.g. 。因为GX10N为中文手机,所以在编码上使用了GB码,上述编码在中文系统下解码就是01-11-04_20-50-36.jpg 。而在后缀名的是“DF440000082001600101DF44”,其中第一二字节或倒数一二字节“DF44”按高低转换则是十六进制“44DF”,换算成十进制就是117631,刚才就是这个文件的长度 。紧随其后的就是文件内容了 。JPEG的文件头都是固定的,“FFD8FFE101104578696600004D4D002A000000080006011A……” 。
此文件长度为17631,而GX10N第一个存储区域的大小为11273,其中在文件名前面有11个字节,在文件名后面有12个字节,这个文件名长度为42个字节,那么紧接着的图片只有11273-11-42-12=11208个字节了 。还有17631-11208=6423个字节没有看到 。这就是我们用GX10Extract解352×288只能有一半图象有原因 。
那么剩下的另一半去哪儿了呢?
双击查找栏的地址0000CFB6 。
可以看到4C4201005D005D19F7…… 。其中4C420100为LB的抬头,不管它,“5D”就是对应于“0D”的 。“19F7”则是这一段文件的长度,换算成十进制就是6647(这个又不需要高低转换) 。而刚才剩下的文件有6423个字节,6647-6423=284 。为什么呢,把文件往后面翻 。
可以看到GX10自动在文件后面补了284年空字节(GX10是补了184个空字节,可能是为了与后面的隔开吧) 。
也就是说01-11-04_20-50-36.jpg这一张图片,系统总共用到了两个存储空间,第一个定长为11273个字节,以0D为编号,其中还有65个字节用于定义文件头,实际图片只有11208个字节 。第二个空间,以5D为编号,有9个字节用于定义文件头,实际占用空间为9 6423 284=6716 。而6423 284又刚好等于第二个空间的第八、九个字节的数值 。
当然,如果图片加文件头小于11273个字节的话,那么图片只占用一个空间,而第一个空间的长度就是文件头 文件的内容长度,而不是定长11273 。
实际上120×160的图片只有5、6K,都是一个空间就能存得下 。而352×288的图片则有17K左右 。需要两个空间 。我们从网上下的图片则有可能超过这个数值,达到三个空间 。第三个空间的存储格式与第二个空间相同,如果图片第一个存储空间编号为0D,第二个空间编号为5D,第三个空间的编号就可能为0D 50 50(十六进制)=AD(没有试过) 。
知道了这个,就可以手动把352×288的图片提取出来 。
【水平有限,谁有兴趣谁做下去】

推荐阅读