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 啊？」
• 「國內的 xx 軟件支持不支持 URL Schemes 啊？」

都能在文章中找到答案。

文章目錄（想看使用部分的可以直接跳轉到基本 URL ?Schemes）：

1. 簡介蘋果的沙盒機制
2. URL Schemes 是什麽
3. URL Schemes 的發展
4. 基本 URL Schemes
5. 復雜 URL Schemes
6. 變形 URL Schemes
7. x-callback-URL
8. URL En/Decode（編碼/解碼）
9. 如何查找以上各類 URL Schemes
10. URL Schemes 的衰敗
11. 結語

註：文中會提到使用 Launch Center Pro、Drafts 等應用的例子，它們都是同類應用中的最好選擇，而支持 URL Schemes 是促成它們如此地位的不可忽視的原因。如果想深入了解 URL Schemes，這些應用恐怕是必不可少的。你可以在 AppShopper 這樣的網站參考其以往價格，以便在你覺得價格合適的時候入手這些應用。

簡介蘋果的沙盒機制

蘋果選擇沙盒來保障用戶的隱私和安全，但沙盒也阻礙了應用間合理的信息共享，於是有了 URL Schemes 這個解決辦法。

一般來說，我們使用的智能設備上有許多我們的個人信息。比如：聯系方式、銀行卡/信用卡信息、支付寶/Paypal/各大商城的賬戶密碼、照片甚至行程與位置信息等。

如果說，你設備上的每一個應用，不管是官方的還是你從任何商城安裝的應用都可以隨意地獲取這些信息，那麽你輕則收到騷擾信息和郵件、重則後果不堪設想。如何讓這些信息不被其它應用隨意使用，或者說，如何讓這些信息僅在設備所有者本人知情並允許的情況下被使用，是所有智能設備與操作系統所要在乎的核心安全問題。

在 iOS 這個操作系統中，針對這個問題，蘋果使用了名為「沙盒」的機制：應用只能訪問它聲明可能訪問的資源。一切提交到 App Store 的應用都必須遵守這個機制。

在安全方面沙盒是個很好的解決辦法，但是有些矯枉過正。敏感的個人信息我們不願意透露，卻不代表所有的信息我們都不想與其它應用共享。

比如說我們要一次性地（沒錯，只按一次）把多個事件放到日歷中，這些事件包含日期時間以及持續時間等信息，如果 App 之間信息不能溝通，就無法做到這點。（在下文中的 x-callback-URL 的部分會詳述整個過程）

類似於一次性添加多個日歷事件這樣的，我們在使用智能設備的過程中會遇到很多不必要的重復的步驟。大多數人對這些重復的步驟是不自覺的，就像當自己電腦裏有一批文件需要批量重命名的時候，他們機械地重復著重命名的過程。但是當我們掌握了這些設備運行的模式，或者有了一些工具，我們就能將這些重復的步驟全部節省下來。在 iOS 上，我們可以利用的工具就是 URL Schemes。

URL Schemes 是什麽

通過對比網頁鏈接來理解 iOS 上的 URL Schemes，應該就容易多了。

URL Schemes 有兩個單詞：

• URL，我們都很清楚，http://www.apple.com 就是個 URL，我們也叫它鏈接或網址；
• Schemes，表示的是一個 URL 中的一個位置——最初始的位置，即 ://之前的那段字符。比如 http://www.apple.com 這個網址的 Schemes 是 http。

根據我們上面對 URL Schemes 的使用，我們可以很輕易地理解，在以本地應用為主的 iOS 上，我們可以像定位一個網頁一樣，用一種特殊的 URL 來定位一個應用甚至應用裏某個具體的功能。而定位這個應用的，就應該這個應用的 URL 的 Schemes 部分，也就是開頭兒那部分。比如短信，就是 sms:

你可以完全按照理解一個網頁的 URL ——也就是它的網址——的方式來理解一個 iOS 應用的 URL，拿蘋果的網站和 iOS 上的微信來做個簡單對比：

在這裏，http://www.apple.com 和 weixin:// 都聲明了這是誰的地盤。然後在 http://www.apple.com 後面加上 /mac 就跳轉到從屬於 http://www.apple.com 的一個網頁（Mac 頁）上；同樣，在 weixin:// 後面加上 dl/moments 就進入了微信的一個具體的功能——朋友圈。

但是，兩者還有幾個重要的區別：

1. 所有網頁都一定有網址，不管是首頁還是子頁。但未必所有的應用都有自己的 URL Schemes，更不是每個應用的每個功能都有相應的 URL Schemes。實際上，現狀是，大多數的應用只有用於打開應用的 URL Schemes，而有一些應用甚至沒有用於打開應用的 URL Schemes。幾乎沒有所有功能都有對應 URL 的應用。所以，不要說某某應用爛，不支持國內應用。一個 App 是否支持 URL Schemes 要看那個 App 的作者是否在自己的作品裏添加了 URL Schemes 相關的代碼。
2. 一個網址只對應一個網頁，但並非每個 URL Schemes 都只對應一款應用。這點是因為蘋果沒有對 URL Schemes 有不允許重復的硬性要求，所以曾經出現過有 App 使用支付寶的 URL Schemes 攔截支付帳號和密碼的事件。
3. 一般網頁的 URL 比較好預測，而 iOS 上的 URL Schemes 因為沒有統一標準，所以非常難猜，通過猜來獲取 iOS 應用的 URL Schemes 是不現實的。

URL Schemes 的發展

URL Schemes 的發展過程可以說就是 iOS 效率工具類 App 的發展過程。

起初的蘋果建立的 Apple URL Schemes 只是用於自用，裏面只有郵件、電話、iTunes 搜索、Youtube 視頻等一些內置服務的 URL。

個人認為 URL Schemes 第一次大火是在 2011 年末（如有異議歡迎指正），那個時期也是越獄的鼎盛時期，那個時期越獄後大家都會裝的一個插件是 SBSettings[1]。越獄的人都知道每當新系統發布的時候，等待新系統的越獄發布是最撩人的，而這段時期那些「不越獄就能做到某種越獄功能」的應用經常一時間風頭無兩。

2011年 iOS 5 發布帶來了通知中心，沒過多久，出現了一大批使用 iOS 系統設置的 URL Schemes 的 App 神奇地完成了接近 SBSettings 的功能——它們可以讓我們從通知中心直接跳轉到某些 App 的特定界面，比如 Twitter 的發推界面。它們甚至還可以直接跳轉到系統設置裏的 Wi-Fi 選項。在這一批 App 中，就有如今效率軟件霸主之一 Launch Center Pro 的前身——Launch Center。

但很快，這一批 App 被蘋果火速下架，原因是「對通知中心的誤用」。模糊的解釋讓開發者們摸不到頭腦，這種不滿一直延續到 Launcher 在 iOS 8 之後的下架事件。

總之，在這一批 App 被下架之後，玩票的都離開了，只留下了一個 Launch Center。作者似乎覺得 URL Schemes 大有可為，所以在不觸碰紅線（當時的紅線是一不許動通知中心，二不許調用系統設置的界面）的基礎上繼續發力，在幾個月（2012年7月）之後推出了 Launch Center Pro v1.0。

另一個註意到 iOS 上的 URL Schemes 的作用的是 Drafts 的作者 Greg Pierce。不同於 Launch Center Pro，Greg Pierce 打造的是一個以輸入文字為主的效率應用，它以一個筆記本的面目示人，所以被媒體稱為「Launch Center for text」。

兩者大的區別在於先選動作還是先輸入。Launch Center Pro 的使用方法是：先打開動作，如果需要輸入的話，你可以讓它跳出來一個輸入框，你來輸入，輸入完成後跳轉到相應應用。Drafts 則是先在筆記本裏把東西輸入了，然後再選擇動作，跳轉到相應應用。

好像沒什麽大不了的嘛……嗎？這裏至少有兩個重要的區別：

1. Drafts 中輸入過的內容會儲存在筆記本中以留作備份，而 Launch Center Pro 裏的則是動作運行完了就沒了。
2. Drafts 中輸入過的內容可以通過 URL Schemes 進行多次使用或一次性發給多個應用或服務，而 Launch Center Pro 只能將輸入內容發送到一個服務或應用。即除了剪切版外， Launch Center Pro 沒有其它變量的概念。
3. 第三個區別不太重要：Launch Center Pro 裏的輸入框和 Drafts 的筆記本界面來比較很明顯不是一個好的寫作環境。

細節上的區別還有很多，兩者適用的範圍隨著各自的發展擴大，因此重合的那部分功能也愈發的不起眼。Launch Center Pro 和 Drafts 從那以後成為效率類應用中的雙雄，不斷提出更多更靈活使用 iOS 上 URL Schemes 的辦法。

比如 Launch Center Pro 提出了 List 的概念，將列表的想法融入到了 URL Schemes 中，列表的每一項可以是簡單的字符，又可以是一串新的復雜的 URL。使用列表可以讓我們每次的輸入變為更輕松的選擇，對於那些重復的任務更為高效。

而 Drafts 的作者直接不滿 URL Schemes 只能跳出不能跳回的問題，和 Marco Arment、Justin Williams 等人開發了 x-callback-URL 來做到跳出，並跳回這樣的動作。

可以說這兩款 App 對 URL Schemes 的推廣和使用構思上的貢獻是最突出的，現在 URL Schemes 越來越被 iOS 用戶和開發者所重視，在我眼裏，一款 App 是否完整系統地支持 URL Schemes 已經是判斷它是否優秀的標誌之一。

故事講到這裏，更重要的還是如何使用 URL Schemes。

故事裏沒有提到 Pythonista、Editorial 跟 Workflow，絕不是我認為這些 App 不夠腕兒，而是它們做的事情重點已經不在於 URL Schemes 了。

基本 URL Schemes

基本 URL Schemes 的能力雖然簡單有限，但使用情境卻是最普遍的。

我所謂的基本 URL Schemes，是指一個 URL 的 Schemes 部分，比如上文提到的微信的 weixin:。這個部分的唯一功能，就是打開相應應用，而不能夠跳轉到任何功能。

絕大多數所謂支持 URL Schemes 的應用，一般都是只有這麽一個部分，它一般是這個應用的名稱，比如 OmniFocus 這款應用，它的基本 URL Schemes 就是 Omnifocus:。如果應用的主名稱是個中文名的話，它的 URL Schemes 也許會是應用名的拼音，比如 墨客 這款應用，它的基本 URL Schemes 是 moke:。

但，我前面提過了網頁 URL 和 iOS 應用的 URL 的三個重要區別，其中第三項，就是 iOS 上的 URL Schemes 並不規範，一個應用的 URL 可以是各種各樣的：

• Coursera 的 URL 是：coursera-mobile:
• Duet 這款遊戲的 URL 是：x-kumo-duet:
• Monument 這款遊戲的 URL 是：fb690517270143345:
• Feedly 的 URL 是：fb129765800430121:
• 扇貝新聞的 URL 是：wx95962d02b9c3e2f7:

它們目前並沒有統一的規則，所以猜測一個應用的意義並不太大，你可以試試，但不要過於指望這種方式。下文會提到如何查找一個應用的基本 URL Schemes，只要那個應用支持 URL Schemes 就能找到。

基本 URL Schemes 的能力雖然簡單有限，但使用情境卻是最普遍的。作為一個使用 Launch Center Pro 代替 Home Screen 的人，這樣只能做到打開應用的基本 URL Schemes 對我來說也是很重要的。

復雜 URL Schemes

掌握復雜 URL Schemes 你才算初步有了打造適應自己使用情境的自動化流程的能力。

iOS 應用的復雜 URL Schemes 就像網站的子頁面的鏈接一樣，在首頁網址的基礎上進行延伸。前面蘋果官網和微信對比的例子已經可以說明問題了，想不起來的可以再去回顧一下。

具體來看，復雜 URL Schemes 有兩種：一種是直接打開某個應用的某個功能，另一種是打開某個功能後直接填寫預設的字符。這同網頁網址的原理也是類似的：

比如 Google Image 搜索的網址是：

https://image.google.com

這就是在它的主網址（Google.com）的基礎上做了修改的子網頁的網址。而如果我們搜索一個詞條，網址實際上是：

http://images.google.com/images?q=關鍵字

iOS 上的 URL Schemes 同樣遵循這個規則，比如你要打開 Fantastical 這個應用，這是一個基本 URL Schemes：

Fantastical:

然後你想使用 URL Schemes 打開它的某個功能界面，比如直接打開 Fantastical 添加新事件的界面，那就需要這個界面的 URL Schemes：

fantastical2://parse?sentence

如果你想事先填好事件是什麽，定在什麽時候進行，只要在原有的 URL 的基礎上再加上事件的描述：

fantastical2://parse?sentence=事件描述

就成為了一個更加實用的 URL Schemes，因為它不光直接讓你進入了某個你需要的功能界面，還直接幫你填好了你需要的內容，而跳轉到 Fantastical 以後，你需要的只是按一下完成。

有了這樣的 URL Schemes，應用之間才可以互相地協作。比如說，當我們在 Mr. Reader 上看到一篇文章裏面寫了一個不錯的軟件的時候，我們可以利用 OmniFocus 的 URL Schemes 將文章名保存到任務名的部分，把鏈接保存到備註的部分。在 iOS 8 的 Share Sheet 出現之前，這是唯一在 App 間傳輸信息的方式。

復雜 URL Schemes 有一個特殊的用例是 Jumpback，字典類 App 用它的很多，比如歐路詞典。傳統的使用歐陸字典查詢單詞的 URL Schemes 是：

eudic://dict/想查的單詞

在這個基礎上，加上一句 Jumpback：

eudic://dict/想查的單詞?jumpback=指定URL

就能夠做到查完單詞以後，按左上角或左下角的返回按鈕，回到你想要回到的 App。我們用下面這個 URL Schemes 來詳細說明這個用例：

eudic://dict/[clipboard]?jumpback=launch:

這段 URL，做到的是：先復制你不會的單詞，然後打開 Launch Center Pro 啟動這個動作，跳轉到歐陸詞典的該單詞的釋義頁面，當你確定了意思以後，按返回按鈕，回到 Launch Center Pro。

並不是每個應用都有它的復雜 URL Schemes，但一般來說，有系統規範的復雜 URL Schemes 的應用都是同類應用中的佼佼者。

基本 URL Schemes 我們猜不中，對復雜 URL Schemes 靠猜就更不靠譜了。支持復雜 URL Schemes 的應用，比如上面提到的 OmniFocus，還有 Due、Clear、Launch Center Pro 等等都會在自己的官網上有專門用來介紹自己的 URL Schemes 的網頁，有些還會提供具體的範例，來幫助用戶理解和使用自己應用的 URL Schemes。這方面的內容我們在後面的查找部分再詳述。

變形 URL Schemes

在復雜 URL Schemes 的基礎上更上一層樓。

變形 URL Schemes 是指一些應用利用了 URL Schemes 的規則和 iOS 系統的一些內置功能，來拓充復雜 URL Schemes，並使其中需要輸入字符或參數的部分可以預設或輸入後再跳轉，進一步減少步驟。

單純使用 URL Schemes 是無法利用 iOS 內的一些基本功能的，比如說，輸入和剪切板，你用一下 iLauncher 這類的 App 你就知道，即便是復雜 URL Schemes，在跳轉具體功能界面以外也是乏力的，因為你就算知道規則，也沒辦法每次都靈活地輸入和調用剪切板，也就是無法應付任何變量，只能使用死的 URL。

所以有的應用就在 URL Schemes 的基礎上，使用了一些方法來調用剪切板或給你一個輸入框，做到先輸入內容，然後 URL 的相應部分。

我們這裏用 Launch Center Pro 來舉幾個簡單的例子：

比如用 OmniFocus 的添加任務的復雜 URL Schemes：

OmniFocus:///add?name=任務名&note=備註

你看這裏有兩個變量——任務名和備註。如果你不能自己每次都做到輸入這兩個變量，那這條 URL 實際上沒有意義，它只是會給你生成一個任務，任務名就叫做「任務名」這三個字，備註裏填的就是「備註」這兩個字。所以我們需要能夠輸入任務名和備註的內容，然後填寫到 URL 的相應位置。

在 Launch Center Pro 裏，輸入框表示為[prompt]，你只要在變量部分填入這個輸入框的表述方式，就會在運行動作時出現輸入框讓你輸入內容，所以我們可以把上面那個 URL 改為：

OmniFocus:///add?name=[prompt]&note=[prompt]

這樣在運行這個動作後，會先後出現兩個輸入框，第一個填進去的就是任務名，第二個填進去的就是備註。這樣這個 URL 才對於使用者有了實際使用上的意義。

在 Launch Center Pro 裏最後一條復制了的文本內容表示為[clipboard]，當你想用歐陸詞典直接搜索你剛才復制好了的不知道意思的單詞的時候，就可以在 Launch Center Pro 裏添加一個這樣的動作：

eudic://dict/[clipboard]

這樣每次打開這個動作就會直接跳轉到那個單詞的解釋頁面去。

Launch Center Pro 對復雜 URL 貢獻比較大的一個思路是使用 list（列表）。在 iOS 這樣只靠觸控屏交互的圖形界面上，「選擇」比「輸入」速度更快也更省事，尤其是對於那些你經常會輸入的內容來說，從一個列表裏選擇它們要比每次都輸入它們來得有效。比如說我們在使用 1Password 的時候，搜索某一些服務（如郵箱、Evernote、Dropbox 等）的頻率要明顯地比另一些更高，這時候，把我們搜索頻率較高的服務列一個列表就比每次都輸入它們更有效率，在 Launch Center Pro 中，在 1Password 裏建立一個列表的 URL 是這樣：

onepassword://search/[list|Google=Google|Dropbox=Dropbox|Weibo=Weibo|輸入=[prompt]]

在這裏簡單說明一下這個 URL 的 List 部分：

[list|Google=Google|Dropbox=Dropbox|微博=Weibo|輸入=[prompt]]

首先有一個中括號[]，然後括號的最左邊是 list 和一個分隔符 |，這三樣元素聲明了這是一個列表。然後是 Google=Google、微博=Weibo 等常用服務，等號左邊，是顯示在列表上的名稱，而右邊是填入 URL 的字符。最後一個 輸入=[prompt]，左邊同樣是列表上的名稱，右邊是前面提到的輸入框。最後這一部分是列表中沒有你想要搜索的項目的時候手動輸入用的。

Launch Center Pro 的用法還有很多，對變形 URL Schemes 也有其它的貢獻，包括文中提到的這些說明有些並不完整。除了 Launch Center Pro 以外，Drafts 等應用對變形 URL Schemes 也有自己的貢獻，比如把 Drafts 中的一篇筆記的某一行或幾行作為 URL 的元素安插在 URL 之中，也就是 [[line|n]] 這個 Tag 的用法等。但這篇文章的目的不是讓大家完全掌握 Launch Center Pro 和 Drafts，而是全面了解 URL Schemes 的各種用法，所以在這裏對這些效率應用的介紹都是點到為止。

x-callback-URL

第一次拓展 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，它的固定語法是：

• 在一個 URL Schemes 後面接&x-success，表示前一個 URL 成功以後下一步做什麽；
• 在一個 URL Schemes 後面接&x-error，表示前一個 URL 失敗以後下一步做什麽；
• 在一個 URL Schemes 後面接&x-cancel，表示取消前一個 URL 的操作結果後下一步做什麽；
• 還有一個 &x-source 我們遇到了再說。

現在來舉剛才提到的例子，x-callback-URL 的例子其實都非常復雜，做好心理準備：

用 Drafts 給 Fantastical 一次性添加多個事件

先回顧一下添加一個事件的復雜 URL Schemes：

Fantastical 支持自然語言識別，可以從一句話裏提取事件的名稱和時間，自動添加到默認日歷中，這非常適合使用 URL Schemes 來把任務發送過去，因為你只要輸入一句「我什麽時候辦啥事兒」（事件日期要照顧下英文語法，事件名稱可以用中文），它就能幫你添加到默認的日歷裏：

fantastical2://parse?sentence=去銀座換 iPhone on this sunday at 15

你可以把上一個 URL 通過 Launch Center Pro 激活，也可以把空格全都替換成%20以後直接填入 Safari 的地址欄：

fantastical2://parse?sentence=去銀座換%20iPhone%20on%20this%20sunday%20at%2015

跳轉以後 Fantastical 裏就會生成一個任務——去銀座換 iPhone，時間是本周日下午三點：

目前為止，實際上用的實際上還都是復雜 URL，具體到 Fantastical 這裏，就是只能添加一個事件。但我們有時候並不只是加一個事件。比如，大學生在考試的時候時間不統一，每節課每個老師都會在自己的課上來公布自己這麽課的考試時間，那麽你可以把這些考試和時間先都記錄在 Drafts 裏，然後一並同時發到 Fantastical。

這個過程實際上是把多個發送事件到 Fantastical 的 URL 綁在了一起，做到一個運行成功以後運行下一個，直到運行完，實現這樣的 URL 就只有 x-callback-URL 才可以，具體的 URL 可以說很復雜，是這樣的：

fantastical2://x-callback-url/parse?sentence=[[line|1]]&add=1&x-success={{drafts4://x-callback-url/runAction?text=[[line|2..]]&allowEmpty=NO&action=Events%20in%20Fantastical-Quick}}&x-cancel={{drafts4://}}

不要被嚇到，我們來逐條分析這段 URL 就能輕松讀懂它：

• fantastical2://x-callback-url/parse?sentence= 這一句，你會發現比我們剛才用的 fantastical2://parse?sentence= 多了一截兒 x-callback-url/，原因是，當一個 App 的 URL 裏使用了多出來的這一段兒 x-callback-url/，就是在聲明，「各單位註意，我下面的 URL 要用到 x-callback-URL 了。」
• 緊接著是 [[line|1]]，這一段是 Drafts 的變形 URL，意味取文本中第一行的值。在這個動作中，我們看上面的截圖，第一行是微積分考試那一條，那麽就是把微積分這條先發到 Fantastical 裏。

接下來我們要做的事是，把剩下幾行也自動發到 Fantastical，並且在沒有東西的時候自動停止動作。

• 所以我們接著來看下一個小部分add=1，這是 Fantastical 的語法，再加一項任務。
• 下一句的 &x-success= 就是 x-callback-URL 的標準聲明了，即當上一步成功後，下一步做什麽。

然後你會看到雙層花括號{{ }}的出現。在 x-callback-URL 中[2]，出現在 x-success 這些固定語法之後的雙層花括號意味著花括號之中應當是一個完整的動作，這個動作在上一個動作成功/取消/錯誤後進行。

在這裏你可以這樣理解：用雙層花括號將一段 URL 包起來放到另一段 URL 中是為了不打亂原有的運行順序。URL 的運行方式就像加減或者乘除這種同級運算，從左到右進行，如果你想給式子裏再加一個式子且不把運算順序和結果搞亂搞錯，就要把後來的式子外面套一個括號放進去。

• 然後我們來看花括號內部的第一部分drafts4://x-callback-url/，熟悉的 x-callback-URL 聲明又來了，就不多解釋了~
• 下一個runAction?是 Drafts 的運行某個動作的起始聲明，你看到一段 URL 裏有這句，就代表 Drafts 要運行一個動作了，後面的不遠處肯定能找到要運行的動作的名稱。
• 接下來的這句text=[[line|2..]]並不是動作名稱，而是動作的內容。text=是 Drafts 裏的一個語法，等號後面決定了該動作使用的文本是什麽。然後[[line|2...]]這句跟我們之前見過的[[line|1]]不太一樣，如果數字 2 後面沒有點點點，就特指的是第一句，但是如果有點點點了，意思就是對下面每行都重復該動作。
• 那麽什麽時候停呢？空白其實也是內容啊。所以你要告訴這個動作什麽時候停，在這裏用的是&allowEmpty=NO，這一句在 Drafts 的語法中意味：不允許發送空內容。
• 然後下一步的&action=Events%20in%20Fantastical-Quick，就承接前面我們提到的伏筆，提出了動作名，動作名是Events%20in%20Fantastical-Quick。為什麽裏面有這麽多%20？為什麽前面 Fantastical 的例子裏見到了好多%20，而直接用 Launch Center Pro 為什麽沒有這些 %20？這個問題涉及到什麽時候要在 URL 中使用編碼，什麽時候不使用的問題。我們後面會說到它。

按說整段 URL 已經結束了，但是我們看到最後還有一段兒 &x-cancel={{drafts4://}}，這裏的 x-cancel 也是我們提到過的 x-callback-URL 的固定語法，它的意思是，當我們取消這個任務了做什麽。然後看等號後面的內容，我們就知道，取消任務以後會回到（實際是打開）Drafts，但什麽都不做。

這一整段的 x-callback-URL，如果想正常工作，必須要保存為 Drafts 中的一個動作，動作名要和 URL 中提到的 Events in Fantastical-Quick 一致，改的話兩個都要改。這是最復雜的 URL Schemes 的一種形式之一：在一個 App （Fantastical）的 URL 中嵌套另一個 App（Drafts） 的 URL，同時 Drafts 的 URL 本身指涉的動作實際上還是不斷自指的。

關於 x-callback-URL 這是一個比較有代表性的例子，我們也看到了它固定語法中的 x-success 跟 x-cancel 是怎麽用的，固定語法中的另外兩個裏，x-error 的用法也與前兩者類似。只有 x-source 還要再說下。

在 x-callback-URL 的四大固定語法中，x-source 是個很小眾的用法。它一般和 x-success 連接，構成 x-source=選項名&x-success={{URL}}的格式。顯示在 App 中則是在上一個動作完成後（一般是跳轉後）給出一個選項，選項內容是你寫在 URL 中的選項名和 取消，選擇選項名後觸發 x-success 後的 URL 裏的動作，取消則停留在當前 App。也就是說，它給了你一個選擇，在這一步到底是繼續下一個動作還是停留在當前 App。

支持 x-source 的 App 不多，在這裏用 Due 的 URL Schemes 來舉個例子（無關部分已用省略號省略）：

due://......&x-source=墨客&x-success={{moke:}}

這段 URL 運行完，會出現的結果是跳轉到 Due，執行省略號中的動作，動作執行完後，會出現這樣一個菜單：

如果選擇墨客，就會跳轉到墨客。如果選擇取消，就會停留在 Due。

和其它類型的 URL Schemes 一樣，x-callback-URL 的格式也並非完全統一。我們前面已經知道，一個應用在使用 x-callback-URL 的時候要先通過 x-callback-url/ 聲明，比如 Launch Center Pro 在用到 x-callback-URL 的時候要這樣開始：

launch://x-callback-url/

但有的 App 會連自己其它部分的 URL 也修改了，比如 Instapaper 的是：

x-callback-instapaper://x-callback-url/add?…

所以想正確使用 x-callback-URL，還是要查看相應 App 的文檔。

URL 編碼（Encode）

編碼還是不編碼，這問題很容易。

完全不知道 URL Schemes 的人對 URL 的編碼和解碼可能有些陌生，但是你一旦入門，你很快就會碰上一些問題，這些問題很有可能是該編碼的部分沒編碼導致的。

比如玩效率 App 的入門人群最喜歡的一個 URL 大概就是百度搜索關鍵字的 URL：

http://www.baidu.com/s?wd=

等號後面可以用剪切板內容代替，或者輸入個什麽，然後就能直接在百度搜索關鍵字。但用 Workflow 做個動作以後，發現這 URL 不靈了，輸入中文就跳轉總失敗，怎麽回事兒？

還有上面的 Fantastical 的例子，那一片%20是啥？為什麽有的時候要有時候不要？

這些都涉及 URL 什麽時候要編碼什麽時候不需要的問題，而這問題並不難解決。

什麽時候要編碼？

URL 中的字符可以分為兩類[3]，一部分可以在鏈接中正常顯示，比如字母、數字還有/等一部分符號。除此之外，全部不能正常顯示，需要進行編碼才能夠作為 URL 的一部分出現。比如空格，在 URL 中就必須表示為 %20轉換的規則不用深究，網上有很多工具（比如 URL 解碼工具）提供 URL 的編碼和解碼功能，可以把編碼過的亂七八糟的 URL 解碼為我們看得清爽的字符：

Hi%2C+%E6%88%91%E6%98%AF+%40JailbreakHum 轉換為 Hi, 我是 @JailbreakHum

這些工具當然也可以反過來把我們常用的字符轉換成可以在 URL 中使用的字符。

所以理論上，所有 URL 不支持的字符，都要編碼。編碼的任務也就是這麽簡單，把 URL 不支持的字符換位它支持的字符。既然如此，為什麽有的時候不用編碼？

為什麽有的 App 不需要編碼？

因為那些不用編碼的時候，是 App 私下替你編了。就像在 Workflow 裏，在 URL 下面接了一步 URL Encode 一樣。這樣一來，不管你在前面的輸入框中輸的內容是什麽，URL 支持不支持，它都會試圖給你編碼。URL 支持的內容就忽略，不支持的就編碼，然後再進行下一步。這樣一來，省了你手動再編一次的麻煩。

實際上現在使用到 URL Schemes 的大部分 App，比如 Launch Center Pro 和 Drafts，都做到了自動編碼。前面也提到了，Workflow 中也有一個名為 URL Encode 的動作是專門用來編碼 URL 的。

那麽，啥時候用我們手動編碼呢？答案是：你把 URL 直接放到瀏覽器的地址欄的時候。

URL Schemes 都可以直接放到 Safari 的地址框裏觸發，因為 URL 就是地址/鏈接，而地址欄就是放鏈接的地方嘛。所以地址欄的 URL 就要嚴格遵守 URL 的規則，它看不懂了就不跟你玩了。除此之外，有一部分效率 App 也不會自動編碼，如果你發現哪個動作在 Launch Center Pro 裏跑的特別順暢，到其它 App 就卡殼兒的話，你就先把輸入內容編下碼，應該就能解決問題了。

如何查找以上各類 URL

前面介紹了基本、復雜、變形、x-callback-URL 這幾種形式的 URL Schemes，幾乎在每一部分都留下了一個問題——「去哪找這些 URL Schemes」？

其中，基本 URL Schemes 是可以由你自己手動查詢的，所有支持基本 URL Schemes 的 App 都可以用以下方法查到其基本 URL Schemes。而其它幾種 URL Schemes 因為是寫進代碼中的，需要查詢各 App 的文檔，來參照例子根據自己的需求制作 URL。

查找基本 URL Schemes

越獄和不越獄本質上用的是同一種辦法，只是越獄以後可以直接從 iOS 查看 URL。

基本 URL Schemes 的查找方法可以通過 App 中的 info.plist 來查詢，分為越獄和不越獄的方法，二者原理一樣：

未越獄方法

不越獄的話，就無法查看 App 包內的內容，所以需要借助電腦。

首先，在 iTunes 找到你想用 URL 打開的 App，右鍵選擇在文件夾中顯示：

然後把這個文件復制到桌面上解壓（或者其它地方，總之不要直接在原文件夾解壓）：

解壓完畢後，在解壓出的文件夾中，找到 .app 文件：

然後選擇顯示包內容：

找到 info.plist 這個文件，用你電腦裏能打開它的 App 打開它（Mac 上用 TextWrangler 就好）。

然後查找 URLSchemes：

在 CFBundleURLSchemes 下的那兩行就是該 App 的基本 URL Schemes 了。

需越獄方法

如果越獄後，可以用 iFile 或 Filza File Manager 這樣的文件管理軟件，進入路徑：

/var/containers/Bundle/Application

找到你想要用 URL Schemes 打開的 App，進入下一級文件夾，搜索 info.plist：

最後用文本編輯器打開 info.plist，在其中搜索 URLSchemes 即可：

本質上，如前文所說，兩者是一種方法，區別僅是越獄後查詢的靈活度變高，你隨時可以看看自己新裝的 App 的 URL Schemes 是啥。如果你像我一樣基本使用 Launch Center Pro 代替主屏的話，這種靈活性還是需要的。

復雜 / 變形 / x-callback-URL

若想全知全能，唯有查詢文檔。

復雜 / 變形 / x-callback-URL 這三種類型的 URL Schemes 是寫入代碼中的，無法通過查詢 .plist 文件來獲取。但支持這三種 URL Schemes 的 App 的開發者將這些功能加入到自己 App 中一般是希望用戶使用的，所以針對那些希望用戶使用的功能都會專門寫文檔來告訴讀者如何使用它們。

如果你想搜索任何一個 App 的復雜 / 變形 / x-callback-URL，你只要搜 App 名 URL Schemes，一般就能找到該 App 的 URL Schemes 文檔頁面。同時，直接去這些 App 的官網查找相關網頁也可以。

網上會推薦一些庫，看起來很方便，你可以一搜就能找到某個 App 支持的 URL Schemes。但實際上，它們沒那麽好用，因為你想，這些庫，跟網上那些列表一樣，都是個人自發做的，所以覆蓋面未必夠，時效性也肯定不如開發者的文檔高，畢竟做庫和列表的這些人也得看了開發者的文檔才能添加到自己的庫或列表裏。

但是，如果你用 Launch Center Pro 的話，我倒是推薦你在想找一個 App 的 URL Schemes 的時候先看下 Launch Center Pro。Launch Center Pro 會匹配你的 App，然後直接顯示出該 App 可使用的 URL。而且在動作生成的最後一步，你只需要考慮你這個動作要輸入的是普通文本還是純數字（比如填日期時間等就只需要純數字），根據你的內容選擇普通鍵盤或數字鍵盤。也就是說，通過 Launch Center Pro 生成的動作是幾乎不用考慮語法的。僅憑 Launch Center Pro 可以解決大部分的 URL Schemes 制作問題，反過來，你也可以根據 Launch Center Pro 生成的動作去理解 URL Schemes。

不過因為 Launch Center Pro 的庫也是人做的，它也不是全能的，也有覆蓋不全和時效性的問題。所以想完全打造符合你自己使用情境的一套 URL Schemes，還是要手動查文檔。

但僅靠扒別人的動作是無法根據自己的情境為自己量身定做一套自動化的動作的，要學會靠自己，查文檔。

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. 半小時以後叫我。」就能定一個計時器。在這種比較之下 Due 這樣的 App 的作用顯然是被大大地削弱了。除此之外還有通知中心部件，Sharesheet 的出現都在一定程度上代替了 URL Schemes 的作用，削弱了其價值。 但按照目前的狀態，充其量只能說 URL Schemes 在衰敗，還遠不能宣判其死刑。

3D Touch 和 URL Schemes 重復的地方只有一部分復雜 URL Schemes 的功能：一些復雜 URL Schemes 的功能 3D Touch 沒有涵蓋，反過來 3D Touch 也有一些可以做到的事通過復雜 URL Schemes 做不到。但在復雜 URL Schemes 之上的變形 URL Schemes 跟 x-callback-URL 都是 3D Touch 無法做到的。

Siri 確實非常好用，我每天都用它很多次。所以我知道，如果不戴耳機，它是通過揚聲器跟你交流的，這種時候它聽錯了你說錯了，都得來回矯情半天，周圍有人的話場面會變得很尷尬。所以很多場合，通過 Due 的 URL Schemes，直接從 Dock 中的 Launch Center Pro 裏找到一個 Timer 或添加一個提醒其實更舒服。

我承認 URL Schemes 如今已無往日輝煌，但它在 iOS 上的效率方面的作用能不能被完全替代，目前也未可知。

轉載地址:https://sspai.com/post/31500

URL Schemes(轉載)