批处理之家's Archiver

plp626 发表于 2011-5-11 23:00

【出题】批处理实现16进制数据最小体积存储

[code]4D5A90000300000004000000FFFF0000B800000000000000400000000000000000000000000000000000000000000000000000000000000000000000E00000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E20444F53206D6F64652E0D0D0A2400000000000000484CF28A0C2D9CD90C2D9CD90C2D9CD90C2D9CD90F2D9CD9633296D9072D9CD98F3192D90D2D9CD9633298D90F2D9CD90C2D9DD91C2D9CD93A0B96D90D2D9CD9526963680C2D9CD9000000000000000000000000000000000000000000000000504500004C0103002B63CA4D0000000000000000E0000F010B0106009001000030020000000000008E02000050020000E003000000004000100000001000000004000000000000000400000000000000100600005002000000000000030000000000100000100000000010000010000000000000100000000000000000000000340400003C0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000E0030000440000000000000000000000000000000000000000000000000000002E7465787400000082010000500200009001000050020000000000000000000000000000200000602E72646174610000CA010000E0030000D0010000E0030000000000000000000000000000400000402E646174610000005C000000B005000060000000B0050000000000000000000000000000400000C0837C2404037D0F68C4054000E827000000596A0158C38B44240833C95151FF7008FF700451E85201000068C0054000E8040000005933C0C3FF25E0034000558BEC6AFF682804400068C003400064A100000000506489250000000083EC205356578965E88365FC006A01FF150C04400059830D00064000FF830D04064000FFFF15080440008B0DFC0540008908FF15040440008B0DF80540008908A1000440008B00A308064000E8C3000000833DE005400000750C68BC034000FF15FC03400059E89400000068BC05400068B8054000E87F000000A1F40540008945D88D45D850FF35F00540008D45E0508D45D4508D45E450FF15F403400068B405400068B0054000E84C000000FF15F00340008B4DE08908FF75E0FF75D4FF75E4E8DFFEFFFF83C4308945DC50FF15EC0340008B45EC8B088B09894DD05051E80F0000005959C38B65E8FF75D0FF15E4034000FF25E8034000FF25F803400068000003006800000100E80D0000005959C333C0C3C3FF2510044000FF2514044000FF251C0440000000000000000000000000000000B4040000C8040000D0040000DE040000E6040000F6040000060500001205000026050000360500004605000054050000660500007A05000000000000880500000000000000000000FFFFFFFF7E03400092034000700400000000000000000000BC040000E0030000AC04000000000000000000009E0500001C0400000000000000000000000000000000000000000000B4040000C8040000D0040000DE040000E6040000F6040000060500001205000026050000360500004605000054050000660500007A050000000000008805000000000000A1027075747300004D53564352542E646C6C0000D3005F657869740048005F5863707446696C74657200490265786974000064005F5F705F5F5F696E6974656E760058005F5F6765746D61696E61726773000F015F696E69747465726D0083005F5F736574757365726D61746865727200009D005F61646A7573745F6664697600006A005F5F705F5F636F6D6D6F646500006F005F5F705F5F666D6F6465000081005F5F7365745F6170705F747970650000CA005F6578636570745F68616E646C6572330000B7005F636F6E74726F6C667000003E0055524C446F776E6C6F6164546F46696C6541000075726C6D6F6E2E646C6C0000000000000000000000000000000000000000000000004F4B210055736167653A20444F574E203C75726C3E203C706174683E000000000100[/code]设计一种编码批处理变量存放方案,将上面的字符信息用尽量少的字符个数储存,当使用的时候,又可以用相应的方案还原。
简单的理解就是类似于数据压缩与解压缩操作。

要求,用cmd的内部命令实现。
----------------------------------------
PS: 这个“设计方案”所含的批处理代码不要过长,体积的计算要把这个“设计方案”所含代码和储存信息一起计算。

当然,如果方案能通用的话,可以适当放宽设计方案所含代码的长度

plp626 发表于 2011-5-11 23:07

[i=s] 本帖最后由 plp626 于 2011-5-11 23:21 编辑 [/i]

PS: 这个“设计方案”所含的批处理代码不要过长,体积的计算要把这个“设计方案”所含代码和储存信息一起计算。

当然,如果方案能通用的话,可以适当放宽设计方案所含代码的长度

-----------------------------------

有人也许会问这个能干什么? 我说下应用,当然还是娱乐,但“娱乐度”比较高,呵呵。

有个霍夫曼编码,可以对所发报文以最短编码存储,我们把他应用到bat2any(利用debug写文件)那个程序里,可以最大限度的压缩文件的体积,

假如有人想把三方工具嵌入到bat中,这样体积可以压缩很多多多。。。。

hanyeguxing 发表于 2011-5-12 12:07

如果源文件是 32 位命令行,直接使用 UPX 压缩

plp626 发表于 2011-5-12 12:43

[b] [url=http://bbs.bathome.net/redirect.php?goto=findpost&pid=78404&ptid=12265]3#[/url] [i]hanyeguxing[/i] [/b]


上面这个exe文件体积就1K多,选择编译的时候我加了/align:16,体积最小模式,upx没法再压缩了

caruko 发表于 2011-5-12 13:24

16*16 =256
一个简单的办法就是使用ACSII码。

DEBUG即可互相转换。

CrLf 发表于 2011-5-12 15:31

同上,相信大家第一反映都差不多,不过我想,无论用ansi码或者什么码来以字典的形式与原始数据一一对应,其根本思路无非是把16进制转换为更高位的进制,以填补用1~2个字节只记录一个十六进制数时浪费的容量。
对于调用第三方、debug、vbs等方法不做评论,因为想必都是可行的,不过我想楼主的意思大概是尽量用纯批的吧。
再说一个大众看法,大家肯定都想到了,只是没说。首先,字典肯定要用到的,再用A个字典里的字符与B个十六进制数对应,不过要知道A:B的最佳比例,就要做一个计算:将能在批处理中识别为单字符的单字节ansi码数量设为N,然后求N与16的最小公倍数,然后...你知道的,不解释

terse 发表于 2011-5-12 15:58

转 Base64码

hanyeguxing 发表于 2011-5-12 18:56

楼主提供的本身就是源文件的 ANSI 。。。

terse 发表于 2011-5-12 19:28

转 Base64码 后文件原来的 2/3

523066680 发表于 2011-5-12 21:24

我看0出现很多次,要不用N个0表示  恩恩

plp626 发表于 2011-5-12 21:30

我目前,理论上,

可以把一楼的数据压缩到1100 字节左右(不含解压代码)

也就是压缩为原来体积的37%左右。

不知大家的结果是怎样的?

CrLf 发表于 2011-5-12 23:26

如果引入有损压缩的概念,压缩比必定更高

batman 发表于 2011-5-13 00:02

[i=s] 本帖最后由 batman 于 2011-5-13 00:57 编辑 [/i]

思路:
0-9的数字就用原值存储(原来用两个字符存储压缩一半),a-z和A-Z全用a-z表示(压缩比视大小写字母比),非数值非字母可见字符用原值存储(原来用两个字符存储压缩一半,),回车换行退格分别用A、B、C存储(压缩一半)。[code]
@echo off&setlocal enabledelayedexpansion
for /f "skip=8 tokens=1*" %%a in (%~fs0) do set "%%a=%%b"
set "str=4D5A90000300000004000000FFFF0000B800000000000000400000000000000000000000000000000000000000000000000000000000000000000000E00000000E1FBA0E00B409CD21B8014CCD21546869732070726F6772616D2063616E6E6F742062652072756E20696E20444F53206D6F64652E0D0D0A2400000000000000484CF28A0C2D9CD90C2D9CD90C2D9CD90C2D9CD90F2D9CD9633296D9072D9CD98F3192D90D2D9CD9633298D90F2D9CD90C2D9DD91C2D9CD93A0B96D90D2D9CD9526963680C2D9CD9000000000000000000000000000000000000000000000000504500004C0103002B63CA4D0000000000000000E0000F010B0106009001000030020000000000008E02000050020000E003000000004000100000001000000004000000000000000400000000000000100600005002000000000000030000000000100000100000000010000010000000000000100000000000000000000000340400003C0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000E0030000440000000000000000000000000000000000000000000000000000002E7465787400000082010000500200009001000050020000000000000000000000000000200000602E72646174610000CA010000E0030000D0010000E0030000000000000000000000000000400000402E646174610000005C000000B005000060000000B0050000000000000000000000000000400000C0837C2404037D0F68C4054000E827000000596A0158C38B44240833C95151FF7008FF700451E85201000068C0054000E8040000005933C0C3FF25E0034000558BEC6AFF682804400068C003400064A100000000506489250000000083EC205356578965E88365FC006A01FF150C04400059830D00064000FF830D04064000FFFF15080440008B0DFC0540008908FF15040440008B0DF80540008908A1000440008B00A308064000E8C3000000833DE005400000750C68BC034000FF15FC03400059E89400000068BC05400068B8054000E87F000000A1F40540008945D88D45D850FF35F00540008D45E0508D45D4508D45E450FF15F403400068B405400068B0054000E84C000000FF15F00340008B4DE08908FF75E0FF75D4FF75E4E8DFFEFFFF83C4308945DC50FF15EC0340008B45EC8B088B09894DD05051E80F0000005959C38B65E8FF75D0FF15E4034000FF25E8034000FF25F803400068000003006800000100E80D0000005959C333C0C3C3FF2510044000FF2514044000FF251C0440000000000000000000000000000000B4040000C8040000D0040000DE040000E6040000F6040000060500001205000026050000360500004605000054050000660500007A05000000000000880500000000000000000000FFFFFFFF7E03400092034000700400000000000000000000BC040000E0030000AC04000000000000000000009E0500001C0400000000000000000000000000000000000000000000B4040000C8040000D0040000DE040000E6040000F6040000060500001205000026050000360500004605000054050000660500007A050000000000008805000000000000A1027075747300004D53564352542E646C6C0000D3005F657869740048005F5863707446696C74657200490265786974000064005F5F705F5F5F696E6974656E760058005F5F6765746D61696E61726773000F015F696E69747465726D0083005F5F736574757365726D61746865727200009D005F61646A7573745F6664697600006A005F5F705F5F636F6D6D6F646500006F005F5F705F5F666D6F6465000081005F5F7365745F6170705F747970650000CA005F6578636570745F68616E646C6572330000B7005F636F6E74726F6C667000003E0055524C446F776E6C6F6164546F46696C6541000075726C6D6F6E2E646C6C0000000000000000000000000000000000000000000000004F4B210055736167653A20444F574E203C75726C3E203C706174683E000000000100"
:lp
set "var=!var!!%str:~,2%!"
if defined str set "str=%str:~2%"&goto lp
set "var=!var:空格= !"
echo !var:跳格=        !
pause>nul&goto :eof
09 跳格
20 空格
21 !
22 "
23 #
24 $
25 %
26 &
27 '
28 (
29 )
2A *
2B +
2C ,
2D -
2E .
2F /
30 0
31 1
32 2
33 3
34 4
35 5
36 6
37 7
38 8
39 9
3A :
3B ;
3C <
3D =
3E >
3F ?
40 @
41 a
42 b
43 C
44 d
45 e
46 f
47 g
48 h
49 i
4A j
4B k
4C l
4D m
4E n
4F o
50 p
51 q
52 r
53 s
54 t
55 u
56 v
57 w
58 x
59 y
5A z
5B [
5C \
5D ]
5E ^
5F _
60 `
61 a
62 b
63 c
64 d
65 e
66 f
67 g
68 h
69 i
6A j
6B k
6C l
6D m
6E n
6F o
70 p
71 q
72 r
73 s
74 t
75 u
76 v
77 w
78 x
79 y
7A z
7B {
7C |
7D }
7E ~
0A A
0D B
08 C
[/code]

hanyeguxing 发表于 2011-5-13 03:40

[b] [url=http://bbs.bathome.net/redirect.php?goto=findpost&pid=78439&ptid=12265]11#[/url] [i]plp626[/i] [/b]


用批处理自身来存储、解压,怎么能不算解压代码呢?

terse 发表于 2011-5-13 11:33

另一思路  把一定长度字符(转为10进制) 除一固定数 储存这个信息

plp626 发表于 2011-5-13 11:48

[b] [url=http://www.bathome.net/redirect.php?goto=findpost&pid=78503&ptid=12265]15#[/url] [i]terse[/i] [/b]


貌似是个新颖的想法, 但我没理解你的思路,能说详细点么?

CrLf 发表于 2011-5-13 13:20

[quote]另一思路  把一定长度字符(转为10进制) 除一固定数 储存这个信息
[size=2][color=#999999]terse 发表于 2011-5-13 11:33[/color] [url=http://bbs.bathome.net/redirect.php?goto=findpost&pid=78503&ptid=12265][img]http://bbs.bathome.net/images/common/back.gif[/img][/url][/size][/quote]
这是有损的,而且十进制数的存储能力似乎反而比十六进制数更低吧

plp626 发表于 2011-5-13 13:27

有损压缩 一般用于图行领域,也没能力研究。

我考虑的是exe可执行文件或者rar压缩文件,当然不能有半点损。

CrLf 发表于 2011-5-13 13:49

10楼的方法看起来不错哦,
另外,可以模仿视频压缩的技术,有一种视频是动态的场景帧数多,静态的场景帧数少
如果是在实战中,很可能连续碰到多个含0?的字节,这时候是不是可以把010201010f0e07记成.05_1211fe7呢?
还有既然都是数字,也许也可以考虑做个函数,将x、y、z放入其中,就能算出后面的一系列数字。这想法跟字典其实还是差不多,但是大概有那么一点区别吧

CrLf 发表于 2011-5-13 13:52

[i=s] 本帖最后由 zm900612 于 2011-5-13 13:57 编辑 [/i]

前面说的有损压缩,我的想法是,有许多字符组合也许不可能出现在16进制编码中的,就像0D0A、0A0A或者0D0D不会出现在由记事本正常输入的txt文件中,那就可以把它们排除在字典之外,这样字典的容量就会提升,这种有损压缩是损字典,不损压缩内容。

hanyeguxing 发表于 2011-5-13 14:04

[i=s] 本帖最后由 hanyeguxing 于 2011-5-13 14:06 编辑 [/i]

由于连续0很多,所有优先处理0:
1,1个0依然记作0
2,2个0按双字节处理,替换为I
3,大于2个的0,则替换为Hnn或Gn,n为0的个数
由于这里0的个数分为3到9之间和10到100之间,所以区分为Hnn和Gn
其次处理连续F,替换为Jn,n为F的个数
再次,以单字符替换多字符(大于等于4),例如替换5F5F为K等
至于剩余的字母是否替换其他双字节字符,个人认为大多没必要了,因为增加的代码量会过高,可以考虑处理出现最多的几个

terse 发表于 2011-5-13 15:34

[i=s] 本帖最后由 terse 于 2011-5-13 15:36 编辑 [/i]

继续对重复字符处理的话  如AAAAAAAA 是否可以这样 %8a%
至于 字符转10进制 处理 有难度
仅处理特殊串 如FFFFFFF[code]set/a N=0xfffffff/0xffffff,R=0xfffffff-n*0xffffff[/code]得商 16 余数 F
这里难度主要是余数的处理  因为余数有 长度等同ffffff长度的情况
转Base64码 后原码的2/3体积  这个应该无损哦

另我认为字符大小写应该区分的[code]
TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAABITPKKDC2c2QwtnNkMLZzZDC2c2Q8tnNljMpbZBy2c2Y8xktkNLZzZYzKY2Q8tnNkMLZ3ZHC2c2ToLltkNLZzZUmljaAwtnNkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQRQAATAEDACtjyk0AAAAAAAAAAOAADwELAQYAkAEAADACAAAAAAAAjgIAAFACAADgAwAAAABAABAAAAAQAAAABAAAAAAAAAAEAAAAAAAAABAGAABQAgAAAAAAAAMAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADQEAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAwAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAggEAAFACAACQAQAAUAIAAAAAAAAAAAAAAAAAACAAAGAucmRhdGEAAMoBAADgAwAA0AEAAOADAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABcAAAAsAUAAGAAAACwBQAAAAAAAAAAAAAAAAAAQAAAwIN8JAQDfQ9oxAVAAOgnAAAAWWoBWMOLRCQIM8lRUf9wCP9wBFHoUgEAAGjABUAA6AQAAABZM8DD/yXgA0AAVYvsav9oKARAAGjAA0AAZKEAAAAAUGSJJQAAAACD7CBTVleJZeiDZfwAagH/FQwEQABZgw0ABkAA/4MNBAZAAP//FQgEQACLDfwFQACJCP8VBARAAIsN+AVAAIkIoQAEQACLAKMIBkAA6MMAAACDPeAFQAAAdQxovANAAP8V/ANAAFnolAAAAGi8BUAAaLgFQADofwAAAKH0BUAAiUXYjUXYUP818AVAAI1F4FCNRdRQjUXkUP8V9ANAAGi0BUAAaLAFQADoTAAAAP8V8ANAAItN4IkI/3Xg/3XU/3Xk6N/+//+DxDCJRdxQ/xXsA0AAi0XsiwiLCYlN0FBR6A8AAABZWcOLZej/ddD/FeQDQAD/JegDQAD/JfgDQABoAAADAGgAAAEA6A0AAABZWcMzwMPD/yUQBEAA/yUUBEAA/yUcBEAAAAAAAAAAAAAAAAAAAAC0BAAAyAQAANAEAADeBAAA5gQAAPYEAAAGBQAAEgUAACYFAAA2BQAARgUAAFQFAABmBQAAegUAAAAAAACIBQAAAAAAAAAAAAD/////fgNAAJIDQABwBAAAAAAAAAAAAAC8BAAA4AMAAKwEAAAAAAAAAAAAAJ4FAAAcBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0BAAAyAQAANAEAADeBAAA5gQAAPYEAAAGBQAAEgUAACYFAAA2BQAARgUAAFQFAABmBQAAegUAAAAAAACIBQAAAAAAAKECcHV0cwAATVNWQ1JULmRsbAAA0wBfZXhpdABIAF9YY3B0RmlsdGVyAEkCZXhpdAAAZABfX3BfX19pbml0ZW52AFgAX19nZXRtYWluYXJncwAPAV9pbml0dGVybQCDAF9fc2V0dXNlcm1hdGhlcnIAAJ0AX2FkanVzdF9mZGl2AABqAF9fcF9fY29tbW9kZQAAbwBfX3BfX2Ztb2RlAACBAF9fc2V0X2FwcF90eXBlAADKAF9leGNlcHRfaGFuZGxlcjMAALcAX2NvbnRyb2xmcAAAPgBVUkxEb3dubG9hZFRvRmlsZUEAAHVybG1vbi5kbGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABPSyEAVXNhZ2U6IERPV04gPHVybD4gPHBhdGg+AAAAAAEATVqQ[/code]

plp626 发表于 2011-5-13 16:08

[i=s] 本帖最后由 plp626 于 2011-5-13 17:18 编辑 [/i]

我目前,理论上,

可以将一楼的数据 至少 压缩 掉 2/3,即压缩为原来体积 1/3 以下(不含解压代码),突破1000字节。

如果再引入字典删去重复,将接近1/4,即压缩到接近900字节或少于900字节。

plp626 发表于 2011-5-13 17:04

特殊编码存放测试[code]

plp626 发表于 2011-5-13 17:04

[code]亗儎厗噲墛媽崕彁憭摂晼[/code]

wankoilz 发表于 2011-5-17 23:04

[i=s] 本帖最后由 wankoilz 于 2011-5-17 23:56 编辑 [/i]

楼上是什么意思,能不能讲解下。
哦...知道了,那是从chcp 437代码页复制过来的特殊符号吧...

caruko 发表于 2011-5-18 01:55

把你的数据转了一下变成UNICODE编码,原来是个MZ头的PE文件,好像是下载用的。
将这些数据导入DEBUG,前面增加2个字节“FF FE”,即可变成新文本,大小1.5k,原文本是2.94k,接近减少一半。
然后将文本附加到bat里 copy /b newfile+my.bat mynew.bat
需要的时候,cmd /U /C more +n mynew.bat >temp
即可导出UNICODE编码文件,去掉FF FE就还原了。

压缩率不高,主要是00 没有做去重复处理。

caruko 发表于 2011-5-18 02:00

原本以为UNICODE 编码占2个字节,也就是4个字符变成一个字符,比起 ASCII 压缩率要高,应该是1/4。

然而字符数目是短了,但是一个字符2字节,实际只减少了1/2。

Demon 发表于 2011-5-31 16:54

[quote]PS: 这个“设计方案”所含的批处理代码不要过长,体积的计算要把这个“设计方案”所含代码和储存信息一起计算。

当然,如果方案能通用的话,可以适当放宽设计方案所含代码的长度

-----------------------------------

有人也许会问这个能干什么? 我说下应用,当然还是娱乐,但“娱乐度”比较高,呵呵。

有个霍夫曼编码,可以对所发报文以最短编码存储,我们把他应用到bat2any(利用debug写文件)那个程序里,可以最大限度的压缩文件的体积,

假如有人想把三方工具嵌入到bat中,这样体积可以压缩很多多多。。。。
[size=2][color=#999999]plp626 发表于 2011-5-11 23:07[/color] [url=http://bbs.bathome.net/redirect.php?goto=findpost&pid=78390&ptid=12265][img]http://bbs.bathome.net/images/common/back.gif[/img][/url][/size][/quote]
直接用二进制不就行了,和原来一样大。

lllsoslll 发表于 2011-11-15 21:35

[code]4d5a9i3l4kffffib8s4/47eme1fba0egb409cd21b8014ccd21546869732070726f6772616d2063616e6e6f742062652072756e20696e20444f53206d6f64652e0d0d0a24s484cf28a0c2d9cd90c2d9cd90c2d9cd90c2d9cd90f2d9cd9633296d9072d9cd98f3192d90d2d9cd9633298d90f2d9cd90c2d9dd91c2d9cd93a0b96d90d2d9cd9526963680c2d9cd9/305045i4c0103gfab0b64e/10eif010b0106g8g1i1g2q7e02i5g2idg3m4h1l1m4t4seg5i5g2r3o1j1n1j1r1/172404i3c/a6dg3i44/362e74657874k7201i5g2i8g1i5g2/1c2j602e7264617461ica01idg3idg1idg3/1c4j402e64617461k3ckag5i4lag5/1c4jc0837c2404027e1f8b44240833c95151ff7g8ff7g451e85101i68bg54he803k59c3ccff25dg34h558bec6aff6818044h68bg34h64a1m50648925m83ec205356578965e88365fcg6a01ff15fc034h59830ddg54hff830dd4054hffff15f8034h8b0dcc054h8908ff15f4034h8b0dc8054h8908a1fg34h8bga3d8054he8c3k833db4054j750c68ac034hff15ec034h59e894k68ac054h68a8054he87fka1c4054h8945d88d45d850ff35cg54h8d45e0508d45d4508d45e450ff15e4034h68a4054h68ag54he84ckff15eg34h8b4de08908ff75e0ff75d4ff75e4e8effeffff83c4308945dc50ff15dc034h8b45ec8b088b09894dd05051e80fk5959c38b65e8ff75d0ff15d4034hff25d8034hff25e8034h68j3g68j1ge80dk5959c333c0c3c3ff25h44hff2504044hff250c044/1fa404ib804icg4ice04id604ie604if604j205i1605i2605i3605i4405i5605i6a05q7805/14ffffffff6e034h82034h6g4/14ac04idg3i9c04/148e05jc04/2ca404ib804icg4ice04id604ie604if604j205i1605i2605i3605i4405i5605i6a05q7805qa10270757473i4d53564352542e646c6cid3g5f65786974g48g5f5863707446696c746572g490265786974i64g5f5f705f5f5f696e6974656e76g58g5f5f6765746d61696e61726773hf015f696e69747465726dg83g5f5f736574757365726d617468657272i9dg5f61646a7573745f66646976i6ag5f5f705f5f636f6d6d6f6465i6fg5f5f705f5f666d6f6465i81g5f5f7365745f6170705f74797065icag5f6578636570745f68616e646c657233ib7g5f636f6e74726f6c667j3eg55524c446f776e6c6f6164546f46696c6541i75726c6d6f6e2e646c6c/304f4b21h1/56[/code]

页: [1] 2

Powered by Discuz! Archiver 7.2  © 2001-2009 Comsenz Inc.