我似乎无法在MSDN中找到答案。我很好奇，如果我有这样的事情：
LPITEMIDLIST pidl = NULL;
HRESULT hr = SHParseDisplayName(L"\\\\?\\C:\\Users\\Name\\Folder", NULL, &pidl, 0, NULL);
它失败，HRESULT设置为E_INVALIDARG。如果我将路径提供为"C:\\Users\\Name\\Folder"，则该问题就会消失，该路径仅限于MAX_PATH个字符。
那些Shell API是否与长Unicode路径不兼容？
答案 0 :(得分：7)
通常不，它不受支持。 \\?\是较低级别文件I / O API的一项功能，而不是较高级别的Shell API。 \\?\不代表Shell命名空间。
更新：对于将长文件路径解析为PIDL的问题，您可能需要手动将路径字符串分成单独的部分，并直接使用IShellFolder将每个部分解析为父/子PIDL根据需要递归递归。如果没有别的，这将帮助您确定哪个子文件夹中断了解析，然后您可以向用户报告：＆＃34;抱歉，达到Windows路径长度限制，无法使用路径XXX＆＃34;下面的文件/文件夹。 / p>
答案 1 :(得分：2)
不，Shell API函数（通常）与长Unicode路径不兼容。
E.g。在SHParseDisplayName的反函数的文档中，即SHGetPathFromIDList，您可以找到
pszPath [out]
输入：LPTSTR
用于接收文件系统路径的缓冲区的地址。此缓冲区的大小必须至少为MAX_PATH个字符。
一般来说，文档记录了每个相关函数的路径长度限制，但是AFAICS并不是更高级别的总体一般性声明。
从开发的角度来看，创建＆gt; MAX_PATH路径是合理的，例如涉及保留名称的路径，如CON，如果它们不会由普通的最终用户处理，因为Windows资源管理器拒绝处理它们。
（我刚才检查过.Windows 8.1 Explorer无声地拒绝删除名为con的文件夹。我认为应该这样做，因为普通的最终用户会发现很难删除它。）
高级用户可以解决shell的路径长度限制，以便例如通过利用命令解释器中的一些错误，使用subst驱动器，使用DOS短名称，编写调用API函数的程序以及可能的其他技术（希望不通过磁盘编辑）来删除或重命名。但对于普通终端用户来说，这种技术还不得而知。因此，当普通最终用户获得一些不受欢迎的＆gt; MAX_PATH路径时，该用户就会陷入困境。