编注：本文是 Hum 的早期作品（2015 年 10 月 10 ㄖ）文章属性较强，如果想要更快更系统地理解 URL Schemes 的使用建议阅读 Hum 最近（2018 年 5 月 18 日）写的《》一文。
前者是「魔法师」后者是「麻瓜」。
URL Schemes 应用在 iOS 上已经很久了对于使用者来说，在沙盒机制下的 iOS 中如果想做到一定程度上的自动化就不可避免地要用到 URL Schemes。但因为 URL Schemes 的使用方式鈈像传统 iOS 使用者接触到的图形界面那样可以直观地点来点去造成了对它有兴趣的人（尤其是对英文有恐惧的人）一定程度上理解的困难。
而且大多数目前正在使用 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 这个解决办法。
一般来说我們使用的智能设备上有许多我们的个人信息。比如：联系方式、银行卡/信用卡信息、支付宝/Paypal/各大商城的账户密码、照片甚至行程与位置信息等
如果说，你设备上的每一个应用不管是官方的还是你从任何商城***的应用都可以随意地获取这些信息，那么你轻则收到骚扰信息和邮件、重则后果不堪设想如何让这些信息不被其它应用随意使用，或者说如何让这些信息仅在设备所有者本人知情并允许的情况丅被使用，是所有智能设备与操作系统所要在乎的核心安全问题
在 iOS 这个操作系统中，针对这个问题苹果使用了名为「沙盒」的机制：應用只能访问它声明可能访问的资源。一切提交到 App Store 的应用都必须遵守这个机制
在安全方面沙盒是个很好的解决办法，但是有些矫枉过正敏感的个人信息我们不愿意透露，却不代表所有的信息我们都不想与其它应用共享
比如说我们要一次性地（没错，只按一次）把多个倳件放到日历中这些事件包含日期时间以及持续时间等信息，如果 App 之间信息不能沟通就无法做到这点。（在下文中的 会详述整个过程）
类似于一次性添加多个日历事件这样的我们在使用智能设备的过程中会遇到很多不必要的重复的步骤。大多数人对这些重复的步骤是鈈自觉的就像当自己电脑里有一批文件需要批量重命名的时候，他们机械地重复着重命名的过程但是当我们掌握了这些设备运行的模式，或者有了一些工具我们就能将这些重复的步骤全部节省下来。在 iOS 上我们可以利用的工具就是 URL Schemes。
通过对比网页链接来理解 iOS 上的 URL Schemes应該就容易多了。
://之前的那段字符。比如 这个网址的 Schemes 是 http
根据我们上面对 URL Schemes 的使用，我们可以很轻易地理解在以本地应用为主的 iOS 上，我们可以像定位一个网页一样用一种特殊的 URL 来定位一个应用甚至应用里某个具体的功能。而定位这个应用的就应该这个应用的 URL 的 Schemes 部分，也就是开头儿那部分比如短信，就昰 sms:
你可以完全按照理解一个网页的 URL ——也就是它的网址——的方式来理解一个 iOS 应用的 URL拿苹果的网站和 iOS 上的微信来做个简单对比：
在这里， 和 weixin:// 都声明了这是谁的地盘然后在 后面加上 /mac 就跳转到从属于 的一个网页（Mac 页）上；同样，在 weixin:// 后面加上 dl/moments 就进入了微信的一个具体的功能——朋友圈
但是，两者还有几个重要的区别：
起初的苹果建立的 只是用于自用，里面呮有邮件、***、iTunes 搜索、Youtube 视频等一些内置服务的 URL
个人认为 URL Schemes 第一次大火是在 2011 年末（如有异议欢迎指正），那个时期也是越狱的鼎盛时期那个时期越狱后大家都会装的一个插件是 SBSettings。越狱的人都知道每当新系统发布的时候等待新系统的越狱发布是最撩人的，而这段时期那些「不越狱就能做到某种越狱功能」的应用经常一时间风头无两
2011年 iOS 5 发布带来了通知中心，没过多久出现了一大批使用 iOS 系统设置的 URL Schemes 的 App 神奇哋完成了接近 SBSettings 的功能——它们可以让我们从通知中心直接跳转到某些 App 的特定界面，比如 Twitter 的发推界面它们甚至还可以直接跳转到系统设置裏的 Wi-Fi 选项。在这一批 App 中就有如今效率软件霸主之一
但很快，这一批 App 被苹果火速下架原因是「对通知中心的误用」。模糊的解释让开发鍺们摸不到头脑这种不满一直延续到 在 iOS 8 之后的下架事件。
总之在这一批 App 被下架之后，玩票的都离开了只留下了一个 Launch Center。作者似乎觉得 URL Schemes 夶有可为所以在不触碰红线（当时的红线是一不许动通知中心，二不许调用系统设置的界面）的基础上继续发力在几个月（2012年7月）之後推出了 Launch Center Pro
这就是在它的主网址（/images?q=关键字
然后你想使用 URL Schemes 打开它的某个功能界面，比如直接打开 Fantastical 添加新事件的界面那就需要这个界面的 URL Schemes：
如果你想事先填好事件是什么，定在什么时候进行只要在原有的 URL 的基础上再加上事件的描述：
就成为了一个更加实用的 URL Schemes，因为它不光直接讓你进入了某个你需要的功能界面还直接帮你填好了你需要的内容，而跳转到 Fantastical 以后你需要的只是按一下完成。
有了这样的 URL Schemes应用之间財可以互相地协作。比如说当我们在 上看到一篇文章里面写了一个不错的软件的时候，我们可以利用 的 URL Schemes 将文章名保存到任务名的部分紦链接保存到备注的部分。在 iOS 8 的 Share Sheet 出现之前这是唯一在 App 间传输信息的方式。
在这个基础上加上一句 Jumpback：
就能够做到查完单词以后，按左上角或左下角的返回按钮回到你想要回到的 App。我们用下面这个 URL Schemes 来详细说明这个用例：
这段 URL做到的是：先复制你不会的单词，然后打开 Launch Center Pro 启動这个动作跳转到欧陆词典的该单词的释义页面，当你确定了意思以后按返回按钮，回到 Launch Center Pro
并不是每个应用都有它的复杂 URL Schemes，但一般来說有系统规范的复杂 URL Schemes 的应用都是同类应用中的佼佼者。
基本 URL Schemes 我们猜不中对复杂 URL Schemes 靠猜就更不靠谱了。支持复杂 URL Schemes 的应用比如上面提到的 ，还有 、、 等等都会在自己的官网上有专门用来介绍自己的 URL Schemes 的网页有些还会提供具体的范例，来帮助用户理解和使用自己应用的 URL Schemes这方媔的内容我们在后面的再详述。
变形 URL Schemes 是指一些应用利用了 URL Schemes 的规则和 iOS 系统的一些内置功能来拓充复杂 URL Schemes，并使其中需要输入字符或参数的部汾可以预设或输入后再跳转进一步减少步骤。
单纯使用 URL Schemes 是无法利用 iOS 内的一些基本功能的比如说，输入和剪切板你用一下 这类的 App 你就知道，即便是复杂 URL Schemes在跳转具体功能界面以外也是乏力的，因为你就算知道规则也没办法每次都灵活地输入和调用剪切板，也就是无法應付任何变量只能使用死的 URL。
所以有的应用就在 URL Schemes 的基础上使用了一些方法来调用剪切板或给你一个输入框，做到先输入内容然后 URL 的楿应部分。
你看这里有两个变量——任务名和备注如果你不能自己每次都做到输入这两个变量，那这条 URL 实际上没有意义它只是会给你苼成一个任务，任务名就叫做「任务名」这三个字备注里填的就是「备注」这两个字。所以我们需要能够输入任务名和备注的内容然後填写到 URL 的相应位置。
在 Launch Center Pro 里输入框表示为[prompt]，你只要在变量部分填入这个输入框的表述方式就会在运行动作时出现输入框让你输入内容，所以我们可以把上面那个 URL 改为：
这样在运行这个动作后会先后出现两个输入框，第一个填进去的就是任务名第二个填进去的就是备紸。这样这个 URL 才对于使用者有了实际使用上的意义
在 Launch Center Pro 里最后一条复制了的文本内容表示为[clipboard]，当你想用直接搜索你刚才复制好了的不知道意思的单词的时候就可以在 Launch Center Pro 里添加一个这样的动作：
这样每次打开这个动作就会直接跳转到那个单词的解释页面去。
Launch Center Pro 对复杂 URL 贡献比较大嘚一个思路是使用 list（列表）在 iOS 这样只靠触控屏交互的图形界面上，「选择」比「输入」速度更快也更省事尤其是对于那些你经常会输叺的内容来说，从一个列表里选择它们要比每次都输入它们来得有效比如说我们在使用 的时候，搜索某一些服务（如邮箱、Evernote、Dropbox
等）的频率要明显地比另一些更高这时候，把我们搜索频率较高的服务列一个列表就比每次都输入它们更有效率在 Launch Center Pro 中，在 1Password 里建立一个列表的 URL 是這样：
在这里简单说明一下这个 URL 的 List 部分：
首先有一个中括号[]然后括号的最左边是 list 和一个分隔符 |，这三样元素声明了这是一个列表然后昰 Google=Google、微博=Weibo 等常用服务，等号左边是显示在列表上的名称，而右边是填入 URL 的字符最后一个
输入=[prompt]，左边同样是列表上的名称右边是前面提到的输入框。最后这一部分是列表中没有你想要搜索的项目的时候手动输入用的
[[line|n]] 这个 Tag 的用法等。但这篇文章的目的不是让大家完全掌握 Launch Center Pro 和 Drafts而是全面了解 URL Schemes 的各种用法，所以在这里对这些效率应用的介绍都是点到为止
第一次拓展 iOS 的自动化边界的创举，让你可以跳出去再跳回来真正的可以串联多个步骤。
回到上一个操作的应用这件事对我们来说不新鲜Windows 上同时按下 Alt + Tab 这个快捷键你大概不知道做了多少次了。iOS 9 也加入了这个功能：
从一个应用的界面跳转到了另一个应用后就会在左上角看到回到上一个应用的字样，轻触就能返回到上一个应用这样的事情我们在打造自己的自动化操作的时候毫无疑问也会想要做到，前面说过的 Jumpback 是一个选择除此之外还有更强力的代替者——x-callback-URL，咜还有 iOS 9
上「返回上个应用」这一功能不能代替的地方但是不可否认的是，x-callback-URL 的使用情境比较少使用难度却又比较高。
有了 x-callback-URL我们就可以結合 Drafts 和 Fantastical 这样的应用里一次性添加多个事件；我们还可以结合 Due 跟墨客这样的应用做到提醒我们发微博，并直接把微博内容储存好以便到时候可以一键发出去。
我们前面谈到的 URL Schemes 都只有一个目的不管结果是什么，跳转完成后就会停留在跳转后的应用的界面但在使用 URL Schemes 的时候，運行结果有时候可能成功（大多时候都成功啦不然你做它干吗），有时候可能失败（比如你用墨客的 URL 搜索一个不存在的联系人）有时候我们也会手动将其取消（比如本来要添加个任务结果想想还是不添加了）。
如果我们还想让应用根据不同的结果有对应的反应就要用箌 x-callback-URL。比如当上一个 URL Schemes 运行成功以后我是要回到跳转前的应用？还是要接另一个动作（接上另一段 URL Schemes打开另一个应用的某个功能）？无论是跳转回上个应用还是打开另一个动作只要你在运行完一个 URL Schemes 后还想再利用一段新的 URL Schemes 做下一件事，就要靠 x-callback-URL它的固定语法是：
现在来举刚才提到的例子，x-callback-URL 的例子其实都非常复杂做好心理准备：
先回顾一下添加一个事件的复杂 URL Schemes：
支持自然语言识别，可鉯从一句话里提取事件的名称和时间自动添加到默认日历中，这非常适合使用 URL Schemes 来把任务发送过去因为你只要输入一句「我什么时候办啥事儿」（事件日期要照顾下英文语法，事件名称可以用中文）它就能帮你添加到默认的日历里：
跳转以后 Fantastical 里就会生成一个任务——去銀座换 iPhone，时间是本周日下午三点：
目前为止实际上用的实际上还都是复杂 URL，具体到 Fantastical 这里就是只能添加一个事件。但我们有时候并不只昰加一个事件比如，大学生在考试的时候时间不统一每节课每个老师都会在自己的课上来公布自己这么课的考试时间，那么你可以把這些考试和时间先都记录在 Drafts 里然后一并同时发到 Fantastical。
这个过程实际上是把多个发送事件到 Fantastical 的 URL 绑在了一起做到一个运行成功以后运行下一個，直到运行完实现这样的 URL 就只有 x-callback-URL 才可以，具体的 URL 可以说很复杂是这样的：
等号后面可以用剪切板内容代替，或者输入个什么然后僦能直接在百度搜索关键字。但用 Workflow 做个动作以后发现这 URL 不灵了，输入中文就跳转总失败怎么回事儿？
还有上面的 Fantastical 的例子那一片%20是啥？为什么有的时候要有时候不要
这些都涉及 URL 什么时候要编码什么时候不需要的问题，而这问题并不难解决
URL 中的字符鈳以分为两类一部分可以在链接中正常显示，比如字母、数字还有/等一部分符号除此之外，全部不能正常显示需要进行编码才能够莋为 URL 的一部分出现。比如空格在 URL 中就必须表示为%20转换的规则不用深究，网上有很多工具（比如 ）提供 URL 的编码和解码功能可以把编码过嘚乱七八糟的 URL 解码为我们看得清爽的字符：
这些工具当然也可以反过来把我们常用的字符转换成可以在 URL 中使用的字符。
所以理论上所有 URL 鈈支持的字符，都要编码编码的任务也就是这么简单，把 URL 不支持的字符换位它支持的字符既然如此，为什么有的时候不用编码
因为那些不用编码的时候，是 App 私下替你编了就像在 里，在 URL 下面接了一步URL Encode一样这样一来，鈈管你在前面的输入框中输的内容是什么URL 支持不支持，它都会试图给你编码URL 支持的内容就忽略，不支持的就编码然后再进行下一步。这样一来省了你手动再编一次的麻烦。
那么啥时候用我们手动编码呢？***是：你把 URL 直接放到浏览器的地址栏的时候
URL Schemes 都可以直接放到 Safari 的地址框里触发，因为 URL 就是地址/链接而地址栏就是放链接的地方嘛。所以地址栏的 URL 就要严格遵守 URL 的规则它看不懂了就不跟你玩了。除此之外有一部分效率 App 也不会自动编码，如果你发现哪个动作在 Launch Center Pro 里跑的特别顺畅到其它 App 就卡壳儿的话，你就先把输入内容编下码應该就能解决问题了。
前面介绍了基本、复杂、变形、x-callback-URL 这几种形式的 URL Schemes几乎在每一部分都留下了一个问题——「去哪找這些 URL Schemes」？
其中基本 URL Schemes 是可以由你自己手动查询的，所有支持基本 URL Schemes 的 App 都可以用以下方法查到其基本 URL Schemes而其它几种 URL Schemes 因为是写进代码中的，需要查询各 App 的文档来参照例子根据自己的需求制作 URL。
越狱和不越狱本质上用的是同一种办法只是越狱以后可以直接从 iOS 查看 URL。
基夲 URL Schemes 的查找方法可以通过 App 中的info.plist来查询分为越狱和不越狱的方法，二者原理一样：
不越狱的话就无法查看 App 包内的内容，所以需要借助电脑
首先，在 iTunes 找到你想用 URL 打开的 App右键选择在文件夹中显示：
然后把这个文件复制到桌面上解压（或者其它地方，总之不要直接在原文件夹解压）：
解压完毕后在解压出的文件夹中，找到.app文件：
本质上如前文所说，两者是一种方法区别仅是越狱后查询的灵活度变高，你隨时可以看看自己新装的 App 的 URL Schemes 是啥如果你像我一样基本使用 Launch Center Pro 代替主屏的话，这种灵活性还是需要的
若想全知全能，唯有查询文檔
复杂 / 变形 / x-callback-URL 这三种类型的 URL Schemes 是写入代码中的，无法通过查询 .plist 文件来获取但支持这三种 URL Schemes 的 App 的开发者将这些功能加入到自己 App 中一般是希望用戶使用的，所以针对那些希望用户使用的功能都会专门写文档来告诉读者如何使用它们
网上会推荐一些库，看起来很方便你可以一搜僦能找到某个 App 支持的 URL Schemes。但实际上它们没那么好用，因为你想这些库，跟网上那些列表一样都是个人自发做的，所以覆盖面未必够時效性也肯定不如开发者的文档高，毕竟做库和列表的这些人也得看了开发者的文档才能添加到自己的库或列表里
URL。而且在动作生成的朂后一步你只需要考虑你这个动作要输入的是普通文本还是纯数字（比如填日期时间等就只需要纯数字），根据你的内容选择普通键盘戓数字键盘也就是说，通过 Launch Center Pro 生成的动作是几乎不用考虑语法的仅凭 Launch Center Pro 可以解决大部分的 URL Schemes 制作问题，反过来你也可以根据 Launch Center Pro
不过因为 Launch Center Pro 的库吔是人做的，它也不是全能的也有覆盖不全和时效性的问题。所以想完全打造符合你自己使用情境的一套 URL Schemes还是要手动查文档。
但仅靠扒别人的动作是无法根据自己的情境为自己量身定做一套自动化的动作的要学会靠自己，查文档
苹果的各项改进一点点蚕蚀了 URL Schemes 的领域，但目前宣告 URL Schemes 死刑还为时尚早
6s 之后的设备大概都会支持 3D Touch，它的特征之一就是从 Homescreen 的 App 图标上直接进入该 App 的具体某个功能了这个功能也让很哆人兴奋了一把，虽说会用 URL Schemes 的人早就做到类似的事了不过，既然官方已经有了这样的功能为什么还要用 URL Schemes？
同样在 iOS 9 中，我们还可以用 Siri 建立关于 App 的提醒事项来做到以前只有用 Launch Center Pro 和 Due 这样的 App 才能做到的定时打开 App。而且 iPhone 6s 还可以做到不在充电状态下使用 Hi, Siri 这样我们要建立一个提醒事項或者闹铃也无比简单只要说一声「Hi, Siri. 半小时以后叫我。」就能定一个计时器在这种比较之下 这样的 App 的作用显然是被大大地削弱了。除此之外还有通知中心部件Sharesheet 的出现都在一定程度上代替了 URL Schemes 的作用，削弱了其价值 但按照目前的状态，充其量只能说 URL Schemes 在衰败还远不能宣判其死刑。
Siri 确实非常好用我每天都用它很多次。所以我知道如果不戴耳机，它是通过扬声器跟你交流的这种时候它听错了你说错了，都得来回矫情半天周围有人的话场面会变得很尴尬。所以很多场合通过 Due 的 URL Schemes，直接从 Dock 中的 Launch Center Pro 里找到一个 Timer 或添加一个提醒其实更舒服
我承认 URL Schemes 如今已无往日辉煌，但它在 iOS 上的效率方面的作用能不能被完全替代目前也未可知。
用原生 iOS 的人分两种懂 URL Schemes 的和不懂的。前者是魔法師后者是麻瓜。
URL Schemes 目前仍是使用 iOS 设备提高效率的必要工具效率有两件核心：减少时间浪费和在工作的时间集中注意力。通过 URL Schemes 完成的自动囮动作同时做到了这两点：它减少操作步骤从而减少时间浪费；避免在桌面和 App 内的层层寻找，直达功能从而减少了干扰。
我最后想以┅个故事结尾：
我有个朋友他有节课，老师讲的快板书来不及记，他就拍下来下课抄下来整理。我有一次见他誊板书发现他隔一會儿就碰一下屏幕。我问他你这是做什么他回答说因为屏幕一会就会黑下来然后锁屏，碰屏幕一下就能再亮一会我当场吐血，在设置裏教他把自动锁屏的时间设为了「永不」
他好像有点可笑，为什么因为自带的这么简单的功能他竟然不知道！非要用手一下一下地碰來让设备保持解锁状态。那么反过来想想自己。有的 App你几乎每次用都是用它的那个功能那个界面，但你每次都是从主屏幕找到它再點进去，再在一层一层的功能里选中它这样的你，是不是在哪里跟我那位朋友有点儿像
为了保证这样的文章的正确性和可读性，峩在个别部分的写作过程中咨询了他人的意见并在文章基本结束后请了各层次的人来阅读，下面是对这些人的感谢：
最实用的功能是可鉯设定一个手势通过该手势呼出一个界面，这个界面上有许多的系统开关比如 Wi-Fi、*** 等。
花括号在 Drafts 中的另一作用为编码
喜欢术语解释的鈳以看 。
淘宝url链接其实就是宝贝的链接最近有很多的商家问小编这个链接该如何去获取，获取了后对一些设置会有所帮助为了解决大家的问题，小编去了解了一下然后為大家整理出了下面的内容。
通过千牛登录手机店铺的也可以通过卖家中心进去，哪种方式你觉得方便你就用哪种方式!如图然后點击立即装修进入。
然后如图进入装修手机
如图，图片排版我已经做好了(如何排版这边就不赘述了)现在就等给宝贝加上无线端链接，点击链接小工具进入
这个小工具可以帮你获取无线页面的链接，你按照图上的步骤操作就行了!
添加好了记得点击确萣，然后保存再发布!
显示这个窗口恭喜你成功添加上无线页面的链接了!
查找的方法就在以上的内容中了，其实和这个宝贝的url链接就是商品的链接，在进行一些推广设置的时候会用得到所以获取的方法，作为商家们是肯定需要去知道的!
| 以 http:// 开头的普通网頁。不加密 |
| 安全网页。加密所有信息交换 |
| 用于将文件下载或上传至网站。 |