http://msdn.microsoft.com/en-us/library/ie/aa767914(v=vs.85).aspx
虽然我在HKEY_CLASSES_ROOT内部进行了初始设置,但新约束是在不需要管理员访问权限的情况下进行安装.因此,我删除了CLASSES_ROOT中的所有更改,并决定在HKEY_CURRENT_USER / Software / Classes / myapp中重试注册表添加,而不是使用HKEY_CURRENT_USER分支.
这似乎是由浏览器检测到的,并显示其确认对话框.但是,他们从未实际运行该应用程序. Internet Explorer提供了最有用的错误消息,对话框显示“无法为{uri}打开此帮助应用程序.此地址中指定的协议无效.请确保地址正确,然后重试.
我是否缺少非管理员设置的注册表部分？这是我的更改导出为.reg. (Dashes审查我的用户名).添加了EditFlags作为猜测,但没有它也没有用.
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Classes\myapp] "URL Protocol"="" @="URL:David Protocol" "EditFlags"=dword:02000000 [HKEY_CURRENT_USER\Software\Classes\myapp\DefaultIcon] @="C:\\Users\\------\\AppData\\Roaming\\-----s Stuffs\\URISchemeTest.exe,1" [HKEY_CURRENT_USER\Software\Classes\myapp\shell] [HKEY_CURRENT_USER\Software\Classes\myapp\shell\open] [HKEY_CURRENT_USER\Software\Classes\myapp\shell\open\command] @="\"C:\\Users\\-------\\AppData\\Roaming\\------s Stuffs\\URISchemeText.exe\" \"%1\""
解决方法
路径声明可能不支持％-sign目录访问器.如果是,则可能需要以某种方式编码.降低在问题中链接的文章中,它提到了Internet Explorer如何解码某些URL参数,但其他浏览器可能不会.无论哪种方式,如果您一直将命令行指定为“％APPDATA％/ MyProgram.exe”,从“C：/”开始可能更可靠,直到您可以解决该问题.
编辑：我刚注意到的另一件事,如果我的问题中的粘贴是正确的：我的工作版本的注册表更改将根的默认密钥设置为“URI：David Protocol”.注意“URI”,而不是“URL”.错误命名(很容易将其他值声明为“URL协议”)可能会破坏最终的效果.
虽然您可能不必指定DefaultIcon,但您可能需要注意不要指出无效的.为了安全起见,我将我设置为专门指向.ico文件,而不是“.exe,1”
正如其他一些评论者提到的那样,我认为EditFlags不是真的必要,也可能没有关系.
尽管如此,对这个高度投票的答案的警示性反驳是：作品.无需访问UAC.从我的研究开始,我个人会相信一个解释,如果没有UAC管理员提示等等,它太冒险了.但是,我花时间测试它,并且可以用一个设置自己的按钮编写一个简单的程序在HKCU / Software / Classes下,浏览器可以访问.然后我从一个从未参与我的任何研究(干净环境)的开发人员的计算机上测试它,并且没有任何管理员提示,它工作正常. (显然,此程序只能由当前用户访问)
(为便于阅读,提醒：HKCU = HKEY_CURRENT_USER.HKCR = HKEY_CLASSES_ROOT.HKLM = HKEY_LOCAL_MACHINE)
任何可以写入用户的HKCU注册表的内容都已经具有非管理二进制访问权限.此外,所有浏览器都会在打开程序之前显示有关启动程序的警告消息(完全可以理解,因为它是本地代码).其中一些甚至提供了您将要启动的可执行文件的完整文件夹路径.
我知道教程说把钥匙放在HKCR;而且这已知来自HKLM / Software.但是,值得一读的是这里的全部内容：
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).aspx
此密钥部分源自HKCU配置单元 – 事实上,用户的设置将覆盖本地计算机设置.没有具体说明HKLM会在HKCR内显示此类密钥时会覆盖HKCU.
