这个事情说来话长，先从2010年之前的各种上户口问题，以及各种民生系统问题说起吧。
那个时候总是出现一些行为，说的是，谁的名字有生僻字上不了户口，用其他的字代替了，
出现了很多那种在族谱上是一个名字，户籍部门一个名字这种奇怪的现象。
这个事情我们从软件开发的角度来谈谈，为什么说是2010年内，我猜想哦，这些软件使用
的是MySQL，也许不一定可能是oracle。但是涉及到国家安全的问题我觉得MySQL的概率或
者是基于MySQL进行国产化的一些数据库。这个涉及到MySQL的历史
回到2002年，如果用户可以保证表中的每一行具有相同的字节数，MySQL就可以提高用
户的速度。为了得到这个提升，用户就需要定义保存文字的列为“CHAR”。一个“CHAR”列总是
拥有相同的字符数。如果存入的字符较少则会在最后补齐空白。如果存入的数据过多则会被抛
弃多余的字符。
当MySQL的开发者第一次尝试以6字节每字符实现UTF-8时，他们意识到CHAR(1)的列会
占用6字节，CHAR(2)会占用12字节，以此类推。
显而易见的是，这个没有被使用的实现方式是正确的，任何一个理解UTF-8的开发者将会
认同这一点。
我的猜测是：MySQL的开发者违背了“utf8”编码去帮助那些1)试图去优化空间和速度的人，
2）尝试优化空间和速度失败的人。
这是个无人获益的改动。那些想要更快性能，更小空间的得到的依然是比他们曾经使用
版本更大更慢的实现，而那些想要正确的“utf8”的人得到的是个“”都存储不了的实现。
MySQL发布了这个错误的版本后，在也没有修复它：因为那样很多使用者将被迫重建他
们的数据库。MySQL最终在2010年更新了一个以“utf8mb4”命名的UTF-8实现。
对于MySQL数据库我们该怎么设计呢，我认为的字符编码最好是utf-8mb4
(1)、GBK包含全部中文字符；
(2)、 UTF-8则包含全世界所有国家需要用到的字符。
(3)、utf8mb4专门用来兼容四字节的unicode。utf8mb4是utf8的超集，除了将编码改为utf8mb4外不需要做其他转换。
安照上述说明可得知Emoji 表情（Emoji 表情是一种特殊的unicode）、生僻汉字。等等都应该在utf8mb4编码里面了。所以我们在数据库层面解决了字符表情生僻字的问题
那对于html显示呢，我们该怎么设计内。
1、理论上代码是utf-8编码显示是不是问题的，html是可识别的（此处的utf-8和数据的utf-8不一样，注意哈）
2、实际情况是数据库取出来debug打印没有问题可以显示，但是放到html就有问题显示出来的是一个方框
这个问题主要是字体库的问题，系统默认使用的是微软雅黑微软雅黑是没有生僻字和图标字体的
我们只要在css样式里面引入宋体simsun就行如
body{font:14px Helvetica Neue,Tahoma,Arial,sans-serif,simsun}
那PHP编码转化我们该怎么使用呢
mb_convert_encoding("䶮昊","GBK","UTF-8");
iconv("UTF-8","gbk//IGNORE","䶮昊");
看看两个的区别iconv出来出来䶮是乱码，而mb_convert_encoding处理出来是正常的，这个提现在编码转换的用法上。
总结现在的编码转换中文的有好几个版本涉及到姓名的建议使用最新的国标编码
GB18030 > GBK > GB2312
GB18030 的是最全的编码，转化的话使用mb_convert_encoding("䶮昊","GB18030","UTF-8");效果应该是最好的，即使你这辈子一次没有见过，只有那些专家看过的字你也能转化识别出来。
