ShellExecute 对于本地 html 或文件 URL 失败

我们公司正在将我们的帮助系统迁移到 Flare 下的 HTML5 格式。我们还在 URI 命令行上使用 Flare CSHID 添加了对帮助系统的基于主题的访问，以便直接访问主题，例如index.html#CSHID=GettingStarted启动GettingStarted.html帮助页面。

我们的应用程序是用 C++ 编写的，并利用 Win32ShellExecute()函数生成与 HTTP 关联的默认应用程序以显示帮助系统。我们注意到ShellExecute()当未指定主题标签时工作正常，例如

ShellExecute(NULL, _T("open"), _T("c:\\Help\\index.html"), NULL, NULL, SW_SHOWNORMAL);

此函数将启动与查看 HTML 页面相关的默认浏览器，在本例中，File:///协议处理程序将启动，浏览器将启动，您将看到file:///c:/Help/index.html在地址栏中。

但是，一旦添加#该主题的信息，ShellExecute()无法打开页面

ShellExecute(NULL,_T("open"),_T("c:\\Help\\index.html#cshid=GettingStarted"),NULL,NULL,SW_SHOWNORMAL);

如果浏览器完全打开，您将被定向到file:///c:/Help/index.htm我没有#cshid=GettingStarted主题识别。

请注意，只有当文件协议处理程序通过以下方式参与时，这才是问题ShellExecute()，如果帮助系统存在于网络上，并且使用了 Http 或 Https 协议处理程序，则一切都运行良好。

对于我们的客户（其中一些客户使用专用 LAN）来说，我们不能总是依赖 Internet 访问，因此我们的帮助系统必须随应用程序一起提供。

经过与 Microsoft 的 MSDN 团队反复讨论后，他们审查了 ShellExecute() 调用的源代码，并确定，是的，当在 ShellExecute() 中处理基于 File:/// 的 URL 时，ShellExecute() 调用将在启动默认浏览器并发送 HTML 页面以打开之前，删除 # 以及在 # 之后找到的任何数据。 MS 的立场是，他们故意这样做是为了防止注入到该函数中。

解决方案是通过在 URL 中搜索 # 来增强 ShellExecute() 调用，如果找到 #，那么我们将使用该 URL 手动启动默认浏览器。这是伪代码

void WebDrive_ShellExecute(LPCTSTR szURL)
{
    if ( _tcschr(szURL,_T('#')) )
    {
        //
        //Get Default Browser from Registry, then launch it.
        //
        ::RegGetStr(HKCR,_T("HTTP\\Shell\\Open\\Command"),szBrowser);
        ::CreateProcess ( NULL, szBrowser + _T(" ") + szURL, NULL, NULL, FALSE, 0, NULL, NULL, &sui, &pi);
    }
    else
        ShellExecute(NULL,_T("open"),szURL,NULL,NULL,SW_SHOWNORMAL);
}

当然，C++ 代码还有更多内容，但这种总体设计对我们来说很有效。