這個事情說來話長，先從2010年之前的各種上戶口問題，以及各種民生系統(tǒng)問題說起吧谋减。
那個時候總是出現(xiàn)一些行為，說的是扫沼，誰的名字有生僻字上不了戶口出爹，用其他的字代替了，
出現(xiàn)了很多那種在族譜上是一個名字缎除，戶籍部門一個名字這種奇怪的現(xiàn)象严就。
這個事情我們從軟件開發(fā)的角度來談?wù)劊瑸槭裁凑f是2010年內(nèi)器罐，我猜想哦梢为，這些軟件使用
的是MySQL，也許不一定可能是oracle轰坊。但是涉及到國家安全的問題我覺得MySQL的概率或
者是基于MySQL進行國產(chǎn)化的一些數(shù)據(jù)庫铸董。這個涉及到MySQL的歷史
回到2002年，如果用戶可以保證表中的每一行具有相同的字節(jié)數(shù)肴沫，MySQL就可以提高用
戶的速度粟害。為了得到這個提升，用戶就需要定義保存文字的列為“CHAR”颤芬。一個“CHAR”列總是
擁有相同的字符數(shù)悲幅。如果存入的字符較少則會在最后補齊空白。如果存入的數(shù)據(jù)過多則會被拋
棄多余的字符站蝠。
當(dāng)MySQL的開發(fā)者第一次嘗試以6字節(jié)每字符實現(xiàn)UTF-8時汰具，他們意識到CHAR(1)的列會
占用6字節(jié)，CHAR(2)會占用12字節(jié)沉衣，以此類推郁副。
顯而易見的是，這個沒有被使用的實現(xiàn)方式是正確的豌习，任何一個理解UTF-8的開發(fā)者將會
認(rèn)同這一點存谎。
我的猜測是：MySQL的開發(fā)者違背了“utf8”編碼去幫助那些1)試圖去優(yōu)化空間和速度的人拔疚，
2）嘗試優(yōu)化空間和速度失敗的人。
這是個無人獲益的改動既荚。那些想要更快性能稚失，更小空間的得到的依然是比他們曾經(jīng)使用
版本更大更慢的實現(xiàn)，而那些想要正確的“utf8”的人得到的是個“”都存儲不了的實現(xiàn)恰聘。
MySQL發(fā)布了這個錯誤的版本后句各，在也沒有修復(fù)它：因為那樣很多使用者將被迫重建他
們的數(shù)據(jù)庫。MySQL最終在2010年更新了一個以“utf8mb4”命名的UTF-8實現(xiàn)晴叨。
對于MySQL數(shù)據(jù)庫我們該怎么設(shè)計呢凿宾，我認(rèn)為的字符編碼最好是utf-8mb4
(1)惠呼、GBK包含全部中文字符葛菇；
(2)摩钙、 UTF-8則包含全世界所有國家需要用到的字符涌献。
(3)凯沪、utf8mb4專門用來兼容四字節(jié)的unicode棠枉。utf8mb4是utf8的超集潦闲，除了將編碼改為utf8mb4外不需要做其他轉(zhuǎn)換乡革。
安照上述說明可得知Emoji 表情（Emoji 表情是一種特殊的unicode）牵啦、生僻漢字亚情。等等都應(yīng)該在utf8mb4編碼里面了。所以我們在數(shù)據(jù)庫層面解決了字符表情生僻字的問題
那對于html顯示呢哈雏，我們該怎么設(shè)計內(nèi)楞件。
1、理論上代碼是utf-8編碼顯示是不是問題的僧著，html是可識別的（此處的utf-8和數(shù)據(jù)的utf-8不一樣履因，注意哈）
2、實際情況是數(shù)據(jù)庫取出來debug打印沒有問題可以顯示盹愚，但是放到html就有問題顯示出來的是一個方框
這個問題主要是字體庫的問題栅迄，系統(tǒng)默認(rèn)使用的是微軟雅黑微軟雅黑是沒有生僻字和圖標(biāo)字體的
我們只要在css樣式里面引入宋體simsun就行如
body{font:14px Helvetica Neue,Tahoma,Arial,sans-serif,simsun}
那PHP編碼轉(zhuǎn)化我們該怎么使用呢
mb_convert_encoding("?昊","GBK","UTF-8");
iconv("UTF-8","gbk//IGNORE","?昊");
看看兩個的區(qū)別iconv出來出來?是亂碼，而mb_convert_encoding處理出來是正常的皆怕，這個提現(xiàn)在編碼轉(zhuǎn)換的用法上毅舆。
總結(jié)現(xiàn)在的編碼轉(zhuǎn)換中文的有好幾個版本涉及到姓名的建議使用最新的國標(biāo)編碼
GB18030 > GBK > GB2312
GB18030 的是最全的編碼，轉(zhuǎn)化的話使用mb_convert_encoding("?昊","GB18030","UTF-8");效果應(yīng)該是最好的愈腾，即使你這輩子一次沒有見過憋活，只有那些專家看過的字你也能轉(zhuǎn)化識別出來。
