1. php调用微信用户信息接口昵称里面的emoji表情怎么存储到mysql中
emoji表情 是四字节的需要utf-8mb4来存储，mysql5.6以上才支持utf-8mb4
2. 求php过滤ios的Emoji表情的方法，如果字符串中包含Emoji表情就删除。
网上已经有开源的了！http://code.iamcal.com/php/emoji/ 你参考下
iOS 5.0之前，苹果都是采用3个字节来承接 emoji 表情，Java 的普通 char 可以支持显示。但 iOS 5.0 之后， 苹果升级了系统自带的 emoji 表情输入法，用的 Unicode 6 标准来统一，是采用4个 bytes 来承接一个 emoji 表情。如果不做处理的话，这种表情直接存储到 mysql5.5 以下的数据库是会报错的。就像这两个表情一样：口口, 在 Windows 8 以下估计都不支持显示，可能会显示成框框，可能压根就是空白， 你可以在 Mac 中使用Safari 浏览器中，就可以看到。经过测试，在 Mac 就算用 Chrome 浏览器(Version 25.0.1364.172)也是不行的。
这种数据在 Mysql 5.5 之前，UTF-8 支持1-3个字节的编码，从 Mysql5.5 开始后，可以支持4个字节的 UTF 编码，但要特殊标记。修改 Mysql 相应存储字段为 utf8mb4 。修改语句如下：
1 ALTER TABLE table_name
2 MODIFY COLUMN content varchar(500) CHARACTER
3 SET utf8mb4 COLLATE utf8mb4_unicode_ci
4 DEFAULT NULL COMMENT 'content of message';
在某种业务情景下，我们可以选择过滤掉这种“非法”的字符。我采用的方式是，在字符上面做操作，下面是Java示例代码，核心的代码附上，应该是 无法直接下载就能够编译，你得小小的做一些微调，没有额外的依赖：
01 public class EmojiFilter {
02
03 /**
04 * 检测是否有emoji字符
05 * @param source
06 * @return 一旦含有就抛出
07 */
08 public static boolean containsEmoji(String source) {
09 if (StringUtils.isBlank(source)) {
10 return false;
11 }
12
13 int len = source.length();
14
15 for (int i = 0; i < len; i++) {
16 char codePoint = source.charAt(i);
17
18 if (isEmojiCharacter(codePoint)) {
19 //do nothing，判断到了这里表明，确认有表情字符
20 return true;
21 }
22 }
23
24 return false;
25 }
26
27 private static boolean isEmojiCharacter(char codePoint) {
28 return (codePoint == 0x0) ||
29 (codePoint == 0x9) ||
30 (codePoint == 0xA) ||
31 (codePoint == 0xD) ||
32 ((codePoint >= 0x20) && (codePoint <= 0xD7FF)) ||
33 ((codePoint >= 0xE000) && (codePoint <= 0xFFFD)) ||
34 ((codePoint >= 0x10000) && (codePoint <= 0x10FFFF));
35 }
36
37 /**
38 * 过滤emoji 或者 其他非文字类型的字符
39 * @param source
40 * @return
41 */
42 public static String filterEmoji(String source) {
43
44 if (!containsEmoji(source)) {
45 return source;//如果不包含，直接返回
46 }
47 //到这里铁定包含
48 StringBuilder buf = null;
49
50 int len = source.length();
51
52 for (int i = 0; i < len; i++) {
53 char codePoint = source.charAt(i);
54
55 if (isEmojiCharacter(codePoint)) {
56 if (buf == null) {
57 buf = new StringBuilder(source.length());
58 }
59
60 buf.append(codePoint);
61 } else {
62 }
63 }
64
65 if (buf == null) {
66 return source;//如果没有找到 emoji表情，则返回源字符串
67 } else {
68 if (buf.length() == len) {//这里的意义在于尽可能少的toString，因为会重新生成字符串
69 buf = null;
70 return source;
71 } else {
72 return buf.toString();
73 }
74 }
75
76 }
77 }
还有优化的空间，但是已经能够满足大多数情况的需求，附上单元测试(JUnit4):
01 public class EmojiFilterTest {
02
03
04 /**
05 * 测试emoji表情
06 */
07 @Test
08 public void fileterEmoji() {
09 String s = "<body>口口213这是一个有各种内容的消息, Hia Hia Hia !!!! xxxx@@@...*)!" +
10 "(@*$&@(&#!)@*)!&$!)@^%@(!&#. 口口口], ";
11 String c = Utils.filterEmoji(s);
12 assertFalse(s.equals(c));
13 String expected = "<body>213这是一个有各种内容的消息, Hia Hia Hia !!!! xxxx@@@...*)" +
14 "!(@*$&@(&#!)@*)!&$!)@^%@(!&#. ], ";
15 assertEquals(expected, c);
16 // assertSame(c, expected);
17 assertSame(expected, "<body>213这是一个有各种内容的消息, Hia Hia Hia !!!! xxxx@@@...*)" +
18 "!(@*$&@(&#!)@*)!&$!)@^%@(!&#. ], ");
19 assertSame(c, Utils.filterEmoji(c));
20 }
21
22 }
3. php创建mysql数据表，怎么选择UTF8字符集
一、转码失败
在数据写入到表的过程中转码失败，数据库端也没有进行恰当的处理，导致存放在表里的数据乱码。
针对这种情况，前几篇文章介绍过客户端发送请求到服务端。
其中任意一个编码不一致，都会导致表里的数据存入不正确的编码而产生乱码。
比如下面简单一条语句：
set @a = "文本字符串";
insert into t1 values(@a);
变量 @a 的字符编码是由参数 CHARACTER_SET_CLIENT 决定的，假设此时编码为 A，也就是变量 @a 的编码。
2. 写入语句在发送到 MySQL 服务端之前的编码由 CHARACTER_SET_CONNECTION 决定，假设此时编码为 B。
3. 经过 MySQL 一系列词法，语法解析等处理后，写入到表 t1，表 t1 的编码为 C。
那这里编码 A、编码 B、编码 C 如果不兼容，写入的数据就直接乱码。
二、客户端乱码
表数据正常，但是客户端展示后出现乱码。
这一类场景，指的是从 MySQL 表里拿数据出来返回到客户端，MySQL 里的数据本身没有问题。客户端发送请求到 MySQL，表的编码为 D，从 MySQL 拿到记录结果传输到客户端，此时记录编码为 E（CHARACTER_SET_RESULTS）。
那以上编码 E 和 D 如果不兼容，检索出来的数据就看起来乱码了。但是由于数据本身没有被破坏，所以换个兼容的编码就可以获取正确的结果。
这一类又分为以下三个不同的小类：
1)字段编码和表一致，客户端是不同的编码
比如下面例子， 表数据的编码是 utf8mb4，而 SESSION 1 发起的连接编码为 gbk。那由于编码不兼容，检索出来的数据肯定为乱码。
2）表编码和客户端的编码一致，但是记录之间编码存在不一致的情形
比如表编码是 utf8mb4，应用端编码也是 utf8mb4，但是表里的数据可能一半编码是 utf8mb4，另外一半是 gbk。那么此时表的数据也是正常的，不过此时采用哪种编码都读不到所有完整的数据。这样数据产生的原因很多，比如其中一种可能性就是表编码多次变更而且每次变更不彻底导致（变更不彻底，我之前的篇章里有介绍）。举个例子，表 t3 的编码之前是 utf8mb4，现在是 gbk，而且两次编码期间都被写入了正常的数据。
3）每个字段的编码不一致，导致乱码和第二点一样的场景。不同的是：非记录间的编码不统一，而是每个字段编码不统一。举个例子，表 c1 字段 a1,a2。a1 编码 gbk，a2 编码是 utf8mb4。那每个字段单独读出来数据是完整的，但是所有字段一起读出来，数据总会有一部分乱码。
三、LATIN1
还有一种情形就是以 LATIN1 的编码存储数据
估计大家都知道字符集 LATIN1，LATIN1 对所有字符都是单字节流处理，遇到不能处理的字节流，保持原样，那么在以上两种存入和检索的过程中都能保证数据一致，所以 MySQL 长期以来默认的编码都是 LATIN1。这种情形，看起来也没啥不对的点，数据也没乱码，那为什么还有选用其他的编码呢？原因就是对字符存储的字节数不一样，比如 emoji 字符 "❤"，如果用 utf8mb4 存储，占用 3 个字节，那 varchar(12) 就能存放 12 个字符，但是换成 LATIN1，只能存 4 个字符。
4. 爬虫写入mysql表里的数据都是这种Unicode编码，怎么转为可读文字
unicode emoji是4个字节的，存不进MySQL里，找到一个转义的库code.iamcal.com/php/emoji/，但是转为Unicode之后，还是4个字节，一样存不进，应该说根本没转。转为其他格式的emoji又怕以后新增了表情不好做，你们在不改数据库编码的前提下，是怎么弄的？
方法1：base_encode64
这种方法是可以，但是旧数据没有经过encode操作，取数据的时候如果统一进行decode的话，旧数据会丢失的。
方法2：urlencode
这个似乎可以，对没有经过encode的数据进行decode也不会有影响，而且多次decode似乎也不会有影响。
5. php调用微信用户信息接口昵称里面的emoji表情怎么存储到mysql中
经过测试虽然utf8mb4能够将数据存储到数据库中，但是还是有问题的：如果微信昵称前后面都有表情，中间有文字的时候，数据库中只能将前面的表情保存，后面的表情变成了空格，经过几番周折还是使用了utf8来保存下图蓝色条选中的那样字符串来保存，在前端对字符串进行去"处理，保证用户的昵称不被破坏