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)，疏漏在所难免，希望指正。
若需转载请保留此信息；
若需修改，请用以下方式与作者取得联系