吃了經驗的虧，因為Emoji表情引起的項目bug被撸主遇到兩次了，總有一些調皮的小朋友愛用表情來搞點事。第一次把當時那個表改為utf8mb4解決了，第二次說啥都不好使。網上找了半天，發現好多人不去實驗一下就復制別人的代碼網上發，然後導致我拿來用直接不行。最後一遍遍嘗試終於解決了，防止以後再出錯，總結下吧。
我們的MYSQL數據庫普遍用的字符集是UTF-8，默認情況下是utf8_general_ci,這種字符集下，默認是支持1-3字節的編碼，當然這對字母，漢字都是沒啥問題的。但是對手機帶的Emoji表情級不行了，因為它是4個字節的。
這裡介紹處理的一些辦法吧，主要有兩個：
第一，修改數據庫字符集：
這種方法需要的硬性要求就是你的mysql數據庫版本5.5以後的。一般有數據庫管理工具的，直接打開改了就是了，比如我用的HeidiSQL，直接把表改為utf8mb4就可以了。如圖：
在默認字符集那裡調整
就可以了。
這種方法簡單省事，但是可能需要重啟數據庫。還有個問題是，有時候這方法不太靈，我第一次用這個方法，完美解決的問題，但是第二次，說啥都不好使。所以，這種方式還是不推薦了。
第二，將這些表情過濾掉
既然數據庫不能保存，那就直接把這些表情過濾掉好了。這種情況是損壞客戶的個性而讓服務更便捷的一張方式。目前很多網站就是這麼干的，畢竟效率是關鍵，你這表情即便保存了，也說不定哪裡再次用到，展示不了。
過濾這種事，簡直太多坑，比如，我嘗試了很多次的這種代碼：
撸主曾經十分堅信這就是最接近答案能解決表情問題的代碼，即便不能，給他稍微改改就可以了。但是經過好多次，無論怎麼搞，所有的字母和漢字全部都會給過濾成表情，最終還是沒解決。哎，還是太年輕。
結果沒辦法，再去找別的代碼，於是，碰到了正確的，也是目前最推薦的答案：
/**
* emoji表情替換
*
* @param source 原字符串
* @param slipStr emoji表情替換成的字符串
* @return 過濾後的字符串
*/
public static String filterEmoji(String source,String slipStr) {
if(StringUtils.isNotBlank(source)){
return source.replaceAll("[\\ud800\\udc00-\\udbff\\udfff\\ud800-\\udfff]", slipStr);
}else{
return source;
}
}
建議做成工具方法，方便實用，親測可行。
