phputf8mb4

Ⅰ thinkphp5 连访问数据库时报错utf-8编码错误

thinkphp5连访问数据库时报错utf-8编码错误，出现中文乱码的原因就是字符编码不统一，出现中文乱码需要添加如下代码。

在D:phpStudyPHPTutorialMySQL下的my.ini中的mysqld下加如下语句：

character-set-server = utf8mb4

collation-server = utf8mb4_unicode_ci

示例代码如下：

(1)phputf8mb4扩展阅读：

thinkphp5 连访问数据库时报错utf-8编码错误可能出错的地方：

1. 代码文件（判断查看文件编码的最简单的办法是：用记事本打开，然后点击“另存为”，出现的窗口下方有“编码”字样，若不是你想要的编码，改为你的编码后保存覆盖原来的文件即可）。

2. html 文件头部应加上 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> ，把 utf-8 改为你要同意的编码即可。

3. 数据库连接代码应选择对应字符编码，mySql 的选择字符编码的代码为：mysql_query("SET NAMES 'utf-8';"); 其他数据库的代码请自行查询。

4. 后台程序代码 php 需要注明字符编码，header('Content-Type:text/html。

Ⅱ MySQL为什么使用utf8mb4还会乱码，插入数据还是报错

服务器端
修改数据库配置文件/etc/my.cnf
character-set-server=utf8mb4
collation_server=utf8mb4_unicode_ci
重启MySQL（按照官方文档，这两个选项都是可以动态设置的，但是实际的经验是Server必须重启一下）
已有的表修改编码为utf8mb4
ALTER TABLE
tbl_name
CONVERT TO CHARACTER SET
charset_name；
使用下面这个语句只是修改了表的default编码
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4;
客户端
jdbc的连接字符串不支持utf8mb4，这个 这种方式 来解决的，如果服务器端设置了character_set_server=utf8mb4，则客户端会自动将传过去的utf-8视作utf8mb4。
Connector/J did not support utf8mb4 for servers 5.5.2 and newer.
Connector/J now auto-detects servers configured with character_set_server=utf8mb4 or treats the Java encoding utf-8 passed using characterEncoding=... as utf8mb4 in the SET NAMES= calls it makes when establishing the connection. (Bug #54175)
其他的client端，比如php、python需要看下client是否支持，如果不能在连接字符串中指定的话，可以在获取连接之后，执行”set names utf8mb4″来解决这个问题；
因为utf8mb4是utf8的超集，理论上即使client修改字符集为utf8mb4，也会不会对已有的utf8编码读取产生任何问题。

Ⅲ xampp-win32-1.7.4-VC6 中phpmyadmin mysql 数据库中字符集 utf8mb4是啥玩意，和utf8有啥区别谢谢

以下是官方说明，大概意思是UTF8存储每个字符最大使用3个字节，而utf8mb4存储每个字符 最大可以使用4个字节。有些UTF8无法存储的utf8mb4就可以。下面的英文可以自己再看一下
The utf8mb4 Character Set (Four-Byte UTF-8 Unicode Encoding)

The character set named utf8 uses a maximum of three bytes per character and contains only BMP characters. As of MySQL 5.5.3, the utf8mb4 character set uses a maximum of four bytes per character supports supplemental characters:

•
For a BMP character, utf8 and utf8mb4 have identical storage characteristics: same code values, same encoding, same length.
•
For a supplementary character, utf8 cannot store the character at all, while utf8mb4 requires four bytes to store it. Since utf8 cannot store the character at all, you do not have any supplementary characters in utf8 columns and you need not worry about converting characters or losing data when upgrading utf8 data from older versions of MySQL.

Ⅳ PHP怎么处理移动端提交的表情字符

需设置 mysql 的字符集为 utf8mb4
在实行sql server 向 mysql 迁移数据时，报错：
Incorrect string value: '\xF0\x9F\x98\x8A'
原因是mysql 采用的是 utf8 的字符集，而该字符集最多占用三个字节，而一些 表情 需要占用 4个字节，所以需要将 utf8 改成 utf8mb4。
原始配置为：
#mysql 5.5 新增参数
character_set_server=utf8
collation_server=utf8_bin
我将 character_set_server=utf8 改为：character_set_server=utf8mb4，重启mysql 却报错：
发生系统错误 1067 进程意外终止
但是查看错误日志，却没有显示是什么错误信息。有倒腾了一会儿，想到是不是 collation_server 也要修改成 utf8mb4_bin，测试的结果果然如此。
所以要注意在将 MySQL字符集 utf8 改为 utf8mb4 时，一定要注意 collation_server 也要同时修改！
干脆将 default-character-set=utf8mb4 也改成了算了。
最后的字符配置如下：
[mysql]
default-character-set=utf8mb4
init_connect='set names utf8mb4'
[mysqld]
character_set_server=utf8mb4
collation_server=utf8mb4_bin
修改之后，启动成功。

Ⅳ 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，终于找到靠谱能用的代码：

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

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

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

Ⅶ 登陆phpmyadmin总是出现这个问题：错误 MySql返回：#1273 - Unknown collation: 'utf8mb4_general_ci'

编码不要选择这个，utf8有很多种

Ⅷ 请教thinkphp如何使用utf8mb4

数据连接配置为
'DB_CHARSET'=> 'utf8mb4',
字段字符集 也需修改为 uf8mb4
才能正常存储

Ⅸ 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存入emoji表情出现乱码，数据库已经改为utf8mb4编码了

你插入数据的时候写的insert中字段数据的编码不对。你要转换成相应的字符编码才可以的。