当传递名称以空格字符结尾的现有目录时,SHParseDisplayName失败,并显示ERROR_FILE_NOT_FOUND

我正在开发文件管理器应用程序,并且注意到某些功能不适用于以空格符号结尾的现有文件夹。例如“ E:\ 1 \”。这并非特定于此特定文件夹,而是确实适用于任何以空格作为文件夹名称最后一个字符的人。对于此类文件夹,SHParseDisplayName返回ERROR_FILE_NOT_FOUND

我从C ++像这样打电话给SHParseDisplayName

ITEMIDLIST* idPtr = nullptr;
const auto result = SHParseDisplayName(L"E:\\1 \\",nullptr,&idPtr,nullptr);

documentation没有指定任何边缘情况,也没有指定对输入路径进行预处理的任何方式。无论如何,我尝试用引号将其修饰:

SHParseDisplayName(L"\"E:\\1 \\\"",nullptr);

并提供UNC路径:

SHParseDisplayName(L"\\\\?\\E:\\1 \\",nullptr);

两者均产生E_INVALIDARG

值得注意的是:SHParseDisplayName对于嵌套在该文件夹中的项目确实可以正常工作,例如。 G。 L"E:\\1 \\some_internal_folder\\",而不是名称本身以空格结尾的文件夹。

有什么解决方法吗? Windows资源管理器似乎可以很好地使用此类文件夹(就像人们期望的那样)。

此外,SHParseDisplayName并不是唯一对此类文件夹失败的Windows API函数。相同行为的另一个示例是ILCreateFromPathW

huli234 回答:当传递名称以空格字符结尾的现有目录时,SHParseDisplayName失败,并显示ERROR_FILE_NOT_FOUND

  

以ASCII空格(0x20)开头或结尾的文件和文件夹名称   将被保存而没有这些字符。结尾的文件和文件夹名称   带有ASCII句点(0x2E)字符的字符也将被保存   字符。所有其他尾随或前导空格字符均为   保留。

     

Win32 API(CreateFile,FindFirstFile等)使用直接方法   枚举本地或远程文件系统上的文件和文件夹。   所有文件和文件夹均可被发现,无论是否包含或   空格字符的位置。

请参阅“ Support for Whitespace characters in File and Folder names

还有博客“ MS-DOS also allowed spaces in file names,although vanishingly few programs knew how to access them

因此,对于名称末尾带有空格的现有文件/文件夹,请使用Win32 API(CreateFile,FindFirstFile等),或将其替换为新名称而不会在末尾添加空格。

本文链接:https://www.f2er.com/3145488.html

大家都在问