上一節實現了主GPT頭的信息提取，這一節繼續提取整個的GPT數據，並且將GPT分區表和MBR分區表兩種格式融合成一個模塊，使主調函數（也可以說是使用者）不需要關心磁盤的分區表類型：它太底層了，確實不需要過多的關心。

　　繼續看上一節的圖1，這裏就不貼圖了，LBA1的主GPT頭給出了分區信息的總數，還有每一個分區信息所占用的字節數，分區信息的結構如表1：

表1 分區信息結構（GPT Entry）

可以看到，這個結構非常之簡潔，只標註了起始扇區，結束扇區，分區類型，GUID，屬性，分區名，而不關心磁頭、磁道等等信息。

需要特殊說明的是，整個分區信息的結構，也就是從LBA2到LBA34（MS總是給劃分128個分區信息），是完全連續的，不依靠任何扇區等信息去定位，也就是說，第n個分區信息的結構起始地址，僅僅根據LBA2的起始地址+分區字節數*n來確定，最常見的是微軟定義的128個分區信息，512字節扇區，128字節的分區信息字節數，所以最常見的是每一個扇區4個分區信息，密集的排列32個扇區。然而正確的計數方法是每128個字節一個分區信息，密集排列128個。當扇區不是512字節時（註意這裏不要跟簇混淆，目前我還沒見過不是512字節扇區的存儲器），每個扇區存儲的分區信息有可能不是4個，下面的程序規避了這個問題，采用了一個新的磁盤讀寫函數——ReadDiskData而不是ReadSectorData——來防止讀分區信息出現錯誤。

 1 /*******************************************************************************
 2 
 3 函 數 名：GetVolumeNumberOfGPT
 4 
 5 函數功能：獲取一個GPT格式的磁盤中有效分卷數
 6 
 7 輸入參數：
 8 
 9           hDisk：磁盤句柄
10 
11           DPT：  磁盤DPT
12 
13 返回參數：int型，返回DPT中包含的有效分區數量（包含未格式化的分卷），如果該DPT不是GPT
14 
15         分區形式，將會返回-1
16 
17 *******************************************************************************/
18 
19 int GetVolumeNumberOfGPT(HANDLE hDisk, DPT_Info* DPT)
20 
21 {
22 
23     if (DPTDetermination(DPT) == DPT_MBR)
24 
25         return -1;
26 
27     GPTEntry_Byte GPTEbuffer;
28 
29     GPTEntry_Info GPTEinfo;
30 
31     PGPTH_Info PGPTH;
32 
33     GetPGPTH(hDisk, &PGPTH);
34 
35     int ValidPartitions = 0;
36 
37     for (int i = 0; i < PGPTH.PartitionTables; i++)
38 
39     {
40 
41         ReadDiskData(
42 
43             hDisk, //讀取磁盤句柄
44 
45             SECTOR_SIZE * PGPTH.PartitionStart + i * PGPTH.BytesPerPartitionTable, //計算讀取的GPTE位置
46 
47             (uint8_t*)(void*)&GPTEbuffer, //緩沖區地址
48 
49             sizeof(GPTEntry_Byte)); //字節數
50 
51         GetGPTEInfo(&GPTEbuffer, &GPTEinfo);
52 
53         if (GUIDcmp(&(GPTEinfo.TypeGUID), (GUID_Info*)&GUID_ptUnuse))
54 
55             break;
56 
57         else
58 
59             ValidPartitions++;
60 
61     }
62 
63     return ValidPartitions;
64 
65 }

分區類型是有規定的，一般有表2的幾種GUID；屬性標誌也是有規定的，見表3。

表2：分區類型的16Byte GUID

上面的GUID數值比較有意思，根據winHex得到的扇區數據，它將16字節的GUID分成了5部分，在很多編譯器中已經有GUID結構體的定義不過是4部分的，在這裏無法使用，所以我們另外定義一個結構

 1 typedef struct
 2 
 3 {
 4 
 5     uint32_t Part1;                 //GUID第1部分
 6 

 7     uint16_t Part2;                 //GUID第2部分
 8 
 9     uint16_t Part3;                 //GUID第3部分
10 
11     uint16_t Part4;                 //GUID第4部分
12 
13     uint48_t Part5;                 //GUID第5部分
14 
15 }GUID_Info;

來表示GUID。而有意思的地方在於，這5部分並不是單純的完全大端或者小端模式，它是混合著來的，前三個部分是小端，後兩個部分是大端，我們在讀取結構的時候一定要註意這點。

表3：分區屬性

以上的屬性列表並不完全，至少我的硬盤分區之後，類型就是0x80。因為只有一個字節有用的信息，一個枚舉類型就足以解決問題。

現在我們實際看一個擁有4個分區信息的LBA，如圖1：

圖1 LBA分區

如圖所示，紅框框起來的部分就是一個分區信息結構，比較精髓的部分是粉色框裏的72字節，它是以UTF16的小端模式編碼的，因為涉及到了中文問題，UTF16LE解碼比較復雜，在這裏我們直接用wchar_t來獲取這個結構：

 1 typedef struct
 2 
 3 {
 4 
 5     uint8_t TypeGUID[16];           //用GUID表示的分區類型
 6 
 7     uint8_t UniqueGUID[16];         //用GUID表示的分區唯一標示符
 8 
 9     uint8_t SectorStart[8];         //該分區的起始扇區，用LBA值表示
10 
11     uint8_t SectorEnd[8];           //該分區的結束扇區(包含)，用LBA值表示，通常是奇數
12 
13     uint8_t PartitionAttrib[8];     //該分區的屬性標誌
14 
15     WCHAR   PartitionName[36];      //UTF-16LE編碼的人類可讀的分區名稱，最大32個字符。
16 
17 }GPTEntry_Byte;

現在GPT結構已經可以完整的讀取，由於博文實在實驗階段性完成後做的，所以沒有截圖（=_=尷尬）。

接下來的步驟是整合GPT和MBR。由於DPT引導到GPT和MBR的部分可以直接整合，所以原DPT部分代碼可以不動，但不同的是GPT是通過讀取LBA直接得到每個分區的起始扇區、終止扇區、分區類型等等，而MBR方式是先通過DPT得到小於等於4個引導扇區的位置，然後對這幾個引導扇區進行解析，每個引導扇區對應一個分區信息。

在使用其他的一些庫的時候，筆者受到困擾的地方就是，API函數太多，有很多的庫有不同的API功能是接近的，同時又有很多API名字相近但功能截然不同，所以為了避免這種情況，在這裏盡量縮減API。根據這個思想，可以構建大致的流程如下：首先由用戶提取分區總數，然後用戶來進行malloc操作來根據分區數建立分區列表，然後根據分區列表可以找到每個分區的引導扇區位置。在本節中，所謂的“分區信息”是針對於分區表的分區信息，事實上根據前幾節的介紹，分卷容量並不一定等於分區容量，所以目前的代碼中都是以Partition代表分區，而以Volume代表分卷。

詳細的代碼結構這裏不進行更多的截取，有關代碼的調用方式在main.cpp中很容易的看到。在壓縮包裏有基於VS2015community環境的完整工程。

最後貼上一張完整的分區列表運行結果（磁盤3是我的移動硬盤，磁盤4是我的64GB SD卡）。

圖2 代碼運行結果

工程下載地址：https://files.cnblogs.com/files/Coder-Ku/NTFS5.rar

在STM32上實現NTFS之5：GPT分區表的C語言實現（2）GPT實現以及統一方式讀取磁盤分區