精华内容
下载资源
问答
  • RAR文件格式的研究

    2012-11-29 15:35:52
    rar 文件格式
  • rar文件格式的研究

    2011-09-07 19:50:52
    非常全面的介绍rar文件格式,压缩过程及加减密过程。
  • RAR文件格式分析

    千次阅读 2020-05-09 15:42:44
    压缩文件通常是一个带有 “.rar” 扩展名的文件RAR的特点包括: RAR通常情况比ZIP压缩比高,但压缩/解压缩速度较慢。 分卷压缩:压缩后分割为多个文件。 固实压缩:把要压缩的视为同一个文件以加大压缩比,代价...

    RAR文件的特点

    RAR通常情况比ZIP压缩比高,但压缩/解压缩速度较慢。
    分卷压缩:压缩后分割为多个文件。
    固实压缩:把要压缩的视为同一个文件以加大压缩比,代价是取用包中任何文件需解压整个压缩包。
    恢复记录:加入冗余数据用于修复,在压缩包本身损坏但恢复记录够多时可对损坏压缩包进行恢复。
    加密RAR 2.0使用AES-128-cbc,(rar5.0以后为AES-256CBC)。之前RAR的加密算法为私有。目前均未被直接攻破(至少没有公开),没有密码时只有暴力破解。

    参考百度百科

    RAR文件码流分析

    下面的文件格式分析是基于RAR4.x,并不是RAR5.0
    RAR 5.0签名和RAR4.x的签名不一样
    RAR 5.0签名由8个字节组成:
    0x52 0x61 0x72 0x21 0x1A 0x07 0x01 0x00
    比较一下
    RAR 4.x 签名由7字节组成:
    0x52 0x61 0x72 0x21 0x1A 0x07 0x00

    一个RAR4.x压缩文件由若干可变长度的块组成
    常见块类型如下:

    标记块:HEAD_TYPE=0x72
    压缩文件头:HEAD_TYPE=0x73
    文件头:HEAD_TYPE=0x74
    旧风格的注释头:HEAD_TYPE=0x75
    旧风格的用户身份信息:HEAD_TYPE=0x76
    旧风格的子块:HEAD_TYPE=0x77
    旧风格的恢复记录:HEAD_TYPE=0X78
    旧风格的用户身份信息:HEAD_TYPE=0X79
    子块:HEAD_TYPE=0x7A
    最后的结束块:HEAD_TYPE=0x7B
    
    

    标记块(MARK_HEAD)

    第一块为标记块(MARK_HEAD),其数据为:

    52 61 72 21 1A 07 00 // 左边是低字节 ,右边是高字节,这是RAR4.x的签名
    //签名即标志着该文件是由支持rar4.x版本的软件压缩而成,如果使用支持5.0版本的压缩软件压缩,其签名可能会不同
    

    字节的说明

    • 52 61头部校验和(HEAD_CRC),占两个字节,每一块均从HEAD_CRC开始,所有的RAR都以 52 61 开头

    • 72块类型(HEAD_TYPE) 占一个字节,所有文件都如此

    • 21 1A块标记(HEAD_FLAGS) 占两个字节

    • 07 00表示块大小 ,即 52 61 72 21 1A 07 00 (标记块)共占7个字节

    压缩文件头(MAIN_HEAD)

    第二块为压缩文件头(MAIN_HEAD) ,和标记块一样

    在这里插入图片描述
    头类型是0x73表示压缩文件头块
    位标记为0x0000 没有位被置为1 ,如果块头被加密,则位标记应该为:0x8000
    文件头大小为0x0D00,由上图可以看出这个压缩文件头块占13个字节

    文件头(FILE_HEAD)

    RAR文件格式及其各字段含义请参考: RAR 5.0 archive format description.

    接下来用rar文件来讲一下文件头部分的码流分析。

    在这里插入图片描述
    16进制软件使用winhex,hex值左边是低位,右边是高位,比如52 61 实际上就是0x6152

    D5 56 :HEAD_CRC,2字节,也就是文件头部分的crc校验值
    74 :HEAD_TYPE,1字节,块类型,74表示块类型是文件头
    20 90 :HEAD_FLAGS,2字节,位标记,这块在资料上没找到对应的数值,不知道20 90代表什么意思。
    2D 00 :HEAD_SIZE,2字节,文件头的全部大小(包含文件名和注释)
    00 10 00 00 :PACK_SIZE,4字节,已压缩文件大小
    00 10 00 00 :UNP_SIZE,4字节,未压缩文件大小
    02:HOST_OS,1字节,保存压缩文件使用的操作系统,02代表windows
    C7 88 67 36:FILE_CRC,4字节,文件的CRC值
    6D BB 4E 4B :FTIME,4字节,MS DOS 标准格式的日期和时间
    1D:UNP_VER,1字节,解压文件所需要的最低RAR版本
    30:METHOD,1字节,压缩方式,这里是存储压缩
    08 00 :NAME_SIZE,2字节,表示文件名大小,这里文件名大小是8字节(flag.txt)
    20 00 00 00 :ATTR,4字节,表示文件属性这里是txt文件
    66 6C 61 67 2E 74 78 74:FILE_NAME(文件名) ,NAME_SIZE字节大小,这里NAME_SIZE大小为8
    再往后是txt文件内容,一直到第六行 65 结束,下面是另一个文件块的开始
    
    这个块中存在两个crc值,一个是文件头块中从块类型到文件名这38个字节的校验,后一个则是压缩包中所包含文件的crc校验,解压时,会计算解压后生成文件的crc值,如果等于这里的crc,则解压完成,如果不同,则报错中断。
    

    结尾块

    在这里插入图片描述

    这个结尾块和标记块字节大小和分析方法是一样的。
    C4 3D :HEAD_CRC,2字节,从HEAD_TYPE到HEAD_SIZE的crc校验值
    7B :HEAD_TYPE,1字节,表示该块是结尾块
    00 40 HEAD_FALGS ,2字节,位标记
    07 00 :HEAD_SIZE,2字节,块大小
    与标记块类似的是,结尾块也是一个固定字节串的块,依次是 C4 3D 7B 00 40 07 00
    

    参考资料:

    展开全文
  • zip、rar文件格式

    千次阅读 2014-12-11 22:57:57
    zip、rar文件格式 目录 一、目录表(TOC)与分卷(Volume) 二、固实(solid)压缩方式 三、安全性 四、开放性 五、结论 声明:本文并非学术论文,所述内容仅为我个人的看法和体会,不具任何权威性,仅...

    zip、rar文件格式


    目录
    一、目录表(TOC)与分卷(Volume)
    二、固实(solid)压缩方式
    三、安全性
    四、开放性
    五、结论

    声明:本文并非学术论文,所述内容仅为我个人的看法和体会,不具任何权威性,仅供有兴趣的人参考,但是如果您不具有足够的鉴别能力,建议勿看,以免误导。

    一、目录表(TOC)与分卷(Volume)

    抛开压缩算法不谈,我认为zip、rar在文件格式上最大的差异就在目录表(Table of Contents,TOC):zip有TOC,而rar没有。

    TOC这个词其实是从出版界借用过来的,指的就是每一本书正文前面的“目录”,它的作用地球人都知道:如果想快速找到书中某一内容,可以先查TOC,然后按照TOC指明的页码直接翻即可。

    在纸质书里TOC是印刷出来的一张表,而在电子文件里则是由结构化数据构成的一张表,它的目的同样是为了快速定位:如果想找文件中的某一内容,可以先查TOC,知道感兴趣的内容在文件的什么位置,直接跳过去就行了。最常见的运用就是avi、rm等多媒体文件:播放的时候经常有人在播放条上点来点去跳着看(即“随机访问”),如果没有TOC,在长达几百兆的文件里来回定位会慢死。

    具体到zip文件里,TOC是放在文件尾部的一张表,里面列出了zip包中每一个文件的属性(文件名、长度等)和在zip包中的存放位置。如果需要随机访问zip包中的某一个文件,只需在TOC里找到这个文件的存放位置,直接跳过去即可。

    而RAR文件里则没有TOC,在文件头之后所有文件按顺序连续存放。

    这种差异造成的结果就是:随机访问时zip比rar快,而顺序访问时rar比zip快。

    所谓随机访问,就是前面说过的随机访问压缩包中某个指定的文件。举一个简单的例子:一本反编译或下载到的网页电子书,有大量HTML、图像、css、js,然后打成压缩包。现在要求在不解包的情况下访问其中的页面:可以想象,打开每个HTML页面的时候,它所附带的图像、css、js等文件可能随机分布在整个压缩包里,如果没有TOC,查找每个文件的时候都要从头开始找,将会有多慢。 所以各位可以理解为什么jar包就是标准zip包,而我也只用zip格式保存反编译出来的电子书、漫画、PDG书等一切可能需要随机访问的东西。

    所谓顺序访问,就是将整个压缩包从头解到尾。在这方面RAR具有天然的优势。而且为了节省WinRAR列文件的时间,对于单个RAR我一般都直接通过右键菜单解压缩,很少双击压缩包打开再解压。解多个RAR时当然都用BatchUnRar。

    由于rar的原作者已经去世,造成这种差异的确切原因我相信已不可考,但我个人猜测可能与DOS时代的备份软件之争有关:在DOS时代,电脑硬盘不像现在这样奢侈,20MB就算很大了。这样的容量用两盒软盘 即可备份,备份成本相对数据本身的价值来说非常低廉。因此在DOS时代,很多公司和机构都制定有定期硬盘备份政策,以免因为人为或非人为的因素 (早期硬盘可没有如今可靠)而造成不可挽回的数据损失。在备份软件方面,虽然微软已经随DOS提供了Backup/Restore工具,但是他们基本不具备数据压缩能力,因此在压缩软件中提供备份功能,就成为DOS时代的一个时尚。由于DOS时代的备份介质多为软盘,因此压缩 软件的备份功能其实就转化成如今很常见的一个功能:分卷压缩功能,即按照软盘容量进行分卷压缩,然后将分卷压缩文件备份(Backup)到软盘,需要的时候再解压,或恢复(Restore)到硬盘。

    DOS时代最有名的zip工具是pkzip,出现得比DOS版的RAR早。在分卷压缩时,pkzip按照zip文件规范,将TOC存放在最后,即存储在最后一卷,由此带来如下问题:

    1、恢复时,每解压一张盘,都要先将最后一张盘插进去一次,读一次TOC。
    2、只要最后一张盘上的TOC坏了,就算其它盘都是好的,也不能正常解压。

    这两个缺点,尤其是第一个缺点实在是太臭名昭著了,因此当时出现了非常强烈的改革呼声。在这个关键时刻,DOS版的RAR出现了:不仅压缩率比pkzip高(这点在DOS时代非常重要,毕竟软盘又贵容量又小),而且由于吸取了当时对zip格式的批评,取消了TOC,因此:

    1、在恢复分卷压缩的备份文件时,不需要频繁插入带有TOC的分卷,按顺序换盘即可。
    2、即使某个分卷损坏,也可以跳过,从完好的分卷再开始解压。

    由于这些原因(当然还有其它原因),RAR推出后迅速取得了成功,pkzip在DOS时代就开始流失用户,到Windows时代基本消声匿迹。在Windows时代推出的Winzip,则彻底放弃了分卷压缩功能(zip格式永远的痛?)。 而从我看到的源自WinRAR的UnRAR源代码来看,现在WinRAR的解压思路明显还是把文件按顺序从头解到尾,看来当年备份/恢复工具之争的影响,还真是深远。

    二、固实(solid)压缩方式

    在压缩算法方面,我觉得rar格式最特色的是固实(solid)压缩方式。WinRAR v3.42的帮助文件中对固实压缩的说明如下:

    固实压缩文件是 RAR 的一种特殊压缩方式存储的压缩文件,它把压缩文件中的全部文件都当成一个连续数据流来看待。

    这段说明其实揭示了固实压缩格式能够提高压缩比的奥秘:数据压缩的基础是“重复”,例如aaaabbb这个字符串,里面就有重复,如果表示为a4b3,看起来是不是变短了?这就是“数据压缩”。“重复”是一个具有相对意义的概念,在某一范围内看起来没有重复,或重复不多的数据,把范围扩大,说不定就能找到更多重复的数据了,这就是固实压缩的奥秘。

    举一个简单的例子:用zip和普通rar压缩一堆jpg文件,很难压下去,但是用固实压缩方式的rar就可以,其原因就在于:jpg文件本身已经是压缩格式了,单个jpg文件里很难再 找到可利用的重复数据,因此不论是用zip还是普通的rar都很难再压缩,因为他们都将需要压缩的文件分隔开来一个一个处理。但是对于固实rar来说,是将 所有需要压缩的jpg文件当作一个整体来压缩,这些jpg之间就存在重复的数据,如他们都有相同的文件头(其中包括各种数据表)等,这就出现了可压缩的空间。从我看到的资料来看,Flash文件也采用了类似的技术对jpg进行压缩:如果在Flash文件中使用了多个jpg文件,它们可以共用一个文件头。

    当然天下不会有白吃的午餐,固实压缩方式在提高压缩比的同时,也有一些限制,在WinRAR v3.42帮助文件中的说法是:

    固实压缩可增加压缩性能,特别是在添加大量的小文件的时候,但它也有一些重要的不利因素:

    • 对已存在的固实压缩文件更新时较慢;
    • 要从固实的压缩文件解压单个文件时,它之前的文件都需先经过分析。这造成当从固实的压缩文件内取出文件时会比一般压缩文件取出文件慢一些。但是,当从固实的压缩文件解压全部的文件时,解压速度并没有影响。
    • 如果在固实压缩文件中的任何文件损坏了,要从损坏的范围中解压全部的文件是不可能的。因此,如果固实压缩文件是保存在例如软盘等媒介时,推荐你在制作时使用“恢复记录”。

    固实压缩的适用场合为:

    • 压缩文件很少更新的时候;
    • 不需要经常从压缩文件中解压一个文件或是部分文件的时候;
    • 压缩效率比压缩速度更为重要的时候。

    与前面说的“随机访问”对应,固实压缩的RAR文件可能是世界上最不适合随机访问的:如果需要访问固实RAR包中的某个文件,就要从文件头开始解压,一直解到这个文件。

    三、安全性

    这里的安全性包含几个方面的含义:文件系统安全性、密码保护安全性和文件数据安全性。

    由于制订zip格式规范的时候操作系统本身的文件安全性还没有引起足够的重视,因此zip格式只记录最基本的文件属性,包括只读属性等,没有其它附加的安全属性。

    rar格式刚推出的时候,文件系统的安全性只能参照DOS,和zip差不多。但是rar毕竟是一种封闭的格式,想怎么改作者一个人说了就算,因此当Windows中出现NTFS,并且引入扩展的文件系统安全属性时,rar也积极跟进,所以现在应该说rar格式在这方面比zip强 。

    在zip和rar格式中均提供了密码保护功能,但是密码保护的安全强度不同。

    zip由于格式开放、代码开源,因此zip密码破解软件出现得比较早,也比较多。初期以暴力破解为主,威胁不大,真正对zip密码安全的致命一击是known plain text(已知明文)攻击法:如果知道加密zip文件中某段内容(密文,ciphertext)解密后的真正内容(明文,plain text),就可以反推出zip加密口令。在这种攻击方法的威胁,及某些国家的法律对密码技术的限制下, 著名开源组织zlib宣布永久放弃对加密zip的支持,详见zlib网站上的相关说明(不过在zlib发行的源代码里仔细找找,还是能找到原来的加/解密相关代码)。

    记得rar刚推出的时候也和zip一样,虽然不能列出加密文件中的文件内容,但可以列出加密文件中的文件名。后来大概也是被known plain text攻击法吓到了,增加了一个“加密文件名”选项,干脆连加密rar文件里有哪些文件都看不见,让攻击者想猜明文都无从猜起。

    rar格式比zip晚推出,在安全方面吸取了足够的教训,因此采用的是美国国家标准与技术局(National Institute of Standard and Technology, NIST)推荐的、目前公认安全程度比较高的AES对称加密算法 ,密钥长度128位。在ASE被攻破以前(NIST认为30年内无法攻破),大家都只能在暴力法上兜圈子,所以密码安全性应该说比zip高。对此WinRAR 3.42的帮助文件是这样描述的:

    ZIP 格式使用私有加密算法。 RAR 压缩文件使用更强大的 AES-128 标准加密。如果你需要加密重要的信息,选择 RAR 压缩文件格式会比较好一些。为了确实的安全性,密码长度请最少要 8 个字符。不要使用任何语言的单词作为密码,最好是任意的随机组合字符和数字,并且要注意密码的大小写。请记住,如果你遗失你的密码,你将无法取出加密的文件,就算是 WinRAR 的作者本身也无法解压加密过的文件。

    在数据安全性方面,RAR格式本身支持一种特殊的附加信息类型,叫做“恢复记录”。如果RAR文件有恢复记录,在介质物理损坏或其它原因造成数据丢失时,WinRAR可以按照“恢复记录”尝试对数据进行修复。而zip格式无恢复记录,因此在数据安全性方面应该说比RAR弱。

    虽然RAR文件本身支持恢复记录,但是在WinRAR里此选项缺省是关闭的,而打开后会导致压缩出来的RAR文件体积增加(增加的百分比与设置有关),可能会令某些人感到不习惯(我就亲眼见到有人在论坛上抱怨为什么压出来的RAR文件会如此庞大),所以这个功能基本上形同虚设。

    四、开放性

    开放性的对比很明显:zip格式不仅文件格式完全公开,而且有专门的开源组织提供操作源代码,跨平台使用也没有多大限制;rar格式完全保密,作者只提供解压所需源代码,不提供压缩所需源代码 ,跨平台使用有点麻烦。

    zip开源组织中,最出名的是zlibInfoZip,二者各有侧重:zlib偏重对内存缓冲区的压缩,因此被png等开源组织用做内部压缩算法,连java的jar程序内核都来自zlib,打出来的jar包自然也是一个标准的zip文件;InfoZip偏重对文件的操作 (包括口令保护),应用似乎不如zlib广泛,但我个人觉得其实它还是满好用的,前提是需要对它的源代码进行一些必要的修改。

    png组织的网页中有说到png格式的来历,我觉得也很有意思:做png的一班人,其实原来都是做gif格式的,但是由于Unisys公司开始对gif格式的核心——LZW压缩算法征收专利费,这帮人怒了,干脆提出png格式:大结构方面还是采用分段结构,但是核心压缩算法采用开源的zlib,压缩 效果在多数情况下比gif的LZW更强。由于没有版权限制,在静态图形领域png得到广泛应用,如果不是及时提出动画支持并因此在web上大行其道,我估计gif早就死掉了。

    RAR的解压源代码在其官方网站www.rarlab.com上提供,通常比WinRAR的正式版本晚一点,不过据说是直接从WinRAR的源代码中抠出来的,所以兼容性应该没有什么问题。

    五、结论

    以下观点纯属个人观点,仅供参考,不具有如何指导意义:

    • 如果经常需要对压缩包进行随机访问,应该选zip而不是rar。虽然将下载到的rar重新压缩成zip会麻烦一次,但是以后会减少无数的麻烦。
    • 如果需要分卷压缩(如某些网站对上传文件大小有限制),则只能用rar。事实上,这也是我唯一会使用rar格式的场合,其它时候一律zip没商量。  
    展开全文
  • 乱谈zip、rar文件格式

    2015-10-27 10:04:00
    虽然RAR文件本身支持恢复记录,但是在WinRAR里此选项缺省是关闭的,而打开后会导致压缩出来的RAR文件体积增加(增加的百分比与设置有关),可能会令某些人感到不习惯(我就亲眼见到有人在论坛上抱怨为什么压出来的...

    作者:马健
    邮箱:stronghorse_mj@hotmail.com
    发布:2006.11.21
    最近更新:2006.11.25

    目录
    一、目录表(TOC)与分卷(Volume)
    二、固实(solid)压缩方式
    三、安全性
    四、开放性
    五、结论

    声明:本文并非学术论文,所述内容仅为我个人的看法和体会,不具任何权威性,仅供有兴趣的人参考,但是如果您不具有足够的鉴别能力,建议勿看,以免误导。

    一、目录表(TOC)与分卷(Volume)

    抛开压缩算法不谈,我认为zip、rar在文件格式上最大的差异就在目录表(Table of Contents,TOC):zip有TOC,而rar没有。

    TOC这个词其实是从出版界借用过来的,指的就是每一本书正文前面的“目录”,它的作用地球人都知道:如果想快速找到书中某一内容,可以先查TOC,然后按照TOC指明的页码直接翻即可。

    在纸质书里TOC是印刷出来的一张表,而在电子文件里则是由结构化数据构成的一张表,它的目的同样是为了快速定位:如果想找文件中的某一内容,可以先查TOC,知道感兴趣的内容在文件的什么位置,直接跳过去就行了。最常见的运用就是avi、rm等多媒体文件:播放的时候经常有人在播放条上点来点去跳着看(即“随机访问”),如果没有TOC,在长达几百兆的文件里来回定位会慢死。

    具体到zip文件里,TOC是放在文件尾部的一张表,里面列出了zip包中每一个文件的属性(文件名、长度等)和在zip包中的存放位置。如果需要随机访问zip包中的某一个文件,只需在TOC里找到这个文件的存放位置,直接跳过去即可。

    而RAR文件里则没有TOC,在文件头之后所有文件按顺序连续存放。

    这种差异造成的结果就是:随机访问时zip比rar快,而顺序访问时rar比zip快。

    所谓随机访问,就是前面说过的随机访问压缩包中某个指定的文件。举一个简单的例子:一本反编译或下载到的网页电子书,有大量HTML、图像、css、js,然后打成压缩包。现在要求在不解包的情况下访问其中的页面:可以想象,打开每个HTML页面的时候,它所附带的图像、css、js等文件可能随机分布在整个压缩包里,如果没有TOC,查找每个文件的时候都要从头开始找,将会有多慢。 所以各位可以理解为什么jar包就是标准zip包,而我也只用zip格式保存反编译出来的电子书、漫画、PDG书等一切可能需要随机访问的东西。

    所谓顺序访问,就是将整个压缩包从头解到尾。在这方面RAR具有天然的优势。而且为了节省WinRAR列文件的时间,对于单个RAR我一般都直接通过右键菜单解压缩,很少双击压缩包打开再解压。解多个RAR时当然都用BatchUnRar。

    由于rar的原作者已经去世,造成这种差异的确切原因我相信已不可考,但我个人猜测可能与DOS时代的备份软件之争有关:在DOS时代,电脑硬盘不像现在这样奢侈,20MB就算很大了。这样的容量用两盒软盘 即可备份,备份成本相对数据本身的价值来说非常低廉。因此在DOS时代,很多公司和机构都制定有定期硬盘备份政策,以免因为人为或非人为的因素 (早期硬盘可没有如今可靠)而造成不可挽回的数据损失。在备份软件方面,虽然微软已经随DOS提供了Backup/Restore工具,但是他们基本不具备数据压缩能力,因此在压缩软件中提供备份功能,就成为DOS时代的一个时尚。由于DOS时代的备份介质多为软盘,因此压缩 软件的备份功能其实就转化成如今很常见的一个功能:分卷压缩功能,即按照软盘容量进行分卷压缩,然后将分卷压缩文件备份(Backup)到软盘,需要的时候再解压,或恢复(Restore)到硬盘。

    DOS时代最有名的zip工具是pkzip,出现得比DOS版的RAR早。在分卷压缩时,pkzip按照zip文件规范,将TOC存放在最后,即存储在最后一卷,由此带来如下问题:

    1、恢复时,每解压一张盘,都要先将最后一张盘插进去一次,读一次TOC。
    2、只要最后一张盘上的TOC坏了,就算其它盘都是好的,也不能正常解压。

    这两个缺点,尤其是第一个缺点实在是太臭名昭著了,因此当时出现了非常强烈的改革呼声。在这个关键时刻,DOS版的RAR出现了:不仅压缩率比pkzip高(这点在DOS时代非常重要,毕竟软盘又贵容量又小),而且由于吸取了当时对zip格式的批评,取消了TOC,因此:

    1、在恢复分卷压缩的备份文件时,不需要频繁插入带有TOC的分卷,按顺序换盘即可。
    2、即使某个分卷损坏,也可以跳过,从完好的分卷再开始解压。

    由于这些原因(当然还有其它原因),RAR推出后迅速取得了成功,pkzip在DOS时代就开始流失用户,到Windows时代基本消声匿迹。在Windows时代推出的Winzip,则彻底放弃了分卷压缩功能(zip格式永远的痛?)。 而从我看到的源自WinRAR的UnRAR源代码来看,现在WinRAR的解压思路明显还是把文件按顺序从头解到尾,看来当年备份/恢复工具之争的影响,还真是深远。

    二、固实(solid)压缩方式

    在压缩算法方面,我觉得rar格式最特色的是固实(solid)压缩方式。WinRAR v3.42的帮助文件中对固实压缩的说明如下:

    固实压缩文件是 RAR 的一种特殊压缩方式存储的压缩文件,它把压缩文件中的全部文件都当成一个连续数据流来看待。

    这段说明其实揭示了固实压缩格式能够提高压缩比的奥秘:数据压缩的基础是“重复”,例如aaaabbb这个字符串,里面就有重复,如果表示为a4b3,看起来是不是变短了?这就是“数据压缩”。“重复”是一个具有相对意义的概念,在某一范围内看起来没有重复,或重复不多的数据,把范围扩大,说不定就能找到更多重复的数据了,这就是固实压缩的奥秘。

    举一个简单的例子:用zip和普通rar压缩一堆jpg文件,很难压下去,但是用固实压缩方式的rar就可以,其原因就在于:jpg文件本身已经是压缩格式了,单个jpg文件里很难再 找到可利用的重复数据,因此不论是用zip还是普通的rar都很难再压缩,因为他们都将需要压缩的文件分隔开来一个一个处理。但是对于固实rar来说,是将 所有需要压缩的jpg文件当作一个整体来压缩,这些jpg之间就存在重复的数据,如他们都有相同的文件头(其中包括各种数据表)等,这就出现了可压缩的空间。从我看到的资料来看,Flash文件也采用了类似的技术对jpg进行压缩:如果在Flash文件中使用了多个jpg文件,它们可以共用一个文件头。

    当然天下不会有白吃的午餐,固实压缩方式在提高压缩比的同时,也有一些限制,在WinRAR v3.42帮助文件中的说法是:

    固实压缩可增加压缩性能,特别是在添加大量的小文件的时候,但它也有一些重要的不利因素:

    • 对已存在的固实压缩文件更新时较慢;
    • 要从固实的压缩文件解压单个文件时,它之前的文件都需先经过分析。这造成当从固实的压缩文件内取出文件时会比一般压缩文件取出文件慢一些。但是,当从固实的压缩文件解压全部的文件时,解压速度并没有影响。
    • 如果在固实压缩文件中的任何文件损坏了,要从损坏的范围中解压全部的文件是不可能的。因此,如果固实压缩文件是保存在例如软盘等媒介时,推荐你在制作时使用“恢复记录”。

    固实压缩的适用场合为:

    • 压缩文件很少更新的时候;
    • 不需要经常从压缩文件中解压一个文件或是部分文件的时候;
    • 压缩效率比压缩速度更为重要的时候。

    与前面说的“随机访问”对应,固实压缩的RAR文件可能是世界上最不适合随机访问的:如果需要访问固实RAR包中的某个文件,就要从文件头开始解压,一直解到这个文件。

    RAR的固实压缩还要手工选择一下,因此用的人会少一些,而7z为了追求压缩率,缺省就是采用固实压缩的,所以CV、UV等需要随机访问的软件,从头到尾就没想过要支持7z格式。

    三、安全性

    这里的安全性包含几个方面的含义:文件系统安全性、密码保护安全性和文件数据安全性。

    由于制订zip格式规范的时候操作系统本身的文件安全性还没有引起足够的重视,因此zip格式只记录最基本的文件属性,包括只读属性等,没有其它附加的安全属性。

    rar格式刚推出的时候,文件系统的安全性只能参照DOS,和zip差不多。但是rar毕竟是一种封闭的格式,想怎么改作者一个人说了就算,因此当Windows中出现NTFS,并且引入扩展的文件系统安全属性时,rar也积极跟进,所以现在应该说rar格式在这方面比zip强 。

    在zip和rar格式中均提供了密码保护功能,但是密码保护的安全强度不同。

    zip由于格式开放、代码开源,因此zip密码破解软件出现得比较早,也比较多。初期以暴力破解为主,威胁不大,真正对zip密码安全的致命一击是known plain text(已知明文)攻击法:如果知道加密zip文件中某段内容(密文,ciphertext)解密后的真正内容(明文,plain text),就可以反推出zip加密口令。在这种攻击方法的威胁,及某些国家的法律对密码技术的限制下, 著名开源组织zlib宣布永久放弃对加密zip的支持,详见zlib网站上的相关说明(不过在zlib发行的源代码里仔细找找,还是能找到原来的加/解密相关代码)。

    记得rar刚推出的时候也和zip一样,虽然不能列出加密文件中的文件内容,但可以列出加密文件中的文件名。后来大概也是被known plain text攻击法吓到了,增加了一个“加密文件名”选项,干脆连加密rar文件里有哪些文件都看不见,让攻击者想猜明文都无从猜起。

    rar格式比zip晚推出,在安全方面吸取了足够的教训,因此采用的是美国国家标准与技术局(National Institute of Standard and Technology, NIST)推荐的、目前公认安全程度比较高的AES对称加密算法 ,密钥长度128位。在ASE被攻破以前(NIST认为30年内无法攻破),大家都只能在暴力法上兜圈子,所以密码安全性应该说比zip高。对此WinRAR 3.42的帮助文件是这样描述的:

    ZIP 格式使用私有加密算法。 RAR 压缩文件使用更强大的 AES-128 标准加密。如果你需要加密重要的信息,选择 RAR 压缩文件格式会比较好一些。为了确实的安全性,密码长度请最少要 8 个字符。不要使用任何语言的单词作为密码,最好是任意的随机组合字符和数字,并且要注意密码的大小写。请记住,如果你遗失你的密码,你将无法取出加密的文件,就算是 WinRAR 的作者本身也无法解压加密过的文件。

    在数据安全性方面,RAR格式本身支持一种特殊的附加信息类型,叫做“恢复记录”。如果RAR文件有恢复记录,在介质物理损坏或其它原因造成数据丢失时,WinRAR可以按照“恢复记录”尝试对数据进行修复。而zip格式无恢复记录,因此在数据安全性方面应该说比RAR弱。

    虽然RAR文件本身支持恢复记录,但是在WinRAR里此选项缺省是关闭的,而打开后会导致压缩出来的RAR文件体积增加(增加的百分比与设置有关),可能会令某些人感到不习惯(我就亲眼见到有人在论坛上抱怨为什么压出来的RAR文件会如此庞大),所以这个功能基本上形同虚设。

    四、开放性

    开放性的对比很明显:zip格式不仅文件格式完全公开,而且有专门的开源组织提供操作源代码,跨平台使用也没有多大限制;rar格式完全保密,作者只提供解压所需源代码,不提供压缩所需源代码 ,跨平台使用有点麻烦。

    zip开源组织中,最出名的是zlibInfoZip,二者各有侧重:zlib偏重对内存缓冲区的压缩,因此被png等开源组织用做内部压缩算法,连java的jar程序内核都来自zlib,打出来的jar包自然也是一个标准的zip文件;InfoZip偏重对文件的操作 (包括口令保护),应用似乎不如zlib广泛,但我个人觉得其实它还是满好用的,前提是需要对它的源代码进行一些必要的修改。

    png组织的网页中有说到png格式的来历,我觉得也很有意思:做png的一班人,其实原来都是做gif格式的,但是由于Unisys公司开始对gif格式的核心——LZW压缩算法征收专利费,这帮人怒了,干脆提出png格式:大结构方面还是采用分段结构,但是核心压缩算法采用开源的zlib,压缩 效果在多数情况下比gif的LZW更强。由于没有版权限制,在静态图形领域png得到广泛应用,如果不是及时提出动画支持并因此在web上大行其道,我估计gif早就死掉了。

    RAR的解压源代码在其官方网站www.rarlab.com上提供,通常比WinRAR的正式版本晚一点,不过据说是直接从WinRAR的源代码中抠出来的,所以兼容性应该没有什么问题。

    五、结论

    以下观点纯属个人观点,仅供参考,不具有任何指导意义:

      • 如果经常需要对压缩包进行随机访问,应该选zip而不是rar。虽然将下载到的rar重新压缩成zip会麻烦一次,但是以后会减少无数的麻烦。
      • 如果需要分卷压缩(如某些网站对上传文件大小有限制),则只能用rar。事实上,这也是我唯一会使用rar格式的场合,其它时候一律zip没商量。

    转载于:https://www.cnblogs.com/stronghorse/p/4913341.html

    展开全文
  • RAR version 3.40 - Technical information RAR 3.40版 技术信息   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  THE ARCHIVE FORMAT DESCRIBED BELOW IS ONLY VALID FOR VER

    RAR version 3.40 - Technical information

    RAR 3.40版            技术信息            
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     THE ARCHIVE FORMAT DESCRIBED BELOW IS ONLY VALID FOR VERSIONS SINCE 1.50
      下面对归档文件格式的描述仅仅对1.5以后的版本是有效的

    本文由CSDN-蚍蜉撼青松【主页:http://blog.csdn.net/howeverpf】整理翻译,欢迎转载,但请务必注明出处!

     

     

     =======================================================================================================

    RAR archive file format

    RAR归档文件格式
     =======================================================================================================

      Archive file consists of variable length blocks. 

          归档文件是由可变长度的块组成的。

      The order of these blocks may vary, but the first block must be a marker block followed by an archive header block.
          这些块之间没有固定地先后顺序,但是要求第一个块必须是被一个归档头部块紧跟的标志块

          【译者注:即第一个块是标志块,并且其后紧跟一个归档头部块】。



       Each block begins with the following fields:
            每一个块都是由以下域开始的:【译者注:即每一个块的头部都是由以下域(可称之为头域)组成的】
    HEAD_CRC       2 bytes     CRC of total block or block part
                                                    整个块或者块某个部分的CRC(根据块类型而有不同) 
    HEAD_TYPE      1 byte      Block type
                                                    块类型【译者注:也可以理解为块头部类型,因为不同的块对应不同的块头部。后文也经常混淆这两种概念。】
    HEAD_FLAGS    2 bytes     Block flags
                                                    块标志
    HEAD_SIZE        2 bytes     Block size
                                                    块大小【译者注:本文中和块头部大小的概念一直混淆。后文中当遇到标志块、结尾块等只有头部的块时,也可理解为块头部大小】
    ADD_SIZE          4 bytes     Optional field - added block size
                                                    添加块的大小(这是一个可选域)
          Field ADD_SIZE present only if (HEAD_FLAGS & 0x8000) != 0
           头域ADD_SIZE仅当(HEAD_FLAGS & 0x8000) != 0【译者注:即块标志的首位被置1的时候才会存在
         Total block size is HEAD_SIZE if (HEAD_FLAGS & 0x8000) == 0

            当(HEAD_FLAGS & 0x8000) == 0【译者注:即块标志的首位被置0的时候,整个块的大小就是HEAD_SIZE
         and HEAD_SIZE+ADD_SIZE if the field ADD_SIZE is present - when (HEAD_FLAGS & 0x8000) != 0.
            而当(HEAD_FLAGS & 0x8000) != 0【译者注:即块标志的首位被置1的时候,整个块的大小就是(HEAD_SIZE+ADD_SIZE)


       In each block the followings bits in HEAD_FLAGS have the same meaning:
          HEAD_FLAGS域【块标志】的以下几位在每一个块中都有相同的含义:
      0x4000 - if set, older RAR versions will ignore the block and remove it when the archive is updated.
       【高二位】  (此位)如果置为1,老版本的rar会在归档文件更新的时候忽略这个块,并且移除这个块。

                       if clear, the block is copied to the new archive file when the archive is updated;
                             如果清为0,那么当更新的时候,这个块会被复制到新的归档文件中
      0x8000 - if set, ADD_SIZE field is present and the full block size is HEAD_SIZE+ADD_SIZE.
       【最高位】  (此位)如果置为1,就会存在ADD_SIZE这个域,并且整个块的大小就应该是(HEAD_SIZE+ADD_SIZE)


      Declared block types:
           已经声明过的块类型包括:
    HEAD_TYPE=0x72          marker block【译者注:有些文献里也称之为MARK_HEAD
                                               标志块【译者注:一个固定为0x52 61 72 21 1A 07 00的7字节序列】
    HEAD_TYPE=0x73          archive header【译者注:有些文献里也称之为MAIN_HEAD
                                               归档头部块
    HEAD_TYPE=0x74          file header【译者注:有些文献里也称之为FILE_HEAD
                                               文件块【译者注:直译为文件头部,但是此处的类型应该指的是整个块的类型,而非块头部结构的类型,因此感觉称之为文件块更合适。】
    HEAD_TYPE=0x75          old style comment header
                                               老风格的 注释块【译者注:直译为注释头部,基于和文件块一样的原因,感觉称之为注释块更合适】
    HEAD_TYPE=0x76          old style authenticity information
                                               老风格的 授权信息块/用户身份信息块
    HEAD_TYPE=0x77          old style subblock
                                               老风格的 子块
    HEAD_TYPE=0x78          old style recovery record
                                               老风格的 恢复记录块
    HEAD_TYPE=0x79          old style authenticity information
                                               老风格的 授权信息块/用户身份信息块
    HEAD_TYPE=0x7a          subblock
                                               子块
    HEAD_TYPE=0x7b          end block
                                                结束块【译者注:一个固定为0xC4 3D 7B 00 40 07 00的7字节序列】
       Comment block is actually used only within other blocks and doesn't exist separately.
            注释块实际上只在其它块中使用,并不单独存在


       Archive processing is made in the following manner:
            归档文件的处理遵循以下流程:    
    1. Read and check marker block
        读取和检查标志块【译者注:确认这是一个rar格式的归档文件】
    2. Read archive header
        读取归档头部块的信息
    3. Read or skip HEAD_SIZE-sizeof(MAIN_HEAD) bytes
        读取或者是跳过HEAD_SIZE( 即sizeof(MAIN_HEAD) )个字节的内容

    【译者注:即跳过归档头部块,将指针指向下一个块,也就是文件块的开始位置,然后读取紧接下来的7字节。另外,译者觉得句首的“读取”不知所云,第二步明明已经读取,此步应该只要跳过就好。

    4. If end of archive encountered then terminate archive processing,

        如果遇到归档文件结束标志【译者注:即下一个块是结束块】,那么终止归档文件处理过程,
        else read 7 bytes into fields HEAD_CRC, HEAD_TYPE, HEAD_FLAGS, HEAD_SIZE.
        不然的话,读取7个字节到头部的四个域:HEAD_CRCHEAD_TYPEHEAD_FLAGSHEAD_SIZE 中。

    5.循环处理 

         Check HEAD_TYPE.
                检查头部的HEAD_TYPE域【译者注:此域指定块类型】
         if HEAD_TYPE==0x74

                 如果HEAD_TYPE域的值是0x74【译者注:表明是文件块】
             read file header ( first 7 bytes already read )
                    读取文件块(前7个字节已经读过)
             read or skip HEAD_SIZE-sizeof(FILE_HEAD) bytes
                    读取或者跳过HEAD_SIZE( 即sizeof(MAIN_HEAD) )个字节的内容
             if (HEAD_FLAGS & 0x100)

                    如果块标志的第四位被置为1(即HEAD_FLAGS & 0x0100 !=0) 【译者注:说明HIGH_PACK_SIZE这个头域存在】
                 read or skip HIGH_PACK_SIZE*0x100000000+PACK_SIZE bytes
                      读取或者跳过已压缩文件大小(即HIGH_PACK_SIZE*0x100000000+PACK_SIZE)的字节

                     【译者注:HIGH_PACK_SIZE是文件块头部的可选域,是已压缩文件大小64位值的高4字节,仅当文件较大时存在。
             else
                  read or skip PACK_SIZE bytes
                       读取或者跳过已压缩文件大小(即PACK_SIZE)的字节
       else
           read corresponding HEAD_TYPE block:
                  读取HEAD_TYPE所指定类型的块的内容;
           read HEAD_SIZE-7 bytes

                  读取HEAD_SIZE-7个字节的内容【译者注:即块数据部分】
           if (HEAD_FLAGS & 0x8000)

                  如果(HEAD_FLAGS & 0x8000) != 0【译者注:即块标志的首位被置1,亦即说明添加块存在】
               read ADD_SIZE bytes

                      读取ADD_SIZE个字节【译者注:即添加块的内容】

    6. go to 4.
        转到第4


       =======================================================================================================

    Block Formats

    (常见)块格式
       =======================================================================================================

       Marker block ( MARK_HEAD )
            标志块
    HEAD_CRC        2 bytes       Always 0x6152
    HEAD_TYPE       1 byte         Header type: 0x72
    HEAD_FLAGS    2 bytes       Always 0x1a21
    HEAD_SIZE        2 bytes       Block size = 0x0007
       The marker block is actually considered as a fixed byte sequence: 0x52 0x61 0x72 0x21 0x1a 0x07 0x00
              标志块事实上被认为是一个固定地字节序列:0x52 0x61 0x72 0x21 0x1a 0x07 0x00
        


       Archive header ( MAIN_HEAD )
             归档头部块
    HEAD_CRC         2 bytes      CRC of fields HEAD_TYPE to RESERVED2
                                                      从头域HEAD_TYPE到头域RESERVED2的CRC
    HEAD_TYPE        1 byte         Header type: 0x73
    HEAD_FLAGS      2 bytes      Bit flags:
                    0x0001  - Volume attribute (archive volume)
                   【最低位】      卷属性标志(归档文件卷)
                    0x0002  - Archive comment present
                   【低二位】      注释标志。【此位若被置1,注释存在
                              RAR 3.x uses the separate comment block and does not set this flag.
                                RAR 3系列的版本使用独立的注释块(来描述归档内容),这个标志没有设定
                    0x0004  - Archive lock attribute
                   【低三位】       归档锁属性标志
                    0x0008  - Solid attribute (solid archive)
                   【低四位】       实”属性标志【译者注:此位若被置1,则使用了固实模式压缩】
                    0x0010  - New volume naming scheme ('volname.partN.rar')
                   【低五位】       新卷命名方案存在标志【译者注:可否理解为,多卷压缩的时候,其他卷里的文件命名方案】
                    0x0020  - Authenticity information present

                   【低六位】        授权信息存在标志。【译者注:此位若被置1授权信息存在】
                              RAR 3.x does not set this flag.
                                RAR 3系列的版本没有设定这个标志
                    0x0040  - Recovery record present
                   【低七位】       回复记录存在标志。【译者注:此位若被置1,则恢复记录存在】
                    0x0080  - Block headers are encrypted
                   【低八位】       块头加密标志。【译者注:此位若被置1,则块头是被加密的】
                    0x0100  - First volume (set only by RAR 3.0 and later)
                   【高八位】       首卷标志(只有RAR3.0以后的版本会设置此位)【译者注:此位若被置1则此卷为首卷】
                    other bits in HEAD_FLAGS are reserved for internal use
                        其他的位为内部使用保留

    HEAD_SIZE          2 bytes       Archive header total size including archive comments
                                                        归档头部块大小,包括归档文件注释。【译者注:不知此处的注释是否指归档头部块的注释块】
    RESERVED1        2 bytes       Reserved
                                                        保留域
    RESERVED2        4 bytes       Reserved
                                                        保留域


       File header (File in archive)
            文件块(被归档的文件)
    HEAD_CRC                2 bytes       CRC of fields from HEAD_TYPE to FILEATTR and file name
                                                        从头域HEAD_TYPE到头域FILEATTR的CRC         
    HEAD_TYPE               1 byte          Header type: 0x74
    HEAD_FLAGS            2 bytes       Bit flags:
                    0x01 - file continued from previous volume
                               前文存在标志。【译者注:此位若被置1,则文件从前一个卷继续】
                    0x02 - file continued in next volume
                               后文存在标志。【译者注:此位若被置1,则文件在后一个卷继续】
                    0x04 - file encrypted with password
                               加密标志。【译者注:此位若被置1,则文件使用了基于密钥的加密】
                    0x08 - file comment present
                               注释存在标志。【译者注:此位若被置1,则文件注释存在】
                           RAR 3.x uses the separate comment block and does not set this flag.
                             RAR 3系列的版本使用独立的注释块(来描述归档内容),这个标志没有设定
                    0x10 - information from previous files is used (solid flag) (for RAR 2.0 and later)
                               固实标志。此位若被置1,则之前的文件信息被使用(RAR2.0及其以后的版本可用)
                    bits 7 6 5 (for RAR 2.0 and later)【译者注:原文应该是从0开始计数,故此是0x20、0x400x80
                               第567位表示的是字典的大小(RAR2.0及其以后的版本可用)【译者注:按照译者前文的计数习惯,应该是678位】
                         0 0 0    - dictionary size   64 KB
                         0 0 1    - dictionary size  128 KB
                         0 1 0    - dictionary size  256 KB
                         0 1 1    - dictionary size  512 KB
                         1 0 0    - dictionary size 1024 KB
                         1 0 1    - dictionary size 2048 KB
                         1 1 0    - dictionary size 4096 KB
                         1 1 1    - file is directory 【译者注:以整个文件作为字典】
                   0x100 - HIGH_PACK_SIZE and HIGH_UNP_SIZE fields are present. 

                                  大文件标志。【译者注:此位若被置1,则头域HIGH_PACK_SIZE 和 HIGH_UNP_SIZE存在。】
                           These fields are used to archiveonly very large files (larger than 2Gb), for smaller files these fields are absent.
                             这些头域仅用于归档很大(大于2GB)文件的时候,对于不足2GB的小文件,这些头域是不存在的。
                   0x200 - FILE_NAME contains both usual and encoded Unicode name separated by zero. 

                                  此位若被置1,则FILE_NAME同时包括了通常的文件名和用0隔开的以Unicode编码的文件名
                            In this case NAME_SIZE field is equal to the length of usual name plus encoded Unicode name plus 1.
                             在这种情况下,NAME_SIZE 头域的值就该等于:通常的文件名长度+以Unicode编码的文件名长度+1
                   0x400 - the header contains additional 8 bytes after the file name, which are required to increase encryption security (so called 'salt').
                                强安全性标志。此位若被置1,则头部在文件名之后还会再附加8个字节用来增强加密强度(这被称之为“盐”【译者注:一个密码学概念,可理解为干扰因子】)
                   0x800 - Version flag. It is an old file version, a version number is appended to file name as ';n'.
                                   版本标志。此位若被置1,则这是一个老版本的文件,版本号以”;n”的形式被附加到文件名后。
                  0x1000 - Extended time field present.
                                   扩展时间头域存在标志。【译者注:此位若被置1,则存在扩展的时间头域】
                  0x8000 - this bit always is set, so the complete block size is HEAD_SIZE + PACK_SIZE(and plus HIGH_PACK_SIZE, if bit 0x100 is set)
                                   数据长度头域存在标志。【译者注:此位若被置1,则头域PACK_SIZE存在】此位通常都会被置为1,因此完整的块大小是HEAD_SIZE + PACK_SIZE(如果位0x100被设定的话,那么还要加上HIGH_PACK_SIZE)

    HEAD_SIZE               2 bytes     File header full size including file name and comments
                                                          文件块大小,包括文件名和内容
    PACK_SIZE               4 bytes     Compressed file size
                                                          压缩后的文件大小【译者注:亦即前文所说的数据长度头域】
    UNP_SIZE                 4 bytes     Uncompressed file size
                                                          没有压缩之前的文件大小
    HOST_OS                  1 byte       Operating system used for archiving
                                                          归档(压缩)操作时所在的操作系统
                      0 - MS DOS
                        1 - OS/2
                        2 - Win32
                        3 - Unix
                        4 - Mac OS
                        5 - BeOS
    FILE_CRC                  4 bytes    File CRC
                                                          被归档文件的CRC【译者注:不知是压缩前还是压缩后】
    FTIME                          4 bytes    Date and time in standard MS DOS format
                                                          标准MS DOS格式的时间和日期
    UNP_VER                  1 byte      RAR version needed to extract file

                                                          释放(即解压)文件所需要的RAR(最低)版本
                    Version number is encoded as 10 * Major version + minor version.
                       版本号的是编码方式是:10*主版本号+小版本号
    METHOD                    1 byte       Packing method
                                                          打包方式【译者注:可理解为压缩模式】
                    0x30 - storing                               存储
                    0x31 - fastest compression      最快压缩
                    0x32 - fast compression            快压缩
                    0x33 - normal compression     普通压缩
                    0x34 - good compression         好压缩
                    0x35 - best compression          最好压缩
    NAME_SIZE                2 bytes     File name size
                                                           文件名长度
    ATTR                            4 bytes     File attributes
                                                           文件属性
    HIGH_PACK_SIZE    4 bytes     High 4 bytes of 64 bit value of compressed file size.
                                                           已压缩文件大小的64位值的高位四字节
                                                        Optional value, presents only if bit 0x100 in HEAD_FLAGS is set.
                                                          可选的头域,仅当块标志的0x100位被置为1时才存在
    HIGH_UNP_SIZE      4 bytes     High 4 bytes of 64 bit value of uncompressed file size.
                                                           未压缩文件大小的64位值的高位四字节
                                                        Optional value, presents only if bit 0x100 in HEAD_FLAGS is set.
                                                          可选的头域,仅当块标志的0x100位被置为1时才存在
    FILE_NAME        NAME_SIZE     File name - string of NAME_SIZE bytes size
                                                            文件名(所占字节数由头域NAME_SIZE指定)
    SALT                          8 bytes      present if (HEAD_FLAGS & 0x400) != 0
                                                            盐。仅当块标志的0x100位被置为1时才存在

    EXT_TIME          variable size      present if (HEAD_FLAGS & 0x1000) != 0
                                  大小可变           扩展的时间头域。仅当块标志的0x1000位被置为1时才存在。
    other new fields may appear here.
      其他新加的头域可能在这里出现


    ======================================================================================================

    Application notes

    应用注意事项
     ======================================================================================================


       1. To process an SFX archive you need to skip the SFX module searching for the marker block in the archive. 

             处理一个自解压缩文件的时候,你需要忽略SFX模块对于标志块的检查

          There is no marker block sequence (0x52 0x61 0x72 0x21 0x1a 0x07 0x00) in the SFX module itself.
              在自解压模块自身不存在标志块序列(0x52 0x61 0x72 0x21 0x1a 0x07 0x00) 
       2. The CRC is calculated using the standard polynomial 0xEDB88320. 

             CRC的值由标准的多项式0XEDB88320计算得出。

           In case the size of the CRC is less than 4 bytes, only the low order bytes are used.
             在 CRC的长度被要求少于4字节的情况下,只使用低4字节

     

    译者声明:

            鄙人前段时间出于学习的需要,下载了参考文献[1]。阅读后不甚满意,遂以之为底稿,并在参考了以参考文献[2]为主的其他一些资料后加以完善,这正是本文的由来。完善工作主要包括:对原文一些表达不清的地方进行了润色,在原文一些可能不易于理解的地方加上了注释(用【译者注】标注),以及按照个人理解对一些原文翻译有错的地方进行了更改。总的来说,算是对两位前辈已有工作的补充与完善吧。

            如有需要,可自由转载分享本文。转载时希望能说明一下来源,谢谢~~~

            如有不同翻译意见,请一定留下评论与我探讨,鄙人感激不尽。

            本文doc版已上传至CSDN下载频道,0积分下载,地址为:http://download.csdn.net/detail/ping_fani07/5353575

     

    参考文献:

     

    ------本文由CSDN-蚍蜉撼青松【主页:http://blog.csdn.net/Ping_Fani07】整理翻译,转载请注明出处!----


    亦可参考:http://xinyidadianzi.blog.163.com/blog/static/3993039920114292257760/ 格式说明

    展开全文
  • RAR编码文件格式分析

    2012-11-29 15:34:22
    RAR编码文件格式分析
  • 文件压缩打包是最为常见的一种分享方式了,而众多的压缩格式中zip仍然是主流。在电脑使用过程中我们也发现,其实Windows10或macOS系统是可以直接支持zip压缩文件解压的,而不需要安装第三方解压工具。对于rar和7z则...
  • WAV文件格式说明.rar

    2021-04-24 18:01:00
    ADPCM格式说明,wav文件格式分析详解,WAV文件格式分析与应用,wav音频格式
  • ubuntu解压rar格式文件

    2016-06-03 07:09:04
    ubuntu如何解压rar格式文件。  1.下载: sudo apt-get install rar  2.解压文件: rar x 压缩文件.rar
  • zip、rar格式文件解压

    2018-06-22 11:04:17
    这是一个Android(Java)解压zip、rar格式的工具类库,主要功能是解压和压缩文件
  • 用于破解RAR格式文件的密码,忘记密码的有力助手!若有人用于对他人文件,本人不负责哦!
  • PE文件格式图.rar

    2012-08-30 12:56:46
    PE文件格式图.rar
  • Linux下解压rar格式文件

    千次阅读 2018-09-19 18:34:53
    rar文件与zip tar.gz等等开源压缩文件是不一样的,rar类型的压缩协议是不开源的,所以linux系统自身是没有安装rar的解压工具的,所以我们需要自己下载rar工具,注:由于rar类型并不可以,理论上是要收费的,所以我们...
  • linux解压rar格式文件

    2021-04-23 11:16:34
    配置 rar package wget https://www.rarlab.com/rar/rarlinux-x64-5.6.1.tar.gz tar -zxvf rarlinux-x64-5.6.1.tar.gz cd rar make 参数列表 a:压缩文件; x:解压文件; -p:设置密码。密码紧随其后,如-p abc ...
  • Win8系统下如何运行rar格式文件 Win8电脑rar文件怎么解压打开 现在应该会有很多人都在使用win8系统的电脑,因为随着win8系统的推广,很多的电脑买回来就是win8的系统。但是对于很多使用惯了win7系统的人来说,有的...
  • xdf文件阅读器及xdf文件格式转pdf格式工具,亲测好用。欢迎下载使用评论,转自:https://download.csdn.net/download/whz2017/11014247
  • Java解压ZIP和RAR格式文件_所需资源,本资源是博客中所需文件,故不要过多积分,以方便技术人员解决问题,而且方便下载。
  • 3ds文件格式说明.rar

    2020-08-09 21:50:19
    本文件描述了由Autodesk公司生成的3d-studio文件格式。作者对本文件使用后产生的 任何不良后果不负有责任。本文件可以在alt.3d and alt.3d-studio新闻组获取,也可以在 http://www.mediatel.lu找到
  • * 解压zip格式文件 * */ public static void Decompressing2() throws IOException { String Inputpath = "E:/b";//压缩包地址 String outpath = "E:/a";//解压到的文件地址 String ...
  • 在C#.NET中压缩解压rar文件 rar格式是一种具有专利文件的压缩格式,是一种商业压缩格式,不开源,对解码算法是公开的,但压缩算法是私有的,需要付费,如果需要在您的商业软件中使用rar格式进行
  • RAR格式文件密码破解

    2008-12-19 12:36:38
    破解RAR格式的压缩包密码 在你不知道它的密码情况下用它来破解密码是有效的方法
  • C# 如何转换图像文件格式.rar C# 如何转换图像文件格式.rar C# 如何转换图像文件格式.rar
  • KML 2.0介绍 KML全称是Keyhole Markup Language KML,是一个基于XML语法和文件格式的文件,用来描述和保存地理信息如点、线、图片、折线并在Google Earth客户端之中显示
  • “rar文件怎么打开”问题只有一种解决方法,就是安装一个支持解压缩rar文件格式的解压缩工具。毕竟Win7默认只支持打开.ZIP格式压缩文件,不支持.rar格式的压缩文件。  什么是.rar文件?  我们先来简单跟系统吧小...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,750
精华内容 3,100
关键字:

rar文件格式