【前言】

(資料圖片僅供參考)

一、Zip格式結(jié)構(gòu)圖總覽

二、Zip文件結(jié)構(gòu)詳解

zip格式壓縮包主要由三大部分組成：數(shù)據(jù)區(qū)、中央目錄記錄區(qū)（也有叫核心目錄記錄）、中央目錄記錄尾部區(qū)

1、數(shù)據(jù)區(qū)

數(shù)據(jù)區(qū)是由一系列本地文件記錄組成，本地文件記錄主要是記錄了壓縮前后文件的元數(shù)據(jù)以及存放壓縮后的文件，組成部分也分為三大部分：本地文件頭、文件數(shù)據(jù)、文件描述1.1、本地文件頭本地文件頭主要是記錄了壓縮文件的元數(shù)據(jù)： 1）0~3：4個(gè)字節(jié)，用來存放本地文件頭標(biāo)識(shí)：0x04034b50，用于解壓時(shí)候，讀取判斷文件頭的開始 2）4~5：2個(gè)字節(jié)，記錄解壓縮文件所需的最低支持的ZIP規(guī)范版本，apk壓縮版本默認(rèn)是20, 即Deflate壓縮方式

3）6~7：2個(gè)字節(jié)，記錄通用標(biāo)志位，第0位為1時(shí)（即二進(jìn)制：00000000 00000001），表示文件被加密，解壓時(shí)候需要解密；第3位為1時(shí)候（即二進(jìn)制：00000000 00000100），表示有數(shù)據(jù)描述部分，那么本地文件頭中的 CRC-32、壓縮大小和未壓縮大小字段都被設(shè)置為0（雖然zip規(guī)范是這么定義，但是發(fā)現(xiàn)有些壓縮包即使聲明有數(shù)據(jù)描述部分，但是本地文件頭的CRC-32、壓縮大小和未壓縮大小依然還是設(shè)置為真實(shí)值） ， 正確的值被放在緊跟在壓縮數(shù)據(jù)之后的數(shù)據(jù)描述部分，apk的通用標(biāo)志位默認(rèn)傳0即可，也有傳2048、2056，目前第15位是PKWARE保留位，沒啥意義，更多通用標(biāo)志位含義可見這里 4）8~9：2個(gè)字節(jié)，記錄壓縮包所用到的壓縮方式，apk默認(rèn)Deflate壓縮，傳8即可, 要是傳0，則是不壓縮，各種壓縮方式對(duì)應(yīng)數(shù)值如下：

5）10~11：2個(gè)字節(jié)，記錄文件最后修改時(shí)間，是MS-DOS格式編碼的時(shí)間 6）12~13：2個(gè)字節(jié)，記錄文件最后修改日期，是MS-DOS格式編碼的日期 7）14~17：4個(gè)字節(jié)，記錄文件未壓縮時(shí)的CRC-32校驗(yàn)碼8）18~21：4個(gè)字節(jié)，記錄文件壓縮后的大小9）22~25：4個(gè)字節(jié)，記錄文件未壓縮的大小10）26~27：2個(gè)字節(jié)，記錄文件名的長度(假設(shè)文件名長度為n) 11）28~29：2個(gè)字節(jié)，記錄擴(kuò)展區(qū)的長度(假設(shè)擴(kuò)展區(qū)長度為m) 12）30~30+n: n個(gè)字節(jié)，記錄文件名13）30+n~30+n+m: m個(gè)字節(jié)，記錄擴(kuò)展數(shù)據(jù)1.2、文件數(shù)據(jù)文件數(shù)據(jù)緊跟在本地文件頭之后，一般是壓縮后的文件數(shù)據(jù)或壓縮方式選擇不壓縮時(shí)候，用來存儲(chǔ)未壓縮文件數(shù)據(jù)。 1.3、文件描述文件描述符僅在通用位標(biāo)志的第 3 位被設(shè)置為1時(shí)才存在。 它是字節(jié)對(duì)齊的，緊跟在文件數(shù)據(jù)的最后一個(gè)字節(jié)之后。當(dāng)且僅當(dāng)無法在 .ZIP 文件中查找時(shí)才使用此描述符，例如：當(dāng)輸出 的.ZIP 文件是標(biāo)準(zhǔn)輸出或不可查找設(shè)備時(shí)使用文件描述，換句話說，正常情況下都不需要使用 數(shù)據(jù)描述符標(biāo)識(shí)不一定有，因?yàn)橐婚_始規(guī)范是沒有的，后面才加上去的

2、中央目錄記錄區(qū)（也稱核心目錄記錄區(qū) ）

中央目錄記錄區(qū)是有一系列中央目錄記錄所組成，一條中央目錄記錄對(duì)應(yīng)數(shù)據(jù)區(qū)中的一個(gè)壓縮文件記錄，中央目錄記錄由以下部分構(gòu)成： 1）0~3：4個(gè)字節(jié)，記錄核心目錄文件頭標(biāo)識(shí)：0x02014b50，用于解壓時(shí)候，查找判斷是否是中央目錄的開始位置 2）4~5：2個(gè)字節(jié)，記錄壓縮所用的版本，同數(shù)據(jù)區(qū)本地文件頭的解壓所需版本，apk設(shè)置203）6~7：2個(gè)字節(jié)，記錄解壓所需的最小版本，同數(shù)據(jù)區(qū)本地文件頭的解壓所需版本，apk設(shè)置204) 8~9：2個(gè)字節(jié)，通用位標(biāo)記，同數(shù)據(jù)區(qū)本地文件頭的通用位標(biāo)記 5）壓縮方法、文件最后修改時(shí)間、文件最后修改日期、CRC-32校驗(yàn)碼、壓縮后大小、未壓縮大小、文件名長度、擴(kuò)展區(qū)長度，這幾個(gè)字段的含義都等同于數(shù)據(jù)區(qū)本地文件頭對(duì)應(yīng)字段的含義 6）32~33：2個(gè)字節(jié)，記錄文件注釋的長度7）34~35：2個(gè)字節(jié)，記錄文件開始位置的磁盤編號(hào)，一般傳0即可 8）內(nèi)部文件屬性、外部文件屬性，一般也是傳0即可 9）42~45：4個(gè)字節(jié)，記錄數(shù)據(jù)區(qū)本地文件頭相對(duì)于壓縮包開始位置的偏移量

3、中央目錄記錄尾部區(qū)

中央目錄記錄尾部主要作用是用來定位中央目錄記錄區(qū)的開始位置，同時(shí)記錄壓縮包的注釋內(nèi)容

1）0~3：4個(gè)字節(jié)，中央目錄記錄尾部開頭標(biāo)記：0x06054b50，用于解壓時(shí)，查找判斷中央目錄尾部的起始位置 2）4~5：2個(gè)字節(jié)，記錄中央目錄記錄尾部區(qū)所在磁盤編號(hào)3）6~7：2個(gè)字節(jié)，記錄中央目錄開始位置所在的磁盤編號(hào)4）8~9：2個(gè)字節(jié)，該磁盤上所記錄的核心目錄數(shù)量5）10~11：2個(gè)字節(jié)，zip壓縮包中的文件總數(shù)6）12~15：4個(gè)字節(jié)，整個(gè)中央目錄的大小（以字節(jié)為單位）7）16~19：4個(gè)字節(jié)，中央目錄開始位置相對(duì)位移8）20~21：2個(gè)字節(jié)，注釋內(nèi)容的長度（假設(shè)長度為n） 9）22~22+n：n個(gè)字節(jié)，注釋內(nèi)容

三、壓縮包解壓過程

1、先從中央目錄尾部區(qū)著手，目標(biāo)是找到中央目錄尾部開頭標(biāo)記：0x06054b50，從上述對(duì)zip壓縮包結(jié)構(gòu)分析可知，中央目錄尾部區(qū)除了注釋內(nèi)容之外，固定大小占22個(gè)字節(jié)，那么假如注釋內(nèi)容為空的時(shí)候，將指針從文件尾部往前移動(dòng)22個(gè)字節(jié)，然后讀取4個(gè)字節(jié)的數(shù)據(jù)，就正好是中央目錄尾部開頭標(biāo)記：0x06054b50，但是注釋內(nèi)容是否為空在實(shí)際操作中是不可得知的，所以只能設(shè)置一個(gè)循環(huán)，每次遞增一個(gè)字節(jié)，不斷推測注釋內(nèi)容的長度，又因?yàn)樽⑨岄L度用2個(gè)字節(jié)表示，那么注釋長度最大只能是65535個(gè)字節(jié)，所以可以在0~65535這個(gè)范圍內(nèi)不斷推測注釋內(nèi)容的長度. 下面是java代碼實(shí)現(xiàn)的查找中央目錄尾部開始位置的案例：

/**     * 查找中央目錄結(jié)尾的開始位置     * @param zipContents     * @return     */    private static int findZipEndOfCentralDirectoryRecord(ByteBuffer zipContents) {//判斷是否小端模式排列        assertByteOrderLittleEndian(zipContents);        int archiveSize = zipContents.capacity();        //由于核心目錄尾部大小至少是22個(gè)字節(jié)，小于22就是沒意義的        if (archiveSize < 22) {return -1;        }        //注釋內(nèi)容長度只可能是： 【壓縮包大小 - 核心目錄尾部固定大小（22字節(jié)）】與 【注釋內(nèi)容最大長度】中的最小值        int maxCommentLength = Math.min(archiveSize - 22, 65535);        //假如沒有注釋內(nèi)容，那么核心目錄尾部開始位置是：壓縮包大小 -22        int eocdWithEmptyCommentStartPosition = archiveSize - 22;        // 循環(huán)查找,假設(shè)沒有注釋內(nèi)容到每次遞增一個(gè)字節(jié)的注釋內(nèi)容，查找出：核心目錄結(jié)尾標(biāo)識(shí)0x06054b50        for (int expectedCommentLength = 0; expectedCommentLength < maxCommentLength; expectedCommentLength++) {int eocdStartPos = eocdWithEmptyCommentStartPosition - expectedCommentLength;            // 核心目錄結(jié)尾標(biāo)志：0x06054b50（十進(jìn)制為：101010256）, 標(biāo)志位長度為4個(gè)字節(jié)，int類型剛好4字節(jié)            // zipContents.getInt(eocdStartPos)，即從eocdStartPos位置開始讀取4個(gè)字節(jié)的內(nèi)容            if (zipContents.getInt(eocdStartPos) == 101010256) {//核心目錄結(jié)尾標(biāo)志的開始位置偏移20個(gè)字節(jié)就是注釋內(nèi)容長度，因?yàn)樽⑨寖?nèi)容長度是2個(gè)字節(jié)，對(duì)應(yīng)就是short類型的大小                int actualCommentLength = getUnsignedInt16(zipContents, eocdStartPos + 20);                // 要是從壓縮包中讀取到的注釋長度跟循環(huán)查找計(jì)算出的注釋長度一致，那么就是找到了確切的核心目錄結(jié)尾標(biāo)記的開始位置了                if (actualCommentLength == expectedCommentLength) {return eocdStartPos;                }            }        }        return -1;    }static void assertByteOrderLittleEndian(ByteBuffer buffer) {if (buffer.order() != ByteOrder.LITTLE_ENDIAN) {throw new IllegalArgumentException("ByteBuffer byte order must be little endian");        }    }

2、中央目錄尾部開始位置找到之后，那么可以從中獲取到中央目錄的開始位置，中央目錄的大小，以及中央目錄記錄條目總數(shù)3、接著，又可以從中央目錄中讀取到本地文件頭相對(duì)壓縮包開始位置的偏移量，那么就能讀到本地文件記錄，并從中解壓出文件數(shù)據(jù)，大概的解壓流程就到此結(jié)束啦

【擴(kuò)展知識(shí)】

剛才在java舉例中有涉及到一個(gè)小端排序問題，因?yàn)樵贘vm中默認(rèn)都是按大端模式儲(chǔ)存, 而 .ZIP格式的數(shù)據(jù)是按小端模式編排的，所以需要手動(dòng)對(duì)ByteBuffer中的數(shù)據(jù)進(jìn)行小端排序，那么，什么是小端模式，什么是大端模式呢？

1、大端模式：Big-Endian就是高位字節(jié)排放在內(nèi)存的低地址端，低位字節(jié)排放在內(nèi)存的高地址端，大端模式是跟人讀寫習(xí)慣是一致的，比如：數(shù)字0x12345678 與 0x11223344,大端模式表示如下：

低地址 ----------------------------------------------------> 高地址0x12  |  0x34  |  0x56  |  0x78 | 0x11  |  0x22  |  0x33  |  0x44

2、小端模式：Little-Endian就是低位字節(jié)排放在內(nèi)存的低地址端，高位字節(jié)排放在內(nèi)存的高地址端，比如：數(shù)字0x12345678 與 0x11223344,小端模式表示如下：

低地址 ----------------------------------------------------> 高地址0x78  |  0x56  |  0x34  |  0x12 | 0x44  |  0x33  |  0x22  |  0x11

那么，為啥會(huì)存在大小端不統(tǒng)一的問題呢？

既然大小端都有存在的必要性，那大小端模式各有啥優(yōu)勢呢？

【注意】字符是只有1個(gè)字節(jié)，故對(duì)于字符不存在大小端模式之分，只有大于1個(gè)字節(jié)的才分大小端模式

【實(shí)踐案例】

理論說了一大篇幅，想必各位看官已是頭昏腦漲，咱們來動(dòng)手分析一個(gè)壓縮包看看，是否如咱們理論所言那般，下面是一個(gè)安卓安裝包（.apk）的案例： 1、首先，先找到中央目錄結(jié)尾標(biāo)志：0x06054b50，因?yàn)閦ip格式是小端模式，那么，咱們看到的應(yīng)該是：50 4B 05 06, 用010 Editor打開apk，成功查找到中央目錄結(jié)尾標(biāo)志從截圖可以看到： 1）當(dāng)前磁盤編號(hào)為：0x0000（即十進(jìn)制：0） 2）中央目錄開始位置的磁盤編號(hào)也是：0x0000（即十進(jìn)制：0）, 3）該磁盤上所記錄的中央目錄數(shù)量：0xD236(轉(zhuǎn)為大端模式就是0x36D2，十進(jìn)制：14034) 4）zip壓縮包中的文件總數(shù)：0xD236(轉(zhuǎn)為大端模式就是0x36D2，十進(jìn)制：14034) 5）中央目錄大小：0x7A1E1600(轉(zhuǎn)為大端模式就是0x00161E7A，十進(jìn)制：1449594), 6）中央目錄開始位置的相對(duì)位移：0x2A03480C(轉(zhuǎn)為大端模式就是0x0C48032A，十進(jìn)制：206045994) 7）注釋長度：0x0000(即長度為0) 2、從第一步中，咱們可以知道中央目錄開始位置是在地址206045994，那么查一下這個(gè)地址： 從截圖可以看到 ① 從地址206045994開始讀取4個(gè)字節(jié)，得到0x504B0102, 按大端模式排序?yàn)椋?x02014b50, 剛好就是前面提到的中央目錄文件頭標(biāo)識(shí)② 壓縮所用版本：0x1400(轉(zhuǎn)為大端模式就是0x0014，十進(jìn)制：20) ③ 解壓所需版本：0x1400(轉(zhuǎn)為大端模式就是0x0014，十進(jìn)制：20) ④ 通用位標(biāo)記：0x0808(十進(jìn)制：2056, 那么就是第3位設(shè)置為1,說明數(shù)據(jù)區(qū)有文件描述符) ⑤ 壓縮方法：0x0800(轉(zhuǎn)為大端模式就是0x0008，十進(jìn)制：8) ⑥ 文件最后修改時(shí)間：0x4B79(轉(zhuǎn)為大端模式就是0x794B，二進(jìn)制：?0111100101001011?)

按照上面的MS-DOS時(shí)間編碼規(guī)則，對(duì)二進(jìn)制01111 001010 01011?進(jìn)行 拆分計(jì)算，時(shí)：01111（十進(jìn)制：15），分：001010（十進(jìn)制：10），秒：01011（十進(jìn)制：11，這是秒除以2的值，故實(shí)際秒為11 * 2 = 22），那么，文件的最后修改時(shí)間為：15:10:22⑦ 文件最后修改日期：0xE552(轉(zhuǎn)為大端模式就是0x52E5，二進(jìn)制：?0101001 0111 00101??)，年：0101001（十進(jìn)制：41，1980 + 41 = 2021），月： 0111（十進(jìn)制：7），日：00101（十進(jìn)制：5），那么文件的最后修改日期為：2021-7-5，比對(duì)一下跟壓縮軟件的結(jié)果是一致的 ⑧ CRC-32校驗(yàn)碼：0x04D127C5(轉(zhuǎn)為大端模式就是0xC527D104),跟上述壓縮軟件結(jié)果也是一致的 ⑨ 壓縮后的大小：0x20E80900(轉(zhuǎn)為大端模式就是0x0009E820, 十進(jìn)制：?649248，約為634.03KB) ⑩ 未壓縮的大小：0xA0D91B00(轉(zhuǎn)為大端模式就是0x001BD9A0, 十進(jìn)制：??1825184?，約為1.74MB),跟上述壓縮軟件結(jié)果也是一致的 ? 文件名長度：0x1400(轉(zhuǎn)為大端模式就是0x0014，十進(jìn)制：??20） ? 擴(kuò)展區(qū)長度、文件注釋長度、文件開始位置的磁盤編號(hào)、內(nèi)部文件屬性都是：0x0000 ? 外部文件屬性、本地文件頭的相對(duì)位移都是：0x00000000 ? 文件名：0x4D 45 54 41 2D 49 4E 46 2F 4D 41 4E 49 46 45 53 54 2E 4D 46, 這些是字符ASCII碼，轉(zhuǎn)為字符是：META-INF/MANIFEST.MF

【注意】假如文件名有中文的話，那這里存放UTF-8編碼數(shù)據(jù)，中文一般先轉(zhuǎn)換為Unicode編碼字符，然后用UTF-8編碼方式存儲(chǔ)(Unicode只是一個(gè)符號(hào)集，它只規(guī)定了符號(hào)的二進(jìn)制代碼，卻沒有規(guī)定這個(gè)二進(jìn)制代碼應(yīng)該如何存儲(chǔ), UTF-8是unicode的一種實(shí)現(xiàn)方式，unicode實(shí)現(xiàn)方式還有UTF-16和UTF-32)

【UTF-8小知識(shí)】UTF-8最大的一個(gè)特點(diǎn)，就是它是一種變長的編碼方式。它可以使用1~4個(gè)字節(jié)表示一個(gè)符號(hào)，根據(jù)不同的符號(hào)而變化字節(jié)長度。 UTF-8的編碼規(guī)則很簡單，只有2條：

1??對(duì)于單字節(jié)的符號(hào)，字節(jié)的第1位（字節(jié)的最高位）設(shè)為0，后面7位為這個(gè)符號(hào)的unicode碼。因此對(duì)于英語字母，UTF-8編碼和ASCII碼是相同的。 2??對(duì)于n字節(jié)的符號(hào)（n>1），第1個(gè)字節(jié)的前n位都設(shè)為1，第n+1位設(shè)為0，后面字節(jié)的前兩位一律設(shè)為10。剩下的沒有提及的二進(jìn)制位，全部為這個(gè)符號(hào)的unicode碼 比如：已知“嚴(yán)”的unicode是4E25（100111000100101），根據(jù)上表，可以發(fā)現(xiàn)4E25處在第3行的范圍內(nèi)（0000 0800-0000 FFFF），因此“嚴(yán)”的UTF-8編碼需要3個(gè)字節(jié)，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，從“嚴(yán)”的最后1個(gè)二進(jìn)制位開始，依次從后向前填入格式中的x，多出的位補(bǔ)0。這樣就得到了“嚴(yán)”的UTF-8編碼是“11100100 10111000 10100101”，轉(zhuǎn)換成十六進(jìn)制就是E4B8A5

? 因?yàn)閿U(kuò)展區(qū)長度為0，所以文件名后面緊跟壓縮之后的文件數(shù)據(jù)，由上面分析的壓縮長度為649248，所以后面649248個(gè)字節(jié)的數(shù)據(jù)都是文件數(shù)據(jù)

? 因?yàn)槭潜镜匚募^的通用標(biāo)志位第3位設(shè)置為1，所以存在數(shù)據(jù)描述區(qū)，數(shù)據(jù)描述區(qū)標(biāo)識(shí)：0x504B0708(轉(zhuǎn)換為大端模式：0x08074b50)

? 數(shù)據(jù)描述符中的CRC-32校驗(yàn)碼、壓縮大小、未壓縮大小跟本地文件頭的值一致