我正在为Linux上的Google Chrome创建自定义协议处理程序。我的链接如下所示：
<a href="myprotocol:someargument">Trigger my app with param</a>
我注意到，如果＆＃39; myprotocol：＆＃39;未注册（我的应用未安装），Linux上的Google Chrome显示＆＃34;外部协议请求＆＃34;对话框并尝试使用xdg-open：
https://s3.amazonaws.com/bucket
在其他操作系统上，例如Windows 10和OS X El Capitan，如果未注册协议，则不会显示任何内容。
我还验证了Firefox在Windows，OS X和Linux上一致地处理未知协议 - 没有显示任何内容。
Linux上的Chrome行为让用户感到非常困惑。
知道为什么Linux上的Chrome（我在Ubuntu 14.04上测试）与其他任何操作系统和网络浏览器的行为都不同？
答案 0 :(得分：5)
问题实际上是，如果Chrome缺少本地协议处理程序，那么它希望使用在用户环境中配置的处理程序。没有两个操作系统提供完全相同的API来启动默认处理程序。在实际启动它之前弄清楚这个程序是什么在Windows或Linux上都不是一个明确的API。
“Mac”和Windows实现最终都知道哪个外部应用程序最终负责协议，因此能够在不发出呼叫警告的情况下抑制未处理的呼叫。但Windows实现实际上是一个依赖于Windows上现有版本的Windows注册表观察的kludge。这种类型的API违规在Linux上更加危险，因为许多版本的相关设置工具都有很多不同的分支。
实际上considered a bug Windows和OsX不发出他们没有调用任何内容的备用警告，因此如果您认为这是正确的行为，您可能想在此处发表评论。
以下是我根据当前来源观察3个系统的工作原理：
在Linux中，当您使用（窗口）系统注册协议处理程序时，您可以执行以下操作：
xdg-settings set default-url-scheme-handler myprotocol evolution.desktop
现在，应用程序发展负责您的协议，任何事情都可以调用：
xdg-open myprotocol:...
现在开始在这些链接上进化。其他操作系统具有类似的机制，但可能没有外部程序作为调用存根。
这很好而且抽象，knowing/saying the external app you are calling is xdg-open可以防止Linux实现中的复杂化。但这并不完全是用户可能想要的信息。获取该信息需要使用xdg-settings代替，如果在某些风格的系统中有条件覆盖默认处理程序，则可能存在错误。
在Windows处理程序中，显然你可以去snooping around in the registry，然后做出有根据的猜测，猜测api实际上会做什么。从技术上讲，chrome必须这样做，因为它打开外部程序的方式是通过系统API，所以在警告中没有像xdg-open那样的外部存根。
在“mac”处理程序中，有一个适当的API可以询问您的特定网址将启动的应用，因此Chrome does，然后if the application name the empty string它可以在生成警告之前完全取消调用