FatFs 之二路径规则、字符编码、编码页、卷管理详解

梦里梦外; 2021-12-03 23:43 520阅读 0赞

# 写在前面 #

本文的内容部分来自于 FatFs 的官方文档，但是添加了一些额外的章节及内容。其并不是原版 FatFs 的官方文档的翻译。如果关注与 FatFs 的官方文档，请从本文的 **参考** 章节前去查看即可！

# 路径名称的格式 #

FatFs 中路径名的格式类似于 DOS/Windows 的文件名规格：`[drive#:][/]directory/file`。FatFs 支持长文件名（LFN）和 8.3 格式文件名（SFN）。 当 FF\_USE\_LFN >= 1 时，可以使用 LFN。与 DOS/Windows API 方式相同，FatFs的子目录也用 \\ 或 / 分隔。自动跳过并忽略重复的分隔符。唯一的区别是指定逻辑驱动器的驱动器前缀是**数字+冒号**的形式。 省略驱动器前缀时，驱动器号被假定为默认驱动器（驱动器 0 或当前驱动器）。例如：`0:/folder/myfile.exe`。  
  控制字符（\\0 到 \\x1F）被识别为路径名的末尾。 路径名中的前导或嵌入空格在 LFN 配置中作为名称的一部分有效，但在非 LFN 配置中，空格被识别为路径名的末尾。 两种配置都会忽略尾随的空格和点。  
  在默认配置（FF\_FS\_RPATH == 0）中，它没有像面向操作系统的文件系统那样的当前目录的概念。 卷上的每个对象始终以从根目录开始的完整路径名指定。 不允许使用点目录名称（“.” 或者 “…”）。 标题分隔符被忽略，它可以存在或省略。 默认驱动器固定为驱动器 0。  
  启用相对路径（FF\_FS\_RPATH> = 1）时，如果存在标题分隔符，则从根目录开始遵循指定的路径。 如果没有，则从 f\_chdir 函数设置的驱动器的当前目录开始跟随。 路径名也允许使用点名称。 默认驱动器是 f\_chdrive 功能设置的当前驱动器。

<table> 
 <thead> 
  <tr> 
   <th>Path name</th> 
   <th>FF_FS_RPATH == 0</th> 
   <th>FF_FS_RPATH &gt;= 1</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>file.txt</td> 
   <td>驱动器 0 的根目录中的文件</td> 
   <td>当前驱动器的当前目录中的文件</td> 
  </tr> 
  <tr> 
   <td>/file.txt</td> 
   <td>驱动器 0 的根目录中的文件</td> 
   <td>当前驱动器根目录中的文件</td> 
  </tr> 
  <tr> 
   <td></td> 
   <td>驱动器 0 的根目录</td> 
   <td>当前驱动器的当前目录</td> 
  </tr> 
  <tr> 
   <td>/</td> 
   <td>驱动器 0 的根目录</td> 
   <td>当前驱动器的根目录</td> 
  </tr> 
  <tr> 
   <td>2:</td> 
   <td>驱动器 2 的根目录</td> 
   <td>驱动器 2 的当前目录</td> 
  </tr> 
  <tr> 
   <td>2:/</td> 
   <td>驱动器 2 的根目录</td> 
   <td>驱动器 2 的根目录</td> 
  </tr> 
  <tr> 
   <td>2:file.txt</td> 
   <td>驱动器 2 的根目录中的文件</td> 
   <td>驱动器 2 的当前目录中的文件</td> 
  </tr> 
  <tr> 
   <td>…/file.txt</td> 
   <td>无效名</td> 
   <td>父目录中的文件</td> 
  </tr> 
  <tr> 
   <td>.</td> 
   <td>无效名</td> 
   <td>本目录</td> 
  </tr> 
  <tr> 
   <td>…</td> 
   <td>无效名</td> 
   <td>当前目录的父目录(*)</td> 
  </tr> 
  <tr> 
   <td>dir1/…</td> 
   <td>无效名</td> 
   <td>当前目录</td> 
  </tr> 
  <tr> 
   <td>/…</td> 
   <td>无效名</td> 
   <td>根目录（始终顶级）</td> 
  </tr> 
 </tbody> 
</table>

此外，驱动器前缀可以是预定义的任意字符串。 当选项 FF\_STR\_VOLUME\_ID == 1 时，任意字符串卷ID 也可用作驱动器前缀。 例如 “flash：file1.txt”，“ram：temp.dat”或“sd：”。 当 FF\_STR\_VOLUME\_ID == 2 时，可以使用 Unix 样式的驱动器前缀。 例如 “/flash/file1.txt”，“/ ram / temp.dat”或“/ usb”。 但是，它无法遍历驱动器，例如 “/flash/…/ram/temp.dat”。 Unix 样式的驱动器前缀可能会导致卷ID 和文件名之间的标识混淆。 例如，“/flash” 是什么意思，根目录上的文件“flash”没有驱动器前缀或驱动器前缀为“flash”？ 如果标题斜杠后面的字符串与任何卷ID匹配，则将其视为驱动器前缀。

备注：在此版本中，双点名称 “…” 不能跟随 exFAT 卷上的父目录。 它将作为 “.” 工作。 并留在那里。

# 8.3格式文件名 #

8.3 格式的文件名，又称短文件名（Short File Name，SFN）是 DOS + FAT12/FAT16 时代采用的命名方法，如下图所示：  
![在这里插入图片描述][20190724131917438.png]

*  **8：** 是指文件名或目录名的主体部分小于等于 8 个字节，目录名是没有扩展名的，文件名可以有个扩展名，表示文件的类型
 *  **. ：** 分隔符，将文件名与扩展名分开
 *  **3：** 是指文件名的扩展名部分（扩展名）小于等于 3 个字节。

根据 8.3 格式的命名规范，多余的字符将被忽略，DOS 默认的做法是将多余的字符替换为 ~ x 。其中 x 是数字，例如，123456~8.TXT。并且如果一个文件没有扩展名，那么它后面的点将没有意义，即：file 和 file. 是同一个文件。  
  此外，FAT 文件本身不区分大小写，但是在绝大部分系统中，都是使用名字会被统一转换为大写！FatFs 也是如此！

# 长文件名 #

长文件名（Long File Name，LFN），凡是文件的基础文件名（不包含扩展名）超过 8 字节或扩展名超过 3 字节的文件名，都被称为“长文件名”。

# 合法字符与大小写敏感性 #

在 FAT 文件系统上，对象名称（文件/目录名称）的合法字符为 0-9 A-Z ！ ＃$％＆’（） - @ ^ \_\` \{\} 〜 以及任何扩展字符。 扩展字符的有效字符代码取决于配置的代码页。 在 LFN 支持的系统下 + , ; = \[\]和空格也是合法的对象名称，空格和点可以放在路径名中的任何位置，但名称的末尾除外。  
  FAT 文件系统对卷上的对象名称不区分大小写。 FAT 卷上的对象名称在不区分大小写的情况下进行比较。 例如，这三个名称 file.txt，File.Txt 和 FILE.TXT是相同的。 扩展字符也是这样的规则。\*\*\* 在 FAT 卷上创建对象时，自动将转换为大写后的名称记录到 SFN 条目，并且在启用 LFN 功能时将原始名称记录到 LFN 条目。\*\*\*  
  对于 CJK（DOS / DBCS）的 MS-DOS 和 PC DOS，扩展字符被记录到 SFN 条目而没有大小写转换，并且区分大小写。 当 DOS/DBCS 系统在卷上创建任何具有扩展字符的对象时，这会导致与 Windows 系统兼容的问题; 因此，不应在这些系统共享的FAT 卷上使用具有 DBCS 扩展字符的对象名称。 FatFs 使用 DBCS 配置（DOS/DBCS 规范）仅对非 LFN 的扩展字符区分大小写。 但在 LFN 配置中，FatFs 对扩展字符（Windows NT规范）不区分大小写。

# 字符编码 #

## 第一阶段 ##

美国最初发明计算机后，首先遇到了字符编码的问题，他们想了半天，最终发明了采用一个字节（8 个比特位）一共可以组合出256(2的8次方)种不同的状态的方式表示他们的语言字符，对于他们来说足够了。而且早年的 ASCII 只定义了 128 个字符（可打印的 96 个），剩下最高位为 1 的 128 个码位算是空出来的。

## 第二阶段 ##

第二阶段，计算机开始流行，原来的 128 个已经不够用了，于是就启用了原来空着的高 128 个。从 128 到 255 这一页的字符集被称”扩展字符集“。IBM 搞 PC 机的时候定义了 codepage 437，把高 128 个码位也用上了。然而，计算机继续流行，现在的 256 个字符也不够用了，于是就到了第三个阶段！

## 第三阶段 ##

ASCII 无法表示其他国家的文字，例如中文、日文、韩文等。人们就想到的一种办法：用两个 byte 来表示一个字符。ASCII 不是空出来了高128个码位吗？第一个 byte 在这高128里取值，再和第二个byte结合就可以表示最多 128x256 = 32768 个字符了。程序在处理字符串的时候，遇到有 byte < 128 的就认为是 ASCII，遇到 >=128的就把下一个 byte 也读进来，换算成一个字符。我国的第一版字符编码 GB2312 编码就是这个方案的实现，其他国家也都有各自的实现！后来我国发现 GB2312 还是不够用，于是更改了表示策略扩展成了 GBK；再后来，GBK 无法表示某些少数民族的语言文字，我国再次扩展成 GB18030。  
  这种编码的方法，被称为 DBCS（Double-Byte Character Set， 双位元组字元集）。

## 第四阶段 ##

每个国家都有自己的 DBCS 实现方式，这就导致了各个国家的字符编码方式不一样！比如我国的的不同地区（香港、台湾）的 DBCS 实现方式也是不同的！这个时候 ISO（国际标谁化组织）站了出来解决这个问题。他们的方法简单粗暴：废除了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号 的编码！他们打算叫它 “Universal Multiple-Octet Coded Character Set”，简称 UCS, 俗称 “unicode”。举个例子，原来各地区的编码就好比方言，而 Unicode 就是全世界的官方统一语言。  
  需要注意的是，Unicode 仅仅是规定了字符的表示规则，但是没有实现！Unicode 有多种实现方案：主要有 UTF-8，UTF-16，UTF-32 等。如果对于字符集感兴趣，自行去 Google 查阅相关资料！

# 编码页（Code Page） #

编码页（Code Page），也称内码表，是由 IBM 的引入的一个概念。想当年，IBM 作为第一批计算机制造者，风光无限！为了可以灵活处理计算机的输入问题，他们在计算机中引入了用一张表的形式来标识编码的这种方式。编码页就是一个经过挑选的以特定顺序排列的字符内码列表。  
  后来，微软开始壮大，编码页被微软用来处理不同的地区的编码问题。每个地区的编码在 Windows 操作系统中，都有一个对应的编码页。这样，Windows 就可以根据不同的地址，以该地区的编码来显示该地区的文字了！新的 Windows 系统好像都开始使用 Unicode 编码了  
  字符编码的不同将影响我们使用的字符串相关的函数，错误的编码选择将导致字符串函数出现操作失败等不可预知的错误！举个例子，Windows 系统的 API 中，很多都是要区分字符集的，用过 Win32 编程的人应该深有体会！比较乐观的是，如果不涉及底层，我们通常不用去关心字符的编码处理，系统会为我们来处理这个问题。但是，看 FatFs 这样的文件系统，字符编码是必须要考虑的！

# Unicode API #

FatFs 根据用户配置，路径名以 ANSI/OEM 或 Unicode 来输入/输出。 FatFs中的函数中，指定路径名的参数类型定义为 TCHAR。 默认情况下，它是 char 的别名，用于路径名字符串的代码集是由 FF\_CODE\_PAGE 指定的 ANSI/OEM。 当FF\_LFN\_UNICODE 设置为 1 或更大时，TCHAR 的类型将切换为正确的类型以支持 Unicode 字符串。 当此选项指定 Unicode API 时，支持全功能 LFN 规范，并且 Unicode 特定字符（如✝☪✡☸☭）也可用于路径名。 它还会影响字符串I/O函数的数据类型和编码。 要定义文字字符串，\_T（s）和 \_TEXT（s）宏可用于自动选择 ANSI/OEM 或 Unicode。 下面显示的代码是定义文字字符串的示例。

f_open(fp, "filename.txt", FA_READ);      /* ANSI/OEM string (char) */
     f_open(fp, L"filename.txt", FA_READ);     /* UTF-16 string (WCHAR) */
     f_open(fp, u8"filename.txt", FA_READ);    /* UTF-8 string (char) */
     f_open(fp, U"filename.txt", FA_READ);     /* UTF-32 string (DWORD) */
     f_open(fp, _T("filename.txt"), FA_READ);  /* Changed by configuration (TCHAR) */

# 卷管理 #

FatFs 的正确工作需要每个卷（逻辑驱动器）的动态工作区，文件系统对象。 它通过 f\_mount 函数注册/取消注册到 FatFs 模块。 默认情况下，每个逻辑驱动器都绑定到具有相同驱动器号的物理驱动器，并且卷装入过程中将扫描驱动器上的 FAT 卷。 它读取引导扇区，并按照扇区0为SFD格式、第一分区、第二分区、第三分区和第四分区为 FDISK 格式的顺序检查它是否是FAT引导扇区。  
  当配置选项指定 FF\_MULTI\_PARTITION = 1 时，每个单独的逻辑驱动器都绑定到卷管理表（PARTITION VolToPart\[FF\_VOLUMES\];）指定的物理驱动器上的分区。 需要由用户定义卷管理表（PARTITION VolToPart\[FF\_VOLUMES\];）以解析逻辑驱动器和分区的映射。 以下代码是卷管理表的示例。

Example: "0:", "1:" and "2:" are tied to three pri-partitions on the physical drive 0 (fixed drive)
             "3:" is tied to an FAT volume on the physical drive 1 (removable drive)
    
    PARTITION VolToPart[FF_VOLUMES] = { 
        { 0, 1},     /* "0:" ==> 物理驱动器 0, 第 1 个分区 */
        { 0, 2},     /* "1:" ==> 物理驱动器 0, 第 2 个分区 */
        { 0, 3},     /* "2:" ==> 物理驱动器 0, 第 3 个分区 */
        { 1, 0}      /* "3:" ==> 物理驱动器 1, 自动检测 */
    };

下图显示了 FatFs 卷管理方式：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1pDU2hvdUNTRE4_size_16_color_FFFFFF_t_70]  
使用多分区配置时需要考虑一些因素。

*  具有两个或多个已安装分区的物理驱动器必须是不可移除的。 禁止系统操作时更改介质。
 *  只能指定四个主分区。 不支持扩展分区。
 *  Windows不支持可移动存储上的多个卷。 其只能识别第一个分区。

# 参考 #

1.  FatFs 官网文档 [http://elm-chan.org/fsw/ff/doc/filename.html][http_elm-chan.org_fsw_ff_doc_filename.html]
2.  Windows 官方中的字符编码

[20190724131917438.png]: /images/20211203/3fa724aa63b749faa8753ed98158b7af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1pDU2hvdUNTRE4_size_16_color_FFFFFF_t_70]: /images/20211203/04353a2ef1804c3ca2cb7710f46a32d5.png
[http_elm-chan.org_fsw_ff_doc_filename.html]: http://elm-chan.org/fsw/ff/doc/filename.html