去除遨游浏览器的”使用遨游下载”
用reshack打开maxthon.ex用reshack打开maxthon.exe ,找到所有包括DOWNLOADALL BY MX和Download by Maxthon的菜单项，删除之.

标签：

deflate(RFC1951):一种压缩算法，使用LZ77和哈弗曼进行编码；
zlib(RFC1950):一种格式，是对deflate进行了简单的封装，他也是一个实现库(delphi中有zlib,zlibex)
gzip(RFC1952):一种格式，也是对deflate进行的封装。

gzip = gzip头 + deflate编码的实际内容 + gzip尾
zlib = zlib头 + deflate编码的实际内容 + zlib尾

因最近在做一些关于网页解码方面的事情，压缩都是gzip,deflate.

deflate返回的就是zlib格式。浏览器可以解压，但ie系列要求必需是纯正的deflate格式，故解压时必须手动的添加一个头和尾，原来采集finance.sina.com.cn上的数据就是deflate格式，今天看了下，改用gzip压缩了。当时，只在deflate数据前加了两个字节：#$78#$9c，就可以用zlib解压了。

gzip格式和deflate相比，有了一些头信息：
GZIP文件由1到多个“块”组成，实际上通常只有1块。每个块包含头、数据和尾三部分。块的概貌如下：

+—+—+—+—+—+—+—+—+—+—+========//========+===========//==========+—+—+—+—+—+—+—+—+
|ID1|ID2| CM|FLG| MTIME |XFL| OS| 额外的头字段 | 压缩的数据 | CRC32 | ISIZE |
+—+—+—+—+—+—+—+—+—+—+========//========+===========//==========+—+—+—+—+—+—+—+—+
1. 头部分
ID1与ID2：各1字节。固定值，ID1 = 31 (0×1F)，ID2 = 139(0×8B)，指示GZIP格式。
CM：1字节。压缩方法。目前只有一种：CM = 8，指示DEFLATE方法。
FLG：1字节。标志。
bit 0 FTEXT – 指示文本数据
bit 1 FHCRC – 指示存在CRC16头校验字段
bit 2 FEXTRA – 指示存在可选项字段
bit 3 FNAME – 指示存在原文件名字段
bit 4 FCOMMENT – 指示存在注释字段
bit 5-7 保留

MTIME：4字节。更改时间。UINX格式。
XFL：1字节。附加的标志。当CM = 8时，XFL = 2 – 最大压缩但最慢的算法；XFL = 4 – 最快但最小压缩的算法
OS：1字节。操作系统，确切地说应该是文件系统。有下列定义：
0 – FAT文件系统 (MS-DOS, OS/2, NT/Win32)
1 – Amiga
2 – VMS/OpenVMS
3 – Unix
4 – VM/CMS
5 – Atari TOS
6 – HPFS文件系统 (OS/2, NT)
7 – Macintosh
8 – Z-System
9 – CP/M
10 – TOPS-20
11 – NTFS文件系统 (NT)
12 – QDOS
13 – Acorn RISCOS
255 – 未知

额外的头字段：
(若 FLG.FEXTRA = 1)

+—+—+—+—+===============//================+
|SI1|SI2| XLEN | 长度为XLEN字节的可选项 |
+—+—+—+—+===============//================+
(若 FLG.FNAME = 1)

+=======================//========================+
| 原文件名(以NULL结尾) |
+=======================//========================+
(若 FLG.FCOMMENT = 1)

+=======================//========================+
| 注释文字(只能使用iso-8859-1字符，以NULL结尾) |
+=======================//========================+
(若 FLG.FHCRC = 1)

+—+—+
| CRC16 |
+—+—+
存在额外的可选项时，SI1与SI2指示可选项ID，XLEN指示可选项字节数。如 SI1 = 0×41 (‘A’)，SI2 = 0×70 (‘P’)，表示可选项是Apollo文件格式的额外数据。

2. 数据部分
DEFLATE数据格式，包含一系列子数据块。子块概貌如下：

+……+……+……+=============//============+
|BFINAL| BTYPE | 数据 |
+……+……+……+=============//============+
BFINAL：1比特。0 – 还有后续子块；1 – 该子块是最后一块。
BTYPE：2比特。00 – 不压缩；01 – 静态Huffman编码压缩；10 – 动态Huffman编码压缩；11 – 保留。
各种情形的处理过程，请参考后面列出的RFC文档。

3. 尾部分
CRC32：4字节。原始(未压缩)数据的32位校验和。
ISIZE：4字节。原始(未压缩)数据的长度的低32位。
GZIP中字节排列顺序是LSB方式，即Little-Endian，与ZLIB中的相反。

deflate使用inflateInit()，而gzip使用inflateInit2()进行初始化，比 inflateInit()多一个参数: -MAX_WBITS，表示处理raw deflate数据。因为gzip数据中的zlib压缩数据块没有zlib header的两个字节。使用inflateInit2时要求zlib库忽略zlib header。在zlib手册中要求windowBits为8..15，但是实际上其它范围的数据有特殊作用，见zlib.h中的注释，如负数表示raw deflate。
Apache的deflate变种可能也没有zlib header，需要添加假头后处理。即MS的错误deflate (raw deflate).zlib头第1字节一般是0×78, 第2字节与第一字节合起来的双字节应能被31整除，详见rfc1950。例如Firefox的zlib假头为0×7801，python zlib.compress()结果头部为0×789c。

注：以上文字属于多段摘抄，非原创。收录于此，感谢原作者们。

标签：deflate, gzip, zlib

360/50的结果是多少？

标签：

标签：