URL Schemes 是个可以称得上「古老」的自动化方式了，它从 11 年末就迎来了它的第一次高峰1 ，四舍五入，我们已经用了它快 10 年了。但是一直以来，没有人尝试过系统地把 URL Schemes 的使用方式讲明白，这让 URL Schemes 变成了「麻瓜」和「魔法师」的分界线，也让我们这些非程序员但对自动化感兴趣的普通用户感到无从下手。
第一篇文章为理解 URL Schemes 确立框架
于是，在 2015 年 10 月 10 日，当时自以为把 URL Schemes 研究得比较透彻的我，写了一篇《URL Schemes 使用详解》。在这篇文章里，我根据自己的理解，把 URL Schemes 分为了以下 4 种类型：
- 基本 URL Schemes：用于启动应用的 URL，例
alipay:。 - 复杂 URL Schemes：用于启动应用特殊界面的 URL，例
alipayqr://platformapi/startapp?saId=10000007（支付宝扫码）。 - 变形 URL Schemes：Launch Center Pro、Drafts 等第三方应用各自对 URL 的特殊改造，例：Launch Center Pro 中的列表或 Prompt 用法。
- x-callback-URL：用于跳回上一个应用或者跳向下个应用的 URL
这 4 种类型为理解 URL Schemes 建立了一个框架。在当时，只要是 URL Schemes，都在这个框架之内。
这是我自己理解事情的方式，我讨厌盲人摸象，讨厌摸着石头过河。所以在详细理解一个事情之前，我会为其建立一张「地图」，这样我就能在涉及到一个知识点的时候，知道它在这张地图上属于什么位置，和它关联的东西是什么。这样更容易把琐碎的知识点，看似无关联的知识点联结起来。有助于理解，也有助于记忆。
也就是说，这篇文章在我看来，最主要的任务就是完成了理解 URL Schemes 的框架。为了让文章更好读，也因为我素来的「结案」野心，我把 URL Schemes 的前因后果，发展、编码问题以及查询方法也都写在了这篇文章里。如果认真读过这篇文章，关于 URL Schemes 就不会问出不该问的问题。
所谓不该问的问题，并不是指小白问的问题。其实小白问问题并不可恶，我在文章里和播客里都表示过，一个领域的高手会忘记他学习时碰过的壁，而半吊子会不懂装懂，只有新人经常会问出很本质的问题。
那么什么叫不该问的问题？不该问的问题，可以体现出提问者根本没有为解决这个问题付出任何一点努力——他没有调查，也没有尝试，甚至搜都没搜过。如果一个人自己都不愿意为自己的问题付出努力，就失去了要求别人为其努力的资格。
所以要熟悉和入门 URL Schemes，《URL Schemes 使用详解》这篇文章还是有必要粗读一下。大概了解 URL Schemes 的框架和它的由来，这样就能明白它的限制。关于 URL Schemes 的不该问的问题，就是提出一些根本不在 URL Schemes 能力范围内的需求。
第二篇文章真正掌握 URL Schemes 的用法
在写《URL Schemes 使用详解》 时，iOS 还算是个年轻的系统，热衷 iOS 自动化的人不多，喜欢写的就更少。于是《URL Schemes 使用详解》这篇文章发布之后产生了一定的影响，一些开发者在介绍 URL Schemes 时会直接放这篇文章，少数派后来谈到 URL Schemes 的文章大多会引用我这篇。
但是正如我所说，这篇文章的主要完成的事是确立一个框架，这就导致它其实在精细程度上是不够的，如果我们去看不同应用的 URL Schemes 文档，还是会云里雾里的。
还拿地图的例子来看的话，《URL Schemes 使用详解》这篇文章相当于开了全图，但是不能放大，一放大就糊了。为了活用 URL Schemes，我们最应该搞明白的是不同应用的 URL Schemes 文档，这些文档指导我们使用其 URL Schemes 地图。
对于开发者来说，看懂这些文档轻而易举。但对于普通用户来说，每个文档看起来都不一样，都很难理解。而这是因为，普通用户没有识破文档中的共通点，而开发者们因为长期的训练早已把握了这些共通点。
而这个关于 URL Schemes 文档的共通点，我写在了《入门 iOS 自动化：读懂 URL Schemes》这篇文章里。这个共通点非常简单，它就是把一段 URL Schemes 拆解开，把它以下分为 4 个部分：
- Scheme（链街头）：我们用来启动应用的就是这部分。
- Action（动作）：一般在斜线（/）后面，问号（？）前面。
- Parameter（参数）: 参数的特点是有必填有选填，一般在问号（？）后面，等号（=）前面。
- Value（值）：值是唯一有可能由使用者（我们）决定的内容，一般在等号（=）后面。
拿 things:///show?id=today 这段 URL 来说：
- Scheme 是
things: - Action 是
show - Parameter 是
id - Value 是
today
所有的 URL Schemes 都符合这个模式，掌握了这个阅读方法就能够读懂所有应用的 URL Schemes 文档，不管它们看起来多复杂。事实上 URL Schemes 的文档一般都是按照 Action、Parameter 的方式组织的。大家可以在看完《入门 iOS 自动化：读懂 URL Schemes》这篇文章后试着看看 Ulysses 的 URL Schemes 文档（如果你不用 Ulysses 的话看你用的应用的 URL Schemes 也可以）。让各位看 Ulysses 文档的原因是它的内容足够多，更能检测你是否理解了 URL Schemes 的组织方式，能不能透过一堆英文，看出 Action 和 Parameter 的结构。
什么时候看文档的时候能够下意识地去寻找「Action-Parameter」结构，就说明完全掌握了看 URL Schemes 的方法。
第三篇文章是 x-callback-URL 的用法
支持 x-callback-URL 的应用屈指可数，根据 x-callback-URL 官网的统计只有寥寥 69 个。作为理解 URL Schemes 的最后一张拼图，x-callback-URL 这张拼图不大，但是比较独特，在 iOS 有一些自动化必须借助它来完成。
我在《URL Schemes 使用详解》这篇文章里也大概讲了 x-callback-URL 应该如何理解。但是和这篇文章其它部分一样，它还是给了一个理解上的框架。所以在本周内容里的《x-callback-URL 的使用方法》这篇文章，我按照《入门 iOS 自动化：读懂 URL Schemes》这篇文章的形式，重新把 x-callback-URL 相关的东西更规范地梳理了一下。
x-callback-URL 的协议规定了使用 x-callback-URL 时要在结构上注意两点：
- 要在链接头后面带上
x-callback-URL的字样，比如drafts5://x-callback-url/create?text=你好 - 跳转时要使用
x-success、x-cancel等参数
但是，这两项中的第一项，有的应用遵守（比如 OmniFocus），有的应用不遵守（Things）。不管遵守不遵守，都不影响跳转功能，所以链接里加不加这个 x-callback-URL 不一定，要看应用的 URL Schemes 文档。
不过，这两项中的第二项，支持 x-callback-URL 的应用们都遵守了。也就是当我们完成一件事想要跳转到时候，肯定要用到 x-success。虽然 x-callback-URL 在设计时因为考虑周全，设计了 4 个参数：
- x-success
- x-cancel
- x-error
- x-source
但结果是实际上没有什么人用下面这 3 个，最后一个 x-source 连 x-callback-URL 的亲爹 Drafts 的开发者都已经不用了。所以我们只需要关注 x-success 即可。
了解了这两个方面，就掌握了 x-callback-URL 的元素在一段 URL 中的位置，而这就是真正理解了它应该怎么用的标志。
我对于各种 URL Schemes 库的看法
一直以来，大部分 URL Schemes 使用者热衷于囤积各种 URL Schemes，以及收集一些囤积了 URL Schemes 的库。我能够理解这种做法，但是并不赞成。原因主要有以下 3 个：
一、URL Schemes 库必然不全
URL Schemes 的库从原理上就不可能是全的，不光不可能覆盖所有应用，也不可能覆盖已有应用的所有用法。这是因为不存在官方 URL Schemes 这种东西。所有的 URL Schemes 库要么是库的维护者收集，要么是用户上传。不论哪种方法，都不可能覆盖到所有用法。而且这里所说的不能覆盖所有 URL Schemes 并不是指覆盖到了 90%、95% 哪种程度。在这种收集机制下的 URL Schemes 覆盖程度可以说低到了几乎不具备实用性的地步，因为每个人用手机的需求都有差异，甚至我们使用同一个应用需要的 URL Schemes 也不一样。一个人有找库的这个时间，不如花点时间看我前面提到的前两篇文章，看完这两篇文章绝对能够省下你找现成 URL Schemes 的时间。
二、URL Schemes 库必然滞后
一个新应用从发布它的 URL Schemes 文档，到它的 URL Schemes 被收录到某一个（你不知道是哪个的）URL Schemes 库，一定是有滞后时间的。如果你是这个应用的初级阶段的使用者，你不知道要等多久才能碰巧在你收藏夹里的那个 URL Schemes 库里查到这款应用的 URL Schemes。另外，有些应用的 URL Schemes 会随着应用更新而更新，更新过后的 URL Schemes 又不知道多久才会被更新到你收藏夹里的任意一个 URL Schemes 库里。
三、URL Schemes 库的模式悖论
这一点是根本原因。
我们已经知道，没有官方的 URL Schemes 库。所有的 URL Schemes 库，要么是独立维护，要么是用户上传。
独立维护的 URL Schemes 库，就免不了受个人需求的限制。他不用的，他就不会收录，特别是国外的库对国内需求最高的支付宝、淘宝、微信、网易云音乐等，连支持都不会支持。
用户上传的 URL Schemes 库，更是悖论。我们想一下，如果我自己会查 URL Schemes，我为什么还要把它上传到某个不是我控制的库里多此一举？所以真正会用 URL Schemes 库的，实际上都是伸手党，是去吸血的而不是去输血的。所以靠用户上传的 URL Schemes 库往往质量更差，基本上就是一些启动用的 URL Schemes，远不如个人维护的精致和深入。
正确使用 URL Schemes 库的姿势
当然，我也并不是完全抵制各式各样的库。这些库也有它们不可替代的价值。比如说有一些「黑 URL Schemes」，它们并没有被写成文档公布出来，而可能是产品经理或者开发者说漏嘴了而泄露出来的。像这样的 URL Schemes，无处可查，只能收集一个是一个。另外，有一些工具的 URL Schemes 的文档是写在它们 API 文档里的，而且写得很深很难找，这时候如果能直接搜到现成的用当然是更省时间。
所以对于这些库，我的态度是把它们当作一种补足措施。当我们通过查看文档无能为力之时，再去这些库里碰下运气。最初你看文档的速度也许不理想，但是熟悉之后，从文档里找出自己需要的 URL Schemes 写法也就是几分钟之内的事。
推荐一个查询 URL Schemes 的「库」
虽然前面表达了对这种 URL Schemes 库的不信任，但是在这些「不信任」里有一个库的质量却是我一直比较信任的，那就是 Launch Center Pro 的库。作为 2011 年将 URL Schemes 带火的工具，Launch Center Pro 不仅仅是最先发现 URL Schemes 价值的启动器，也一直内置了极丰富的 URL Schemes 库，这个库里内置了超过 10 万个支持 URL Schemes 的应用，而且一直在持续更新：
另外，Launch Center Pro 这个库好就好在，当我们选择其中一个应用之后，Launch Center Pro 会根据我们填写的内容将其制成可用的 URL Schemes，甚至直接解决编码问题。
现在 Launch Center Pro 已经改变了收费方式，由之前的买断改为了免费使用 + 订阅，而这个库的功能，它完全是免费的，非常划算。
小结
发布《x-callback-URL 的使用方法》这篇文章之后，我个人目前倾向于认为，面向普通用户的 URL Schemes 宏观指南这张地图已经比较完整了。
在去年的 Power+ 里还有一篇文章是《Universal Link 使用详解》，这是苹果提出的一项和 Universal Link 息息相关的新技术，它把服务的网址和应用关联了起来，大家可能体验过点网址却跳转到应用的情况，就是利用了这一特性。利用它可以做的自动化比较基础和简单，但却非常实用，比如我们想直接在知乎应用、豆瓣应用里搜个什么东西，就可以通过这个 Universal Link 来实现。还有很多 Web 套壳感很强，URL Schemes 查不到的工具，比如 Medium、Quora 这样的，它们都可以通过 Universal Link 来实现页面跳转。比如 Medium 的收藏夹是：https://medium.com/me/list/bookmarks，你点这个链接——如果你装了 Medium——它会直接在应用里给你打开收藏夹界面，尽管这条 URL 不是我们认识中的 URL Schemes。
不过因为那是一篇付费文章，所以还是不使劲儿给大家种草了。
除了这些比较宏观的指南之外，少数派以及去年的 Power+ 还有很多针对某个应用的具体的 URL 使用指南，比如我写过的《通过 Bear 来认识 Drafts 的 [[line]] 用法》、《通过 Bear 来认识 Launch Center Pro 的进阶用法》，还有《OmniFocus 的 URL Schemes 用法》等等。
但是这些实际上不是理解 URL Schemes 用法的主干，它们属于理解 URL Schemes 用法的碎片，在理解主干觉得有点抽象的时候可以辅助调剂。但我们最终的目的还是把握住干和核心。
因此如果想彻底搞明白 URL Schemes 的使用方法，我建议从这 3 篇开始：
- 1具体见《URL Schemes 使用详解》这篇文章中 「URL Schemes 的发展」部分：https://sspai.com/post/31500
