印象筆記 SDK 踩坑記

作者：swiftyper

來源：http://www.swiftyper.com/2017/02/18/struggle-with-evernote-api/

於我而言，一個筆記工具最重要的兩個功能就是信息採集和提取。

人腦是用來思考而非用來記憶的，因此我們需要一個外部系統來存儲個人化的信息。這一點的體現就在於，我們能隨時隨地方便地將看到的有價值的信息保存起來。網上的各種博客文章和微信公眾號是我的主要信息來源，我的印象筆記配合上剪藏插件就能完美地解決我信息採集的問題。

提取信息最好的辦法是搜索，印象筆記在這一點上也是做得很出色。可以說，有了它的搜索功能，基本上我收藏文章的時候可以不需要進行分類了（然而，作為一個有整理強迫症的人，不分類我是不能忍的）。IBM 做過一個研究，讓人去找一封電子郵件，有的人喜歡搜索，有的人喜歡平時就把郵件分類。結果搜索的人平均只需要 17 秒可以找到他想要的郵件，而分類的人則需要 58 秒。

雖然印象筆記的搜索功能已經很好用了，但是每次要搜索的時候還是得先打開印象筆記再進行搜索，這一個流程下來，少說也要花掉三四秒的時間，並且還要把手從鍵盤上移到滑鼠（觸摸板）上，實在是太費勁了。

優化搜索方案

對於使用 Mac 的人來說，要提高效率，第一反應就是能不能使用 Alfred 來完成這件事。本著不重複造輪子的原則，我立馬上 Google 搜索了印象筆記相關的 workflow，結果還真讓我找到一個。

但是由於這個 workflow 使用的 JavasScript SDK 是舊版本的，很多功能都不能正常使用，再加上它針對的是 Evernote 而非印象筆記。與其去大動干戈地修改它裡面的內容，還不如仿造這個項目，自己使用 Python 寫一個。

由於有一個現成的項目做參照，因此在做 workflow 的時候沒有碰到什麼大問題。反而是在我自認為可以很快完成的印象筆記 API 上跌入了大坑中，白白浪費不少時間。

整個 API 開發過程中主要就是卡在 Token 認證問題上，主要原因就是官方的開發文檔沒寫清楚，特別是對於印象筆記和 Evernote 間的認證差異問題沒有特別說明。這裡主要就是把我接入 SDK 過程中一些問題記錄下來，希望可以幫助後來人不再翻車。

workflow 已完成，並上傳到 Github：

Token 認證問題

由於我們需要的只是搜索自己的筆記，因此也不需要走 OAuth 的整個流程了。只需要在印象筆記的 Developer Token的頁面上直接獲取到 Token 就行了。

根據文檔上的說法，只要做下面的操作就可以認證了：

但是，我在做這步操作的時候，死活都是認證不通過。直到我去翻了這個 SDK 的源碼後才發現這裡面藏著幾個坑啊（這也就是開源的好處，源碼才是最官方的文檔）。

下面是 EvernoteClient 的構造方法：

可以看到，構造方法有一個 sandbox 參數，默認是 。sandbox 伺服器是印象筆記的開發測試伺服器，主要用於在應用程序發布到生產環境前進行的開發工作。但是，我們要做的東西只是針對自己的帳號，沒有所謂的開發或者生產環境，並且測試伺服器裡面是沒有筆記的，也就沒辦法進行筆記搜索的測試了。

然而，在我把代碼改成 後，還是認證不通過。

無奈之下，只好再回過頭看源碼，才發現構造方法裡面用的伺服器地址全是 Evernote 的，並沒有印象筆記的伺服器地址，我們必須自己指定 參數。用印象筆記的 Token 來 Evernote 伺服器上進行驗證，怎麼可能認證通過！

這麼關鍵的一個東西，開發者文檔上居然一！個！字！都！沒！提！

好吧，直接指定 的話，sandbox 參數也可以省了，這次代碼應該是這樣的：

誰知道，這次改過之後直接運行錯誤了，信息如下：

原來，python 是使用 socket 進行通信的，所以不能使用 前綴，網上有很多類似的問題，但是只有這個解決方案才是針對我這種情況的。

現在，該加的也加了，該刪了也刪了，應該是可以正常運行了。不過，果然還是太天真了，運行之後出錯了另一個錯誤：

就在我確信已經沒有任何辦法的時候，我的程序員直覺告訴我，再試最後一次。

於是，我隨手登錄了我的帳號，然後發現…瀏覽器地址欄上的 URL 變成了 。

我用著顫抖的雙手，把代碼改成了：

然後運行。

終於，控制台上列印出了我的用戶名。

其它的一些小問題

我在用 python 寫 workflow 的時候，使用到了 alfred-workflow 這個庫，它對於接受的參數已經做過了 unicode 處理，如果直接傳到筆記搜索 API 裡面是有問題的。

因此，在使用前需要先進行轉碼：

關於 python2 中的 Unicode 處理，可以參考 Unicode HOWTO。

小結

其實，只要文檔上再多加一句說明，我也不用為折騰這個問題浪費大半天時間了。

經過這件事之後，我對其它兩件事更加確信了：

壞的文檔，不如沒有文檔

程序員能相信的只能自己和源碼

如果你對這個 workflow 感興趣的話，可以到我的 Github上進行下載。

題圖：pexels，CC0 授權。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！