Swift 中判斷字符串是否有 Emoji 表情

更新:網絡上流傳的 emoji 代碼點不太完整,我按照維基百科的資料重新整理了一下,文中的 Swift 版本代碼已更新。

很多時候我們需要判斷一個字符、或者說是一句話裡是不是包含了emoji,使用 Swift 語言開發 app 也不例外,比如可以使用正則表達式——但很遺憾,似乎不同的語言對於正則表達式的支持區別, \u [……]

點擊跳轉以繼續閱讀

落格輸入法 是怎麼實現 app 設置而不需要 完全訪問 權限的?

眾所周知,在 iOS 平台上自從 8.0 版本開始,可以為 iOS 開發第三方的輸入法鍵盤了,而這些鍵盤可以被放在 AppStore 銷售了,不過,同時也有著十分嚴格的權限規則。

對此,蘋果為第三方的鍵盤設計了兩種權限,一種是最小的,只有最基本的鍵盤功能的權限、另一種則相對較多,鍵盤獲取了“完全訪問”權限之後基本上就和 安卓 上鍵盤差不多,可以訪問聯繫人、可以聯網等等。

不過[……]

點擊跳轉以繼續閱讀

無法加載 “” 與標識捆綁從筆尖引用圖像 “com.xxx.xxx”

今天遇到一個奇怪的問題,程序運行一點問題都沒有但終端報錯如下

其實就是題目上的錯誤,這個問題看上去挺簡單——不就是引用的圖片丟失了麼……

其實不然,由於名字是 "" 所以你根本找不到究竟是哪個圖片丟失了——實際上一個都沒有丟。

畢竟程序裡邊的資源一個都沒有[……]

點擊跳轉以繼續閱讀

寫 落格輸入法 的這半年裡獲得的 一點人生經驗

說出來你們可能不信,落格輸入法起初是我的一個練手項目,它叫小飛

但在動手寫它之前,其實我就已經抱怨過很多次了,說自己要寫一款好用的輸入法,因為我用雙拼,而現存的輸入法,都不怎麼重視雙拼這個群體,同時,就全拼來講,各種廣告彈窗小紅點也把它們本身整句輸入啊實用功能啊這些優點給埋沒了。

一直到 2015 年 11 月 7 日,我第一次有了動手寫一個輸入法的想法:

現在iOS上的輸入法大都臃腫[……]

點擊跳轉以繼續閱讀

CloudKit 優化指南

最近給落格輸入法加入了一個叫做“對數雲”的東西,其實不難,比使用 iCloud Document 要簡單,不過網上的資料不太多,你通過那些上手教程來現充應該不是問題,但想要提升用戶體驗,就不是那麼容易了。這裡我們就一起來看看,怎麼樣才能讓 CloudKit 運行得更暢快。

CKDatabaseOperation

一般來說,你獲取一條數據可能是這樣的:
[crayon-67420aa21017[……]

點擊跳轉以繼續閱讀

讓 iTrem 2 + zsh 啟動不再等待!

iTerm 作為一個 mac 裡自帶終端的替代品真的是太好用了,功能多、界面也好看。配合zsh+皮膚,終端從此也美麗(題圖)。

不過,zsh 啟動總是很慢,雖然說每次啟動前輸入的內容還是不會丟失,但總等著也不是個事(說句實在話,我就這麼忍受了好多年……)

總之,其實這個問題是可以被解決的:

進入 iTerm2 的偏好設置裡,在 Profiles 裡編輯你的配置,在配置右側的 Ge[……]

點擊跳轉以繼續閱讀

在 Swift 中使用 cmph

CMPH 的全稱是 ç最小完美哈希庫 ,是一個很著名的用 C 寫成的最小完美哈希庫,什麼是完美哈希?

完美哈希

這裡我們不講原理,你只需要知道傳統的哈希有衝突,我們需要靠各種算法來處理衝突就可以了,對於哈希,總是需要一個表,這個表裡預留了很多位置,然後計算出來的值就是這些位置的坐標,你可以把對應的數據放到坐標裡。

但這時候有一個問題,如果[……]

點擊跳轉以繼續閱讀

在字符串中 快速查找

很多時候,我們需要在字符串中執行查找,以判斷過濾指定的內容出來。比如過在落格輸入法當中,就需要用輔碼過濾出需要的候選詞。

一般來說,查找和對比肯定是數字來的最快,不過在詞庫上總不能把所有的詞彙都轉換為數字(雖然理論上可行……)在字符串的搜索上,我們有很多種辦法來實現,這裡我就說一下我自己的思路:

組<String>

由於我的詞庫輔碼篩選只對兩字或者三字詞彙生效,那麼我考慮[……]

點擊跳轉以繼續閱讀

基於動態規劃的整句輸入法

一般來說,我們不會在用動態規划算法求解的問題上稱呼它為“動態規劃“,而是稱之為“隱馬爾可夫模型“,不過,如果我們單純用動態規划算法來求解一個普通的有向無環圖,那麼就只能說是動態規劃了……

這次我們要來說的,是基於詞庫的整句輸入法。而不是基於狀態轉移的隱馬爾可夫模型求解。

詞庫

由於不需要模型,我們的整句輸入是基於詞彙的,就需要一個詞庫。這個詞庫裡應該記錄了普通人大部分的常用詞彙,而且有一[……]

點擊跳轉以繼續閱讀