最近項目開發的時候發現插入emoji表情的時，會報如下錯誤：
Caused by; com. ibatis。common. j dbc。except ion .NestedSQLExcept ion:
The error occurred while applying a parameter map.
Check the MS -RESERVATION RECORD UPDATE- InlinePa raneterMap。
Check the statement ( update fai Led) .
Cause: java. sql. SQL Exception: Incorrect string value: '\xF0\x9F\x98\x93\xF0\x9F...' for column
查看DB實例的時候charactor_ser_server=utf8mb4,經測試數據庫是支持emoji表情的，通過命令行的方式插入emoji表情都是正常的，但是通過應用服務器插入數據就是失敗。
通過以上定位出現問題在應用服務器與DB的連接問題。
理所當然的最優解決方案
既然是DB連接問題，那麼在連接中設置指定編碼，就可以了，在connectionProperties中添加參數
newConnectionSQL=set names utf8mb4
不僅這個業務問題，整個服務器的emoji問題都解決了。
但是這個方式有個缺點，影響範圍大，雖說utf8mb4編碼是utf8的超級，但是一個應用服務器上跑着N多個服務，稍有問題就是全局大問題，而且無法降級，回滾風險高。
這種方式適合業務不多或者有充分的時間進行迴歸的場景。
其他解決方案
- 通過URL編碼，在插入的時候進行encode，查詢後進行decode操作，當然缺點也很明顯，encode後數據長度邊長，讀取時必須要轉換，不利於後期維護。而且歷史數據還需要處理
- 序列化後存儲，操作類似"通過URL編碼"，但是序列化後必須要通過編碼的方式進行decode，維護成本也高,而且歷史數據還需要處理
- 替換emoji表情，因爲emoji表情基本固定在一個編碼範圍內，在保存數據的時候將emoji識別出來，並且通過URL編碼進行替換，在emoji數據添加固定前綴和後綴，在讀取的時候將emoji解碼出來即可，當然前綴和後綴選擇時最好是用戶基本不可能會輸入的分隔符。
最終方案
經過最終選擇，還是選擇了替換emoji表情的方案，其他方案的優劣還是很明顯的，要麼是成本高，要麼是風險高。
在技術方案選擇時可降級，可回滾需要擺在最高位置。
替換的方案是參照 https://www.cnblogs.com/shihaiming/p/5833244.html 文章上的方式
在git上還有一個emoji轉換的庫，https://github.com/vdurmont/emoji-java 在生產項目中很少會使用個人開發的庫，而且這裏自己動手成本也低，無需要引入其他庫！