如题所述
====================源自DOS时代的8.3格式文件名规范====================
所谓8.3格式短文件名规范，就是型如 PROGRA~1（目录）或者
元素周~1.exe（文件）这样的名称——
“8”是指文件名或目录名的主体部分小于等于8个字节；
“3”是指文件名的扩展名部分小于等于3个字节。
另外还有一点，就是8.3文件名的有效字符不包括空格等特殊字符。
8.3短文件名格式规范是DOS+FAT12/FAT16时代遗留下的老规矩，
自从Windows95开始（其实据说从Windows for Groups 3.11开始），
Windows就已经能支持长文件名，但是为了向前兼容，特别是文件系统兼容性，
FAT文件系统均强制执行“为长文件名提供8.3兼容格式的短文件名”的特性。
因此你会看到，在FAT16/32文件系统上：
目录"program files"同时还拥有一个8.3规范的"PROGRA~1"短名称；
而文件"元素周期表.exe"也同时拥有一个"元素周~1.exe"的短名称。
[这有一点像类UNIX系统下的hardlink，一个对象拥有两个引用方式。]
PS：知道为什么IE浏览器的主程序叫做iexplore.exe 而不是iexplorer么？
就是为了照顾8.3短文件名规范。
===================NTFS文件系统与8.3格式规范的兼容性===================
NTFS文件系统支持unicode（UTF16）字符集文件名，最长达255个UTF16字符，
因此NTFS文件系统以及基于unicode字符集的32位NT内核Windows操作系统
本身都没有必要遵循16位DOS时代遗留的8.3格式短文件名规范。
但还是为了兼容性，NTFS文件系统也提供了一个可选的特性：8.3兼容格式。
Windows中这个特性默认是on，也就是说每当建立一个长文件名的对象的同时，
系统的NTFS驱动模块会自动建立一个合适的8.3格式短名称指向这个对象。
需要指出的是，这个特性并不像FAT文件系统中那样是强制执行的，
因此不同的磁盘实用程序或者操作系统可能有不同的执行方式——
比如windowsXP中可以用 fsutil behavior set disable8dot3 1 命令关闭，
驱动模块关闭这一特性后就不会每次都额外地建立一个附加的短名称，
这样在新建/重命名大量小文件/目录的时候能略微提升磁盘的写入速度，
（不用计算出一个合适的短文件名，也不用把这个额外的信息写入磁盘）。
=================非win32标准的老程序兼容性依赖8.3规范=================
但是，关闭这一特性之后可能导致某些古老的应用程序出现兼容性问题，
这些程序虽说是32位GUI界面的“windows应用程序”，却不完全遵循win32
程序的规范，而是通常混合有16位API，使用8.3格式短名称来引用文件。
很显然，如果在一个NTFS分区上根本就不为长文件名提供短名称，那么这些
16/32位混合型老程序将无法用8.3格式短名称来找到文件，当然会出错……
但是事情并不总是这么简单的——
最近我发现有几个老的应用程序不能正常启动，这包括曾经在科大校园网上
非常流行的科技大词典（主程序 ncce_win.exe，怎么样，熟悉不？）
细查原因，似乎只是放在NTFS分区才会出问题，移到FAT32的U盘上没问题。
后来我惊讶的发现：把U盘格成NTFS再放上这个程序也没问题！…… ……
数小时后，真正的的原因被找到了，说起来非常复杂，简而言之：
全路径上有一级目录不兼容短文件名格式，因此主程序找不到相关文件！
为什么会有一级目录不兼容8.3规范呢？
因为我的硬盘是在以前的硬盘出故障后新换的，换上来之前，我在
一个64位windows操作系统上把旧硬盘上还能读出的目录一一复制过来，
而那个64位windows关闭了NTFS的8.3兼容特性，复制来的目录和文件
都不具备附加的短名称，特别是我放应用程序的E:\program files\目录。
（64位windows理论上是完全不支持16位和16/32位混合程序的，因此可能
默认就关闭了NTFS驱动的8.3兼容性，或者也许是什么优化程序关闭的。）
然后我用GHOST恢复了系统分区，恢复的32位winXP并没有关闭8.3兼容性，
但关键问题是已经写入NTFS分区的（不具备短名称的）目录和文件并不会被
这个32位XP重建短文件名，系统只会对新建的文件或目录附加8.3文件名，
至于原先已经建立好的目录和文件，即使是重命名这种操作，也无法
“提醒”XP检查并追加上一个短文件名——这一点让我百思不得其解。
于是，当我把软件放在E:\program files\的子目录中时，虽然子目录
“科技词典”，以及ncce_win.exe等文件名都符合8.3规范，但是全路径上
有一个“program files”是不符合8.3规范的，并且没有等效的短名称代替，
所以某个API就无法用“E:\progra~1\科技词典\xxxxxxxx.xxx”定位文件了，
这个程序当然无法正常启动。
所谓8.3格式短文件名规范，就是型如 PROGRA~1（目录）或者
元素周~1.exe（文件）这样的名称——
“8”是指文件名或目录名的主体部分小于等于8个字节；
“3”是指文件名的扩展名部分小于等于3个字节。
另外还有一点，就是8.3文件名的有效字符不包括空格等特殊字符。
8.3短文件名格式规范是DOS+FAT12/FAT16时代遗留下的老规矩，
自从Windows95开始（其实据说从Windows for Groups 3.11开始），
Windows就已经能支持长文件名，但是为了向前兼容，特别是文件系统兼容性，
FAT文件系统均强制执行“为长文件名提供8.3兼容格式的短文件名”的特性。
因此你会看到，在FAT16/32文件系统上：
目录"program files"同时还拥有一个8.3规范的"PROGRA~1"短名称；
而文件"元素周期表.exe"也同时拥有一个"元素周~1.exe"的短名称。
[这有一点像类UNIX系统下的hardlink，一个对象拥有两个引用方式。]
PS：知道为什么IE浏览器的主程序叫做iexplore.exe 而不是iexplorer么？
就是为了照顾8.3短文件名规范。
===================NTFS文件系统与8.3格式规范的兼容性===================
NTFS文件系统支持unicode（UTF16）字符集文件名，最长达255个UTF16字符，
因此NTFS文件系统以及基于unicode字符集的32位NT内核Windows操作系统
本身都没有必要遵循16位DOS时代遗留的8.3格式短文件名规范。
但还是为了兼容性，NTFS文件系统也提供了一个可选的特性：8.3兼容格式。
Windows中这个特性默认是on，也就是说每当建立一个长文件名的对象的同时，
系统的NTFS驱动模块会自动建立一个合适的8.3格式短名称指向这个对象。
需要指出的是，这个特性并不像FAT文件系统中那样是强制执行的，
因此不同的磁盘实用程序或者操作系统可能有不同的执行方式——
比如windowsXP中可以用 fsutil behavior set disable8dot3 1 命令关闭，
驱动模块关闭这一特性后就不会每次都额外地建立一个附加的短名称，
这样在新建/重命名大量小文件/目录的时候能略微提升磁盘的写入速度，
（不用计算出一个合适的短文件名，也不用把这个额外的信息写入磁盘）。
=================非win32标准的老程序兼容性依赖8.3规范=================
但是，关闭这一特性之后可能导致某些古老的应用程序出现兼容性问题，
这些程序虽说是32位GUI界面的“windows应用程序”，却不完全遵循win32
程序的规范，而是通常混合有16位API，使用8.3格式短名称来引用文件。
很显然，如果在一个NTFS分区上根本就不为长文件名提供短名称，那么这些
16/32位混合型老程序将无法用8.3格式短名称来找到文件，当然会出错……
但是事情并不总是这么简单的——
最近我发现有几个老的应用程序不能正常启动，这包括曾经在科大校园网上
非常流行的科技大词典（主程序 ncce_win.exe，怎么样，熟悉不？）
细查原因，似乎只是放在NTFS分区才会出问题，移到FAT32的U盘上没问题。
后来我惊讶的发现：把U盘格成NTFS再放上这个程序也没问题！…… ……
数小时后，真正的的原因被找到了，说起来非常复杂，简而言之：
全路径上有一级目录不兼容短文件名格式，因此主程序找不到相关文件！
为什么会有一级目录不兼容8.3规范呢？
因为我的硬盘是在以前的硬盘出故障后新换的，换上来之前，我在
一个64位windows操作系统上把旧硬盘上还能读出的目录一一复制过来，
而那个64位windows关闭了NTFS的8.3兼容特性，复制来的目录和文件
都不具备附加的短名称，特别是我放应用程序的E:\program files\目录。
（64位windows理论上是完全不支持16位和16/32位混合程序的，因此可能
默认就关闭了NTFS驱动的8.3兼容性，或者也许是什么优化程序关闭的。）
然后我用GHOST恢复了系统分区，恢复的32位winXP并没有关闭8.3兼容性，
但关键问题是已经写入NTFS分区的（不具备短名称的）目录和文件并不会被
这个32位XP重建短文件名，系统只会对新建的文件或目录附加8.3文件名，
至于原先已经建立好的目录和文件，即使是重命名这种操作，也无法
“提醒”XP检查并追加上一个短文件名——这一点让我百思不得其解。
于是，当我把软件放在E:\program files\的子目录中时，虽然子目录
“科技词典”，以及ncce_win.exe等文件名都符合8.3规范，但是全路径上
有一个“program files”是不符合8.3规范的，并且没有等效的短名称代替，
所以某个API就无法用“E:\progra~1\科技词典\xxxxxxxx.xxx”定位文件了，
这个程序当然无法正常启动。
温馨提示：答案为网友推荐，仅供参考
第1个回答 2010-08-20
就是那种DOS下的8.3的规范，
可以这样写 C:\Progra~1
也可以这样写全名字的 "C:\Program File"，因为这个路径中的文件夹名有空格，要用两个英文输入法下的双引号来引上
可以这样写 C:\Progra~1
也可以这样写全名字的 "C:\Program File"，因为这个路径中的文件夹名有空格，要用两个英文输入法下的双引号来引上
第2个回答 2010-08-20
这是为了符合8.3文件名的缩写
