Emoji問題由來
這里推薦周俊杰知乎上的的回答:Android 微信對 emoji 的支持是不是很差搂誉?為何這樣設(shè)計噩斟?
Emoji從最早開始到現(xiàn)在儒飒,比較通用的是兩種編碼方案眼姐,分別是Softbank和Unicode者蠕,android版微信早期也是使用Softbank編碼窃祝,然后客戶端根據(jù)表情對應(yīng)的Softbank編碼使用SpannableString在TextView, EditText中顯示成對應(yīng)的表情,此時Emoji表情的集合還不是很多踱侣,微信只打包進去了大概400多個左右粪小,在早期可以滿足大部分Emoji表情的顯示需求但是,隨著Unicode 6.0以及Unicode 7.0的發(fā)布抡句,越來越Emoji表情被加入到這個標(biāo)準(zhǔn)當(dāng)中探膊,iOS系統(tǒng)自行擴展OpenType標(biāo)準(zhǔn),通過Apple Color Emoji.ttf這個字體來講Emoji表情直接顯示出來(OSX下也有這個字體玉转,在/System/Library/Fonts/Apple Color Emoji.ttf)突想,當(dāng)時國外也有對這個問題進行過討論:Color bitmapfonts… thanks to Apple?! ,但是,由于新加進來的表情都沒有對應(yīng)的Softbank編碼猾担,無法轉(zhuǎn)碼成Softbank袭灯,并且客戶端在打包的時候只放進了400多個Emoji表情,所以在顯示的時候绑嘹,只能轉(zhuǎn)換成”..”來顯示
Emoji的過濾方式
網(wǎng)上文章也有很多:Android 準(zhǔn)確過濾(禁止) Emoji表情
鏈接1:Emoji列表過濾稽荧,但是直接從 Emoji Unicode Tables 網(wǎng)站獲取的列表 4. Enclosed characters ( 24C2 - 1F251 ) 區(qū)間會和漢字沖突,實際范圍是 24C2 和(1F170 - 1F251)工腋,標(biāo)題錯了姨丈,作者沒有修改直接把漢字內(nèi)容(例如:我,們擅腰,有 ……)也過濾了蟋恬,并且沒有過濾 5. Uncategorized 忽略了許多表情。列表過濾相對準(zhǔn)確趁冈,但是需要先加載列歼争,雖然使用了靜態(tài)方法但是首次使用要較長加載時間,過濾時匹配也相對耗時渗勘。
鏈接2:過濾區(qū)間沐绒,但是只過濾了雙字節(jié)的Emoji表情,忽略了單字節(jié)的表情旺坠,并且區(qū)間也不合理(判斷得很復(fù)雜乔遮,結(jié)果等同于直接過濾了 utf8
Surrogates,這樣如果有其他的 Surrogates 區(qū)的編碼字符也會被過濾掉)取刃。相對列表過濾速度快蹋肮,但存在多過濾和少過濾的較多。
綜合兩種情況考慮蝉衣,既要保證速度又要保證過濾的準(zhǔn)確性括尸。Android EditView 以 UTF-16 為編碼16位為一個單位。由于兩字節(jié)以上的Unicode 編碼基本上沒用到病毡,直接過濾掉 Surrogates 區(qū)(0xD800-0xDFFF)濒翻;再過濾掉單字節(jié)的Emoji表情列表。
當(dāng)然為了確保絕對只過濾Emoji表情啦膜,這里使用1的方法有送,修改了 4. Enclosed characters ( 24C2 - 1F251 ),添加了 5. Uncategorized 僧家,畢竟現(xiàn)在Android的處理器性能都很高雀摘,效率可以不用考慮了。當(dāng)然也可以使用區(qū)間過濾八拱,添加個 Scrope 阵赠,再修改下filter()方法涯塔。
-Emoji在不同版本的android手機上適配問題
Android開發(fā)中,低版本Android系統(tǒng)和高版本Android系統(tǒng)分別怎么處理emoji?
個人建議:關(guān)于Emoji兼容性清蚀,最好還是利用網(wǎng)上現(xiàn)有的Emoji相關(guān)庫匕荸,畢竟人多力量大,使用人數(shù)多肯定是有原因的枷邪。