据我所知 – NTFS支持Unicode文件名（UTF-16作为微软的声明？）。
但是官方的MSDN文档对于在FAT-32上使用什么代码页来存储文件名（文件path）非常含糊。
在这里它说， OEM代码页 （我假设CP437）是用来存储文件名： http : //msdn.microsoft.com/en-us/library/windows/desktop/dd317748.aspx
但是，事实certificate，可以有不同的OEM代码页与CP437是其中之一： http : //msdn.microsoft.com/en-us/library/windows/desktop/dd317752.aspx
而且我们现在所有的像mount这样的工具都支持更多不同的FAT代码页，而不仅仅是OEM代码页。
那么FAT-32文件名的实际cdepage是什么？ 这取决于FAT卷创build时的系统代码页。 FAT可以支持像UTF-16这样的真正的双字节字符集代码页吗？ 或者像UTF-8这样的多字节字符集编码是限制吗？
更具体的问题： 当我使用CreateFileW函数（如MSDN所述，使用UTF-16作为文件名代码页）在FAT-32卷上创build文件时会发生什么？
你可能不得不在这里试验。 这是一个很好的问题，我不是100％自信的，但是：
那么FAT-32文件名的实际代码页是什么？ 这取决于FAT卷创建时的系统代码页。
无论是系统的“OEM代码页”。
FAT可以支持像UTF-16这样的真正的双字节字符集代码页吗？ 或者像UTF-8这样的多字节字符集编码是限制吗？
不，我不相信FAT可以直接使用UTF-16或UTF-8。 也就是说，Microsoft将Unicode文件名存储在带外方法中。 一个文件有两个文件名。 （这也是如何可以有超过8.3个字符的文件名，以及。）
更具体的问题：当我使用CreateFileW函数（如MSDN所述，使用UTF-16作为文件名代码页）在FAT-32卷上创建文件时会发生什么？
传递给CreateFileW的Unicode文件名直接存储在带外文件名中。 它被重新编码到OEM代码页（无论发生在系统上）并被放置在那里。 如果不能转换成OEM代码页，或者超过8.3个字符，Windows会调用文件FILENA~1.TXT 。
首先， 这个页面告诉我们OEM代码页！= Windows代码页：
创建FAT文件的非Unicode应用程序有时必须使用标准C运行时库转换函数来在Windows代码页字符集和OEM代码页字符集之间进行转换。 使用文件系统函数的Unicode实现，不需要执行这样的翻译。
在一个典型的美国系统上，OEM代码页是“CP437” ，但Windows代码页是Windows-1252 （我相信FooA调用使用Windows代码页，通常是美国机器上的Windows-1252，但取决于环境）。
如果您有一个FAT卷可用，您可以看到这在实际中。 字符“Σ”（U + 03a3）在Windows-1252中不存在，但在CP437中。 您可以使用dir /X来查看短文件名和长文件名。 用一个名为asdfΣ.txt的文件，你会看到：
ASDFΣ.TXT asdfΣ.txt
但是，使用名为“asdfΛ.txt”（Λ不在CP437或Windows-1252中）的文件，您将看到：
ASDF~1.TXT asdf?.txt
（你可能会看到? ，因为cmd.exe的字体不能显示Λ。）
有关长文件名的信息，请参阅这篇维基百科文章 。
另外，有趣的是，如果你命名一个文件“asdf©.txt”，你可能会得到：
ASDFC.TXT asdfc.txt
…我不是100％肯定的，但是我认为Windows聪明地决定用“c”代替©，并且同样地显示它。 如果您将字体更改为不基于光栅的内容（如Consolas），则会看到：
ASDFC.TXT asdf©.txt
这就是为什么你应该使用FooW函数。
基本的FAT或FAT32目录条目仅支持当前OEM代码页中的短名称 （旧的DOS 8.3格式）。 但是，在Windows下使用的VFAT（支持长文件名的FAT）可以在UTF-16中为每个文件存储额外的，所谓的长文件名 。