FAT32的一個重要的特點是完全支持長文件名。長文件名依然是記錄在目錄項中的。
爲了低版本的OS或程序能正確讀取長文件名文件，系統自動爲所有長文件名文件創建了一個對應的短文件名，使對應數據既可以用長文件名尋址，也可以用短文件名尋址。不支持長文件名的OS或程序會忽略它認爲不合法的長文件名字段，而支持長文件名的OS或程序則會以長文件名爲顯式項來記錄和編輯，並隱藏起短文件名。
當創建一個長文件名文件時，系統會自動加上對應的短文件名，其一般有的原則：
(1)、取長文件名的前6個字符加上"~1"形成短文件名，擴展名不變。
(2)、如果已存在這個文件名，則符號"~"後的數字遞增，直到5。
(3)、如果文件名中"~"後面的數字達到5，則短文件名只使用長文件名的前兩個字母。通過數學操縱長文件名的剩餘字母生成短文件名的後四個字母，然後加後綴"~1"直到最後(如果有必要，或是其他數字以避免重複的文件名)。
(4)、如果存在老OS或程序無法讀取的字符，換以"_"
短文件格式的目錄項。其參數意義見表14：
| 表14 FAT32短文件目錄項32個字節的表示定義 | |||
| 字節偏移(16進制) | 字節數 | 定義 | |
| 0x0~0x7 | 8 | 文件名 | |
| 0x8~0xA | 3 | 擴展名 | |
| 0xB* | 1 | 屬性字節 | 00000000(讀寫) |
| 00000001(只讀) | |||
| 00000010(隱藏) | |||
| 00000100(系統) | |||
| 00001000(卷標) | |||
| 00010000(子目錄) | |||
| 00100000(歸檔) | |||
| 0xC | 1 | 系統保留 | |
| 0xD | 1 | 創建時間的10毫秒位 | |
| 0xE~0xF | 2 | 文件創建時間 | |
| 0x10~0x11 | 2 | 文件創建日期 | |
| 0x12~0x13 | 2 | 文件最後訪問日期 | |
| 0x14~0x15 | 2 | 文件起始簇號的高16位 | |
| 0x16~0x17 | 2 | 文件的最近修改時間 | |
| 0x18~0x19 | 2 | 文件的最近修改日期 | |
| 0x1A~0x1B | 2 | 文件起始簇號的低16位 | |
| 0x1C~0x1F | 4 | 表示文件的長度 | |
|
* 此字段在短文件目錄項中不可取值0FH,如果設值爲0FH，目錄段爲長文件名目錄段 |
長文件名的實現有賴於目錄項偏移爲0xB的屬性字節，當此字節的屬性爲：只讀、隱藏、系統、卷標，即其值爲0FH時，DOS和WIN32會認爲其不合法而忽略其存在。這正是長文件名存在的依據。
將目錄項的0xB置爲0F，其他就任由系統定義了，Windows9x或Windows 2000、XP通常支持不超過255個字符的長文件名。
系統將長文件名以13個字符爲單位進行切割，每一組佔據一個目錄項。所以可能一個文件需要多個目錄項，這時長文件名的各個目錄項按倒序排列在目錄表中，以防與其他文件名混淆。
長文件名中的字符采用unicode形式編碼(一個巨大的進步哦)，每個字符佔據2字節的空間。其目錄項定義如表15。
系統在存儲長文件名時，總是先按倒序填充長文件名目錄項，然後緊跟其對應的短文件名。從表15可以看出，長文件名中並不存儲對應文件的文件開始簇、文件大小、各種時間和日期屬性。文件的這些屬性還是存放在短文件名目錄項中，一個長文件名總是和其相應的短文件名一一對應，短文件名沒有了長文件名還可以讀，但長文件名如果沒有對應的短文件名，不管什麼系統都將忽略其存在。所以短文件名是至關重要的。
在不支持長文件名的環境中對短文件名中的文件名和擴展名字段作更改(包括刪除，因爲刪除是對首字符改寫E5H)，都會使長文件名形同虛設。
（長文件名如何與短文件名對應？僅靠她們之間的位置關係？）
長文件名和短文件名之間的聯繫光靠他們之間的位置關係維繫顯然遠遠不夠。其實，長文件名的0xD字節的校驗和起很重要的作用，此校驗和是用短文件名的11個字符通過一種運算方式來得到的。系統根據相應的算法來確定相應的長文件名和短文件名是否匹配。這個算法不太容易用公式說明，我們用一段c程序來加以說明。
假設文件名11個字符組成字符串shortname[],校驗和用chknum表示。得到過程如下：
int i，j,chknum=0;
for (i=11; i>0; i--)
chksum = ((chksum & 1) ? 0x80 : 0) + (chksum >> 1) + shortname[j++];
如果通過短文件名計算出來的校驗和與長文件名中的0xD偏移處數據不相等。系統無論如何都不會將它們配對的。
依據長文件名和短文件名對目錄項的定義，加上對簇的編號和鏈接，FAT32上數據的讀取便遊刃有餘了。
本文出自數據恢復網(www.sjhf.net),疏漏在所難免，希望指正。若需轉載請保留此信息；若需修改，請用以下方式與作者取得聯繫
1、http://www.sjhf.net
2、[email protected]
3、[email protected]