我正在为 Linux 上的 Google Chrome 创建一个自定义协议处理程序。我的链接如下所示：
<a href="myprotocol:someargument">Trigger my app with param</a>
我注意到如果 'myprotocol:' 未注册（我的应用程序未安装），Linux 上的 Google Chrome 会显示“外部协议请求”对话框并尝试使用 xdg-open：
而在其他操作系统上，例如 Windows 10 和 OS X El Capitan，如果协议未注册，则不会显示任何内容。
我还验证了 Firefox 在 Windows、OS X 和 Linux 上始终适用于未知协议 - 没有显示任何内容。
Linux 上的 Chrome 行为让用户非常困惑。
知道为什么 Linux 上的 Chrome（我在 Ubuntu 14.04 上测试）与任何其他操作系统和网络浏览器的行为不同吗？
问题在于，如果 Chrome 缺少本地协议处理程序，那么它想使用在用户环境中配置的处理程序。没有两个操作系统提供完全相同的 API 来启动默认处理程序。在实际启动它之前弄清楚这个程序会是什么，甚至在 Windows 或 Linux 上都不是一个清晰的 API。
“Mac”和 Windows 实现最终都知道哪个外部应用程序最终对协议负责，因此能够在不发出呼叫警告的情况下抑制未处理的呼叫。但 windows 实现实际上是一个依赖于 windows 注册表对 windows 上现有版本的观察的 kludge。这种类型的 API 违规在 Linux 上更加危险，在 Linux 上，许多风格的相关设置工具都有非常不同的分支。
实际上，Windows 和 OsX 没有发出它们没有调用任何警告的替代警告被认为是一个错误，因此如果您认为这是正确的行为，您可能需要在此处发表评论。
以下是我根据当前来源对这 3 个系统如何工作的观察：
在 Linux 中，当您向（窗口）系统注册协议处理程序时，您会执行以下操作：
xdg-settings set default-url-scheme-handler myprotocol evolution.desktop
现在，应用程序演化负责您的协议，任何东西都可以调用：
xdg-open myprotocol:...
现在在这些链接上打开进化。其他操作系统具有类似的机制，但可能没有外部程序作为调用存根。
这很好，很抽象，知道/说您正在调用的外部应用程序是 xdg-open可以防止 linux 实现中的很多复杂性。但这并不是用户可能想要的信息。获取该信息将需要使用xdg-settings，并且如果存在或曾经有一种方法可以有条件地覆盖该系统的某些风格中的默认处理程序，则存在不正确的风险。
在 Windows 处理程序中，显然您可以在注册表中四处窥探，然后对调用 api 的实际操作进行有根据的猜测。从技术上讲，chrome 必须这样做，因为它打开外部程序的方式是通过系统 API，所以没有像xdg-open警告中提到的外部存根。
在“mac”处理程序中，有一个适当的 API 来询问您的特定 URL 将启动的应用程序，因此 chrome会这样做，然后如果应用程序将空字符串命名为空字符串，它可以在生成警告之前完全放弃调用。