2. 程式人生 > >URL Schemes 使用詳解

URL Schemes 使用詳解

阿新 • • 發佈：2019-01-26

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

）：

注：文中會提到使用 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 上的微信來做個簡單對比：

網頁（蘋果） iOS 應用（微信）
網站首頁/開啟應用 http://www.apple.com weixin://
子頁面/具體功能 http://www.apple.com/mac/（Mac頁面） weixin://dl/moments（朋友圈）

在這裡，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...]]這句跟我們之前見過的

    相關推薦

    Django 2.0 新款URL配置詳解

    Django2.0釋出後，很多人都擁抱變化，加入了2的行列。 但是和1.11相比，2.0在url的使用方面發生了很大的變化，下面介紹一下： 一、例項 先看一個例子： from django.urls import path from . import views urlpattern

    Django URL name詳解

    開場白不多說，下面直接開始。先上一下完成的工程目錄（注：使用的編譯器為Pycharm,python版本為3.6，django版本為2.0） 1.先開啟django目錄下的urls.py檔案，檔案程式碼如下： 我們看到url列表中有 path('add/&

    Django url()函式詳解

    url()函式看起來的格式象：url(r^/account/$', views.index, name=index)，它可以接收四個引數，分別是兩個必選引數：regex、view和兩個可選引數：kwargs、name，接下來詳細介紹這四個引數。 regex regex代

    004：URL組成部分詳解

    URL是什麼 URL 是 Uniform Resource Locator 的簡寫，統一資源定位符。 一個 URL 由以下幾部分組成： scheme://host:port/path/?query-string=xxx#anchor scheme：代表的是訪問的協議，一般為 http

    rest_framework之url控制器詳解

    一 自定義路由（原始方式） from django.conf.urls import url from app01 import views urlpatterns = [ url(r'^books/$', views.BookView.as_view()), url(r'^books

    css cursor url用法詳解

    html{cursor: url("http://ued.taobao.com/blog/wp-content/themes/taobaoued/images/cursor.ico"),auto;} 友情提示：本頁面能看到自定義滑鼠圖示的演示效果！如

    Servlet中url-pattern詳解

    過濾器概述        過濾器就好比應用中的保安，利用過濾器實現對請求和響應的攔截。 編寫過濾器的步驟 編寫一個類，實現javax.servlet.Filter介面 [java] vi

    web.xml中的url-pattern詳解

    Servlet和filter是J2EE開發中常用的技術，使用方便，配置簡單。servlet和filter中的url-pattern有一些文章在裡面的，總結了一些東西，以免遇到問題又要浪費時間。 一、先精確匹配，再路徑匹配 （路徑匹配的時候，先最長路徑匹配，再最短路徑匹配）

    java.net.URL類詳解

           java.net.URL中定義了URL相關的操作，其主要利用的是openStream();方法來返回一個InputStream，然後可以使用InputStreamReader和BufferedReader來封裝從而獲取網上已釋出的資源內容。具體使用如下:

    PHP中獲取當前頁面的URL資訊詳解

    <? //獲取當前的域名: echo $_SERVER['SERVER_NAME']; //獲取來源網址,即點選來到本頁的上頁網址 echo $_SERVER["HTTP_REFERER"]; $_SERVER['REQUEST_URI'];//獲取

    iOS URL scheme 詳解

    launch center pro支援的引數主要有兩個，[prompt]文字輸入框和[clipboard]剪貼簿 淘寶寶貝搜尋 taobao://http://s.taobao.com/?q=[prompt] 淘寶店鋪搜尋 taobao://http://shopsearch.taobao.com/brows

    ios開發－－ URL Schemes 使用詳解

    用原生 iOS 的人分兩種，懂 URL Schemes 的和不懂的。 前者是「魔法師」，後者是「麻瓜」。 URL Schemes 應用在 iOS 上已經很久了。對於使用者來說，在沙盒機制下的 iOS 中，如果想做到一定程度上的自動化就不可避免地要用到 URL S

    URL Schemes 使用詳解

    URL Schemes 應用在 iOS 上已經很久了。對於使用者來說，在沙盒機制下的 iOS 中，如果想做到一定程度上的自動化就不可避免地要用到 URL Schemes。但因為 URL Schemes 的使用方式不像傳統 iOS 使用者接觸到的圖形介面那樣可以直觀地點來點

    window.location獲取url各項參數詳解

    server ear 端口 空字符 alert 定位 hostname javascrip cati window.location方法後還還可以帶href,search等參數，下面我們來看看獲取url各項參數的辦法。URL即:統一資源定位符 (Uniform Resour

    微信公眾開發URL和token填寫詳解

    res wrap this true 進行 -m tmp sem 知識 微信公眾開發URL和token填寫詳解 方法/步驟 作為一名微信公眾號開發者，別人進入你的微信公眾號，肯定會看見某些網頁，或者給你發某些信息，你需要實時自動回復，所以你

    詳解servlet的url-pattern匹配規則.RP

    ont 有一個 att 而且 borde param class 配方 12px 　　首先需要明確幾容易混淆的規則： servlet容器中的匹配規則既不是簡單的通配，也不是正則表達式，而是特定的規則。所以不要用通配符或者正則表達式的匹配規則來看待servlet的url-p

    HTTP協議詳解以及URL具體訪問過程

    標記語言 初始化 折疊 code 文件類型 scheme 缺少 gif 其他瀏覽器 1、簡介 　　1.1、HTTP協議是什麽？ 　　即超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網絡協議，所有的WWW文件都必

    javascript 獲取get參數方法（獲取url參數方法）詳解

    rip req 調用方法 div type body cape esc amp 網上有很多關於獲取url參數的方法，我給他們都加了註釋。不懂的朋友可以給我留言 1 <script type="text/javascript"> 2 func

    python web開發-flask中url帶斜線/和不帶斜線/的區別詳解

    編程語言 Python flask中帶斜線和不帶斜線的url通過flask進行路由配置的時候，有一個細節，就是同樣的url，帶上”/”和不帶”/”有什麽區別。舉例說明：比如有個url，名字為”/url”先同時定義兩種url，一種帶”/”，一種不帶”/”,如下代碼：@app.route("/url")d

    Django url()函數詳解

    cout emp stack del keyword rst http index 一模一樣 url()函數看起來的格式象：url(r^/account/$‘, views.index, name=index)，它可以接收四個參數，分別是兩個必選參數：regex、view和