在FAT-32的Unicode文件名?

据我所知 – 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文件时会发生什么?

Solutions Collecting From Web of "在FAT-32的Unicode文件名?"

你可能不得不在这里试验。 这是一个很好的问题,我不是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中为每个文件存储额外的,所谓的长文件名