phpemojimysql

㈠ 爬虫写入mysql表里的数据都是这种Unicode编码，怎么转为可读文字

unicode emoji是4个字节的，存不进MySQL里，找到一个转义的库code.iamcal.com/php/emoji/，但是转为Unicode之后，还是4个字节，一样存不进，应该说根本没转。转为其他格式的emoji又怕以后新增了表情不好做，你们在不改数据库编码的前提下，是怎么弄的？
方法1：base_encode64
这种方法是可以，但是旧数据没有经过encode操作，取数据的时候如果统一进行decode的话，旧数据会丢失的。
方法2：urlencode
这个似乎可以，对没有经过encode的数据进行decode也不会有影响，而且多次decode似乎也不会有影响。

㈡ MySQL与PostgreSQL相比哪个更好

MySQL
MySQL声称自己是最流行的开源数据库。LAMP中的M指的就是MySQL。构建在LAMP上的应用都会使用MySQL，如WordPress、Drupal等大多数php开源程序。MySQL最初是由MySQL AB开发的，然后在2008年以10亿美金的价格卖给了Sun公司，Sun公司又在2010年被Oracle收购。Oracle支持MySQL的多个版本：Standard、Enterprise、Classic、Cluster、Embedded与Community。其中有一些是免费下载的，另外一些则是收费的。其核心代码基于GPL许可，由于MySQL被控制在Oracle，社区担心会对MySQL的开源会有影响，所以开发了一些分支，比如： MariaDB和Percona。
PostgreSQL
PostgreSQL标榜自己是世界上最先进的开源数据库。PostgreSQL的一些粉丝说它能与Oracle相媲美，而且没有那么昂贵的价格和傲慢的客服。最初是1985年在加利福尼亚大学伯克利分校开发的，作为Ingres数据库的后继。PostgreSQL是完全由社区驱动的开源项目。它提供了单个完整功能的版本，而不像MySQL那样提供了多个不同的社区版、商业版与企业版。PostgreSQL基于自由的BSD/MIT许可，组织可以使用、复制、修改和重新分发代码，只需要提供一个版权声明即可。
MySQL与PostgreSQL的对比
MySQL的背后是一个成熟的商业公司，而PostgreSQL的背后是一个庞大的志愿开发组。这使得MySQL的开发过程更为慎重，而PostgreSQL的反应更为迅速。这样的两种背景直接导致了各自固有的优点和缺点。
PostgreSQL相对于MySQL的优势
1)不仅仅是关系型数据库
除了存储正常的数据类型外，还支持存储：
array，不管是一位数组还是多为数组均支持
json(hStore)和jsonb，相比使用text存储接送要高效很多
json和jsonb之间的区别
jsonb和json在更高的层面上看起来几乎是一样的，但在存储实现上是不同的。
json存储完的文本，json列会每次都解析存储的值，它不支持索引，但你可以为查询创建表达式索引。
jsonb存储的二进制格式，避免了重新解析数据结构。它支持索引，这意味着你可以不使用指定的索引就能查询任何路径。
当我们比较写入数据速度时，由于数据存储的方式的原因，jsonb会比json稍微的慢一点。json列会每次都解析存储的值，这意味着键的顺序要和输入的时候一样。但jsonb不同，以二进制格式存储且不保证键的顺序。因此，如果你有软件需要依赖键的顺序，jsonb可能不是你的应用的最佳选择。使用jsonb的优势还在于你可以轻易的整合关系型数据和非关系型数据， PostgreSQL对于mongodb这类的基于文档的数据库是个不小的威胁，毕竟如果一个表中只有一列数据的类型是半结构化的，没有必要为了迁就它而整个表的设计采用schemaless的结构。
2)支持地理信息处理扩展
PostGIS 为PostgreSQL提供了存储空间地理数据的支持，使PostgreSQL成为了一个空间数据库，能够进行空间数据管理、数量测量与几何拓扑分析。在功能上，和MYSQL对比，PostGIS具有下列优势：

O2O业务场景中的LBS业务使用PostgreSQL + PostGIS有无法比拟的优势。
3)可以快速构建REST API
PostgREST 可以方便的为任何 PostgreSQL 数据库提供完全的 RESTful API 服务。
4)支持树状结构
支持R-trees这样可扩展的索引类型，可以更方便地处理一些特殊数据。MySQL 处理树状的设计会很复杂, 而且需要写很多代码, 而 PostgreSQL 可以高效处理树结构。
5)有极其强悍的 SQL 编程能力
支持递归，有非常丰富的统计函数和统计语法支持。
MySQL：支持 CREATE PROCEDURE 和 CREATE FUNCTION 语句。存储过程可以用 SQL 和 C++ 编写。用户定义函数可以用 SQL、C 和 C++ 编写。
PostgreSQL：没有单独的存储过程，都是通过函数实现的。用户定义函数可以用 PL/pgSQL(专用的过程语言)、PL/Tcl、PL/Perl、PL/Python 、SQL 和 C 编写。
6)外部数据源支持
可以把 70 种外部数据源 (包括 Mysql, Oracle, CSV, hadoop …) 当成自己数据库中的表来查询。Postgres有一个针对这一难题的解决方案：一个名为“外部数据封装器(Foreign Data Wrapper，FDW)”的特性。该特性最初由PostgreSQL社区领袖Dave Page四年前根据SQL标准SQL/MED(SQL Management of External Data)开发。FDW提供了一个SQL接口，用于访问远程数据存储中的远程大数据对象，使DBA可以整合来自不相关数据源的数据，将它们存入Postgres数据库中的一个公共模型。这样，DBA就可以访问和操作其它系统管理的数据，就像在本地Postgres表中一样。例如，使用FDW for MongoDB，数据库管理员可以查询来自文档数据库的数据，并使用SQL将它与来自本地Postgres表的数据相关联。借助这种方法，用户可以将数据作为行、列或JSON文档进行查看、排序和分组。他们甚至可以直接从Postgres向源文档数据库写入(插入、更细或删除)数据，就像一个一体的无缝部署。也可以对Hadoop集群或MySQL部署做同样的事。FDW使Postgres可以充当企业的中央联合数据库或“Hub”。
7)没有字符串长度限制
一般关系型数据库的字符串有限定长度8k左右，无限长 TEXT 类型的功能受限，只能作为外部大数据访问。而PostgreSQL的 TEXT 类型可以直接访问，SQL语法内置正则表达式，可以索引，还可以全文检索，或使用xml xpath。MySQL 的各种text字段有不同的限制，要手动区分 small text, middle text, large text… PostgreSQL 没有这个限制，text 能支持各种大小。
8)支持图结构数据存储
没有具体使用过，具体可以自己搜索下。参考链接：https://mp.weixin.qq.com/s/cjor82wgDu5gzDvTYpLDWw
9)支持窗口函数
窗口函数提供跨行相关的当前查询行集执行计算的能力。仅当调用跟着OVER子句的聚集函数，作为窗口函数;否则它们作为常规的聚合函数。窗口也是一种分组，但和 group by 的分组不同。窗口，可以提供分组之外，还可以执行对每个窗口进行计算。可以相像成是group by 后，然后对每个分组进行计算，而不像Group by ，只是单纯地分组。MySQL 不支持 OVER 子句, 而PostgreSQL支持。OVER 子句能简单的解决 “每组取 top 5” 的这类问题。MySQL支持的SQL语法(ANSI SQL标准)的很小一部分。不支持递归查询、通用表表达式(Oracle的with 语句)或者窗口函数(分析函数)。
10)对索引的支持更强
PostgreSQL 的可以使用函数和条件索引，这使得PostgreSQL数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。对于索引类型：
MySQL：取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。
PostgreSQL：支持 B-树、哈希、R-树和 Gist 索引。
InnoDB的表和索引都是按相同的方式存储。也就是说表都是索引组织表。这一般要求主键不能太长而且插入时的主键最好是按顺序递增，否则对性能有很大影响。PostgreSQL不存在这个问题。
索引类型方面，MySQL取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。PostgreSQL支持 B-树、哈希、R-树和 Gist 索引。
11)集群支持更好
Mysql Cluster可能与你的想象有较大差异。开源的cluster软件较少。复制(Replication)功能是异步的并且有很大的局限性。例如，它是单线程的(single-threaded)，因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master。
PostgreSQL有丰富的开源cluster软件支持。plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。
另外，PostgreSQL的主备复制属于物理复制，相对于MySQL基于binlog的逻辑复制，数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小。对于WEB应用来说，复制的特性很重要，mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。还有mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制，pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。
12)事务隔离做的更好
MySQL 的事务隔离级别 repeatable read 并不能阻止常见的并发更新, 得加锁才可以, 但悲观锁会影响性能, 手动实现乐观锁又复杂. 而 PostgreSQL 的列里有隐藏的乐观锁 version 字段, 默认的 repeatable read 级别就能保证并发更新的正确性, 并且又有乐观锁的性能。
13)对于字符支持更好一些
MySQL 里需要 utf8mb4 才能显示 emoji 的坑, PostgreSQL 没这个坑。
14)对表连接支持较完整
对表连接支持较完整，MySQL只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join)。PostgreSQL都支持。
15)存储方式支持更大的数据量
PostgreSQL主表采用堆表存放，MySQL采用索引组织表，能够支持比MySQL更大的数据量。
16)时间精度更高
MySQL对于时间、日期、间隔等时间类型没有秒以下级别的存储类型，而PostgreSQL可以精确到秒以下。
17)优化器的功能较完整
MySQL对复杂查询的处理较弱，查询优化器不够成熟，explain看执行计划的结果简单。性能优化工具与度量信息不足。
PostgreSQL很强大的查询优化器，支持很复杂的查询处理。explain返回丰富的信息。提供了一些性能视图，可以方便的看到发生在一个表和索引上的select、delete、update、insert统计信息，也可以看到cache命中率。网上有一个开源的pgstatspack工具。
18)序列支持更好
MySQL 不支持多个表从同一个序列中取 id, 而 PostgreSQL 可以。
19)对子查询支持更好
对子查询的支持。虽然在很多情况下在SQL语句中使用子查询效率低下，而且绝大多数情况下可以使用带条件的多表连接来替代子查询，但是子查询的存在在很多时候仍然不可避免。而且使用子查询的SQL语句与使用带条件的多表连接相比具有更高的程序可读性。几乎任何数据库的子查询 (subquery) 性能都比 MySQL 好。
20)增加列更加简单
MySQL表增加列，基本上是重建表和索引，会花很长时间。PostgreSQL表增加列，只是在数据字典中增加表定义，不会重建表.
MySQL相对于PostgreSQL的优势
1)MySQL比PostgreSQL更流行
流行对于一个商业软件来说，也是一个很重要的指标，流行意味着更多的用户，意味着经受了更多的考验，意味着更好的商业支持、意味着更多、更完善的文档资料。易用，很容易安装。第三方工具，包括可视化工具，让用户能够很容易入门。
2)回滚实现更优
innodb的基于回滚段实现的MVCC机制，相对PG新老数据一起存放的基于XID的MVCC机制，是占优的。新老数据一起存放，需要定时触发VACUUM，会带来多余的IO和数据库对象加锁开销，引起数据库整体的并发能力下降。而且VACUUM清理不及时，还可能会引发数据膨胀。
3)在Windows上运行更可靠
与PostgreSQL相比，MySQL更适宜在Windows环境下运行。MySQL作为一个本地的Windows应用程序运行(在 NT/Win2000/WinXP下，是一个服务)，而PostgreSQL是运行在Cygwin模拟环境下。PostgreSQL在Windows下运行没有MySQL稳定，应该是可以想象的。
4)线程模式相比进程模式的优势
MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。
进程模式对多CPU利用率比较高。进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。
线程模式对资源消耗比较少。所以MySQL能支持远比PostgreSQL多的更多的连接。但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。
5)权限设置上更加完善
MySQL在权限系统上比PostgreSQL某些方面更为完善。PostgreSQL只支持对于每一个用户在一个数据库上或一个数据表上的 INSERT、SELECT和UPDATE/DELETE的授权，而MySQL允许你定义一整套的不同的数据级、表级和列级的权限。对于列级的权限， PostgreSQL可以通过建立视图，并确定视图的权限来弥补。MySQL还允许你指定基于主机的权限，这对于目前的PostgreSQL是无法实现的，但是在很多时候，这是有用的。
6)存储引擎插件化机制
MySQL的存储引擎插件化机制，使得它的应用场景更加广泛，比如除了innodb适合事务处理场景外，myisam适合静态数据的查询场景。
7)适应24/7运行
MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。
8)更加试用于简单的场景
PostgreSQL只支持堆表，不支持索引组织表，Innodb只支持索引组织表。
索引组织表的优势：表内的数据就是按索引的方式组织，数据是有序的，如果数据都是按主键来访问，那么访问数据比较快。而堆表，按主键访问数据时，是需要先按主键索引找到数据的物理位置。
索引组织表的劣势：索引组织表中上再加其它的索引时，其它的索引记录的数据位置不再是物理位置，而是主键值，所以对于索引组织表来说，主键的值不能太大，否则占用的空间比较大。
对于索引组织表来说，如果每次在中间插入数据，可能会导致索引分裂，索引分裂会大大降低插入的性能。所以对于使用innodb来说，我们一般最好让主键是一个无意义的序列，这样插入每次都发生在最后，以避免这个问题。
由于索引组织表是按一个索引树，一般它访问数据块必须按数据块之间的关系进行访问，而不是按物理块的访问数据的，所以当做全表扫描时要比堆表慢很多，这可能在OLTP中不明显，但在数据仓库的应用中可能是一个问题。
总结
MySQL从一开始就没有打算做所有事情，因而它在功能方面有一定的局限性，并不能满足一些先进应用程序的要求。MySQL对某些功能(例如引用、事务、审计等)的实现方式使得它与其他的关系型数据库相比缺少了一些可靠性。对于简单繁重的读取操作，使用PostgreSQL可能有点小题大做，同时性能也比MySQL这样的同类产品要差。除非你需要绝对的数据完整性，ACID遵从性或者设计复杂，否则PostgreSQL对于简单的场景而言有点多余。
如何你确定只在MySQL和PostgreSQL中进行选择，以下规则总是有效的：
如果你的操作系统是Windows，你应该使用MySQL。
当绝对需要可靠性和数据完整性的时候，PostgreSQL是更好的选择。
如果需要数据库执行定制程序，那么可扩展的PostgreSQL是更好的选择。
你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。
如果你对数据库并不了十分了解，甚至不知道事务、存储过程等究竟是什么，你应该使用MySQL。

㈢ php调用微信用户信息接口昵称里面的emoji表情怎么存储到mysql中

emoji表情 是四字节的需要utf-8mb4来存储，mysql5.6以上才支持utf-8mb4

㈣ php调用微信用户信息接口昵称里面的emoji表情怎么存储到mysql中

经过测试虽然utf8mb4能够将数据存储到数据库中，但是还是有问题的：如果微信昵称前后面都有表情，中间有文字的时候，数据库中只能将前面的表情保存，后面的表情变成了空格，经过几番周折还是使用了utf8来保存下图蓝色条选中的那样字符串来保存，在前端对字符串进行去"处理，保证用户的昵称不被破坏

㈤ 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 个字符。

㈥ 求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 }

㈦ 怎样查看mysql自定义数据库的编码字符集

分不同的类型，可按以下三种方式查询：

一、查看MySQL数据库服务器和数据库MySQL字符集。

命令：

mysql>showvariableslike'%char%';

㈧ php存入emoji表情出现乱码，数据库已经改为utf8mb4编码了依然乱码

你插入数据的时候写的insert中字段数据的编码不对。你要转换成相应的字符编码才可以的。
<?php
header("Content-type:text/html;charset=utf8");
//你的代码
//也可以用notepad++将文件格式改为UTF8
?>

插入数据库需要
1
mysql_query("SET NAMES UTF8");

㈨ php 怎么处理 emoji表情

1、使用utf8mb4字符集
如果你的mysql版本>=5.5.3，你大可直接将utf8直接升级为utf8mb4字符集
这种4字节的utf8编码可完美兼容旧的3字节utf8字符集，并且可以直接存储emoji表情，是最好的解决方案
至于字节增大带来的性能损耗，我看过一些评测，几乎是可以忽略不计的
2、使用base64编码
如果你因为某些原因无法使用utf8mb4的话，你还可以使用base64来曲线救国
使用例如base64_encode之类的函数编码过后的emoji可以直接存储在utf8字节集的数据表中，取出时decode一下即可
3、干掉emoji表情
emoji表情是个麻烦的东西，即使你能存储，也不一定能完美显示。在iOS以外的平台上，例如PC或者Android。如果你需要显示emoji，就得准备一大堆emoji图片并使用第三方前端类库才行。即便如此，还是可能因为emoji图片不够全而出现无法显示的情况在大多数业务场景下，emoji也不是非要不可的。我们可以适当地考虑干掉它，节约各种成本
经过一番苦苦的google，终于找到靠谱能用的代码：

㈩ ios开发怎么处理苹果自带表情

苹果系统一直在更新优化中，其中ios内置表情也在不断新增，近日有消息曝光称ios10将加入一系列新表情，ios10默认表情有哪些?下面带来苹果ios10系统新增表情一览。 ios10默认表情有哪些?苹果ios10系统新增表情一览 iOS9.1固件刺激更多iPhone和iPad用户更新了设备系统。该固件更新提升系统稳定性与性能，让用户使用设备运行更加顺畅。在iOS9.1中苹果公司可能还进行很多工程方面改进，但是其中有一个功能备受关注：那就是新表情符号。据悉iOS10中可能会加入更多表情符号。 统一码协会(Unicode Consortium)此前已经通过了 74 个全新表情符号的审核，而这些表情符号可能很快就会出现在苹果的 iOS 10 系统之中。这些新的表情符号已经确定引入将在 2016 年中发布的 Unicode 9.0 中。而苹果公司通常都会在每年 6 月份发布新的 iOS 操作系统，从时间上来说，苹果很有可能在新的操作系统中引入这些新的表情符号。 从理论上来说，这 74 个新的表情符号已经获得统一码技术委员会审核通过，但是要真正引入到 Unicode 9.0 之中还需要经过一个步骤。 iOS 10 的开发者预览版有望在今年 6 月份发布，而正式上线时间应该是在今年的 9 或者 10 月份，届时也是苹果新款智能手机上市的时间。也就是说要将这些新的表情符号引入 iOS 10 之中，苹果还有很多时间来做准备。 如图就是这些新表情符号的一部分，不知道你是否喜欢。当然目前我们也无法完全确定这 74 个新的表情会全部出现在 iOS 10 和 iPhone 上。但是iOS 9.1 中增加了某些新的表情符号后，用户当中还是因为这些新的表情符号而产生了一阵不小的讨论，从这一点来说苹果或许很有可能会考虑在 iOS 10 中丰富表情符号。 之前有消息称苹果已经开始对 iOS 10 系统进行测试，该系统会在今年 6 月时的 WWDC 开发者大会上亮相，随后发给开发者测试，真正面向用户的时候估计要等到 iPhone 7 发布的时候了。 虽然 iOS 9 发布的时候依旧保持了对老设备的支持，但这不代表接下来苹果的系统都会支持老设备。消息中称，iOS 10 对运行内存的要求会在512MB 以上，然而像 iPhone 4s 和 iPad 2 这样的大龄朋友恐怕就要被淘汰掉了。 在功能方面，iOS10也带来全面的提升。这次Siri也许能真正成为你的私人助理，帮你处理语音邮件同时化身iCloud语音信箱。3DTouch将被融入到更多应用与设置中，控制中心或将实现根据用户的喜好自行定制。对于不同音量控制开关也会进行调整，旋屏方向和缓存清理问题也会得到解决。至于全新的iOS10究竟会如何改变，让我们共同期待吧。 ios10默认表情有哪些?苹果ios10系统新增表情一览就为大家介绍到这里，更多软件教程欢迎关注。