直接用PHP做网站的同学十有八九都遇到过这个鬼问题用户昵称或者评论区里存个emoji入库的时候变成一串问号“???”或者干脆报错“Incorrect string value”。特别是对接微信登录、微博同步这类第三方接口时emoji几乎成了标配十个用户里至少有两个昵称带表情。这个问题说白了就一句话——MySQL的老版本utf8字符集根本不支持四字节字符而emoji基本都是四字节。要解决它得把整个链路的字符集从“utf8”升级成“utf8mb4”。这篇就把原理、操作和踩坑点一次讲透。先说清楚这篇内容能帮你解决什么如果你正在做PHP开发遇到emoji入库变问号、json_encode之后中文变乱码、或者数据库查询报“Incorrect string value”这类错误照这篇的思路排查和配置基本都能搞定。内容涉及PHP代码连接层配置、MySQL库表字符集调整、以及常见的避坑技巧适合刚接触PHP的入门开发者也适合被这个问题折磨过但一直没时间系统梳理的中级开发者。1. 先说清楚emoji和MySQL为什么会有仇1.1 问题还原存进去是问号读出来还是问号先描述一下最常见的现场。你在本地搭了个PHP站点数据库用的是MySQL 5.7或者MariaDB建表语句大概是这样的CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, nickname varchar(255) NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8;建表时选了utf8看起来没毛病。用户从前端提交一个昵称“小明 ”后端用PDO插入$pdo new PDO($dsn, $user, $pass); $stmt $pdo-prepare(INSERT INTO user (nickname) VALUES (?)); $stmt-execute([小明 ]);结果库里存进去的不是“小明 ”而是“小明 ???”。你以为是代码有问题翻来覆去检查PHP文件编码明明也是UTF-8。其实问题不在PHP而在MySQL的utf8字符集根本不认这个emoji。还有一种情况更隐蔽插入不报错但存进去的是乱码。比如有的用户昵称带了一个“滑雪”的emoji⛷️查出来变成一堆“ðð”前端显示更是惨不忍睹。这种多半是连接层字符集没对齐或者列字符集被改成了乱七八糟的编码。1.2 根因分析三字节与四字节的差别要理解这个问题得从Unicode编码说起。Unicode给每个字符分配了一个码点code point而UTF-8是一种变长编码用1到4个字节来表示一个码点。我们日常用的ASCII字符英文字母、数字占1个字节中文汉字大部分在U0800到UFFFF之间需要3个字节而绝大多数emoji分布在U1F300到U1F9FF这个区间也就是“增补平面”需要4个字节才能表示。MySQL在5.5.3版本之前它的utf8字符集实际上是utf8mb3的别名最多只支持3个字节。也就是说MySQL原生的“utf8”天生就有残疾它根本没办法存4字节的emoji。这个问题坑了全世界无数开发者后来MySQL官方也意识到这个命名有误导性在5.5.3之后推出了真正的四字节字符集utf8mb4但为了兼容旧系统还是保留了utf8这个别名。所以你现在在MySQL里写charsetutf8实际上是还在用那个老掉牙的三字节版本。用一句话概括MySQL里的utf8不是真正的UTF-8utf8mb4才是。你如果把库表字符集改成utf8mb4就等于从“残疾版UTF-8”升级到了“完整版UTF-8”emoji自然就能存进去了。1.3 谁最容易踩这个坑根据我实际接触过的项目踩这个坑最多的场景大概有三类第一类是社交类产品用户昵称、个性签名、评论内容都需要存用户自己输入的文字。现在手机上输入法自带的emoji太丰富了用户随手就给你来一个你根本拦不住。第二类是接第三方平台的开发者微信、QQ、微博这些平台允许昵称带特殊字符尤其是微信用户的昵称用emoji的比例特别高你要是没把字符集处理好同步用户数据时直接白屏。第三类是内容管理系统比如博客的标题、文章摘要、标签有人就喜欢在标题里加个表情符号虽然不是常态但一旦遇到就够你排查半天的。这三种场景有个共同特点数据来源不可控用户输入什么你都得接得住。所以与其等到出问题时再修不如一开始就把utf8mb4作为标配。2. 从库到表一次把utf8mb4铺到全链路2.1 数据库和表的字符集修改搞清楚了原理接下来就是动手。先说数据库层面的修改。如果你还没建库建表那最简单直接在建库时指定字符集CREATE DATABASE myapp DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;建表时也明确指定CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, nickname varchar(255) NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;如果你已经上线了库表里已经有数据那就得用ALTER语句改。修改的粒度可以分三层库、表、字段。先改库ALTER DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;再改表ALTER TABLE user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;注意这个CONVERT TO它会把你表里所有varchar、text、char类型的字段都转成utf8mb4。如果你只想改某几个字段可以单独用MODIFY指定ALTER TABLE user MODIFY nickname VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;这里有个小细节varchar的字段长度上限是以字符为单位的但不同的字符集占用的字节数不一样。utf8mb4下每个字符最多占4个字节所以如果你原来有varchar(255)那它在utf8mb4下最长可能占用1020字节超出了早期MySQL版本的单行大小限制65535字节不含TEXT/BLOB。大多数情况下varchar(255)没问题但如果一个表里有很多varchar(255)字段可能触发行大小超限的问题这时候要么减小长度要么把不常用的字段改成TEXT类型。排序规则collation的选择也有讲究。utf8mb4下有几种常见的排序规则utf8mb4_general_ci、utf8mb4_unicode_ci、utf8mb4_0900_ai_ciMySQL 8.0。其中utf8mb4_unicode_ci对Unicode的排序规则支持更全面准确性更高一点utf8mb4_general_ci速度稍快但排序不够精准。MySQL 8.0的话默认的utf8mb4_0900_ai_ci是官方推荐的选择性能和准确性都不错。我个人的习惯是能用新版本就用0900_ai_ci老版本就用unicode_ci别太纠结反正日常开发中排序规则对业务的影响远没有字符集大。2.2 连接层也要同步PHP配置无效的坑很多人在这一步掉坑里了。库表和字段都改成utf8mb4了但PHP连接MySQL时的字符集还是老样子数据照样乱。这里的关键在于你的应用程序与MySQL服务器之间有一个“连接字符集”character_set_client和character_set_connection的概念。如果你用MySQL命令行工具连接可以在客户端执行SET NAMES utf8mb4;这条语句会一次性把character_set_client、character_set_connection、character_set_results都设置成utf8mb4。但在PHP里你不可能每次请求都手动执行SQL所以正确做法是在连接初始化时就指定。用PDO的话DSN里直接带charset参数$dsn mysql:host127.0.0.1;port3306;dbnamemyapp;charsetutf8mb4; $pdo new PDO($dsn, username, password);有几个老版本的PDO驱动可能不支持DSN里的charset参数这时候可以在连接后执行$pdo-exec(SET NAMES utf8mb4);用mysqli的话更简单有一个专门的方法$mysqli new mysqli(127.0.0.1, username, password, myapp); $mysqli-set_charset(utf8mb4);这里要特别提醒一下set_charset和直接执行SET NAMES的区别在于set_charset是mysqli官方提供的API它会正确地设置客户端侧的编码信息包括后续$mysqli-real_escape_string等转义函数所需的信息。所以能用API就用API别图省事写成$mysqli-query(SET NAMES utf8mb4)——虽然绝大多数情况下也能用但语义上不严谨某些特殊字符转义时可能有偏差。2.3 MySQL服务端配置与验证方法除了库表和应用连接MySQL服务端本身也有一个默认字符集的配置在my.cnf或my.ini里[mysqld] character-set-server utf8mb4 collation-server utf8mb4_unicode_ci这个配置影响的是新建数据库时的默认字符集。如果你不给数据库显式指定字符集就会用这个。所以建议在服务器初始化时就把它改掉避免后续建库时漏配。改完配置记得重启MySQL服务。验证是否生效可以登录MySQL执行SHOW VARIABLES LIKE character_set_server; SHOW VARIABLES LIKE collation_server;另外连接进去之后可以执行这条来查看当前的连接字符集SHOW VARIABLES LIKE character_set%;正常情况下你会看到这样的结果character_set_client、character_set_connection、character_set_database、character_set_results、character_set_server都是utf8mb4character_set_system是utf8这个是系统内置的不能改也没必要改。注意如果你用的是云数据库服务比如阿里云RDS、腾讯云CDB那服务端的character_set_server很多时候不能修改只能在控制台或者建库参数里指定。遇到这种情况不要硬刚服务端配置建库时显式指定utf8mb4即可应用连接层保持一致就没问题。3. PHP侧的编码处理从入口到出口堵住问题3.1 PHP文件本身编码与响应头设置说完了数据库现在说说PHP这一侧。首先得确认你的PHP源文件本身是UTF-8编码。如果你用Windows下的记事本编辑过代码保存时可能被写成带BOM的UTF-8或者更惨的话被存成GBK。带BOM的文件在PHP解析时有时候会在输出里多一个不可见字符这个小坑排查起来很折磨人。建议用VS Code、PHPStorm这类编辑器右下角会显示文件编码统一改成UTF-8无BOM。然后是HTTP响应头。如果你输出的页面编码不对哪怕数据库里存的是正确数据浏览器显示出来也是乱码。所以PHP页面里最好显式声明编码header(Content-Type: text/html; charsetutf-8);如果你前后端分离接口返回JSON那应该用header(Content-Type: application/json; charsetutf-8);还有数据库查询结果里的字符串如果发现读出来在页面上显示乱码第一件事先查响应头对不对因为PHP本身在处理字符串时是透明的不会帮你做编码转换你的字符串是什么编码输出到浏览器时就是什么编码。3.2 常用函数与emoji处理姿势对于PHP里的字符串函数有一个经典大坑strlen、substr、strpos这些函数在PHP中默认是按字节处理的。一个UTF-8编码的中文占3个字节一个emoji占4个字节。所以如果你直接对包含emoji的字符串用substr截断非常容易把emoji从中截成两半导致半个字符的乱码。正确的做法是使用mbstring扩展的函数先确保ext-mbstring已经安装。可以用php -m命令查看模块列表或者用phpinfo()查看是否有mbstring一项。// 正确按字符个数统计 $count mb_strlen($nickname, UTF-8); // 错误按字节统计emoji会占4个字节 $count strlen($nickname); // 正确按字符截断 $shortName mb_substr($nickname, 0, 10, UTF-8); // 错误可能截断出乱码 $shortName substr($nickname, 0, 10);mbstring函数有个好处它不会改变原始字符串本身。也就是说如果你只是读取一个含emoji的字符串用mb_strlen和mb_substr操作它原始数据不会损坏。但如果你要修改字符串内容建议直接依赖MySQL的utf8mb4存储PHP侧尽量做最小处理。再说一个第三方接口交互时的情况。微信开放平台的用户昵称经常带emoji你把昵称拿到手后如果用json_encode转成JSON返回给前端会发现某些emoji被转成了“\ud83d\ude00”这种格式这其实是PHP在JSON编码时把四字节的Unicode表示成了代理对surrogate pair。更麻烦的是有些场景下json_encode会把中文直接转成\uXXXX格式那其实是你的JSON_UNESCAPED_UNICODE参数没带上。想要输出好看一点可以这样做$json json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);但要注意即使加了JSON_UNESCAPED_UNICODE四字节的emoji还是会变成代理对形式因为PHP的json_encode对超出基础多语言平面BMP的字符默认就是这么处理的。这在绝大多数浏览器和前端解析器里是合法的JSON能正常显示不用过度纠结。3.3 如果需要过滤emoji正则方案与场景权衡有些业务场景比较特殊比如你做的论坛不允许用户昵称带表情或者上游数据库是Oracle且改动成本太高那你可能需要在PHP侧把emoji过滤掉。这事用正则也能做。先看一个简单方案用Unicode属性\p{So}Symbol, other来匹配常见的emoji类字符。$clean preg_replace(/\p{So}/u, , $nickname);这种做法能过滤掉大部分传统符号类emoji但不够全面。因为有些emoji并不是So属性比如一些数字加变音符号组合、国旗之类的特殊组合。更稳妥的是按码点区间正则$clean preg_replace(/[\x{1F600}-\x{1F64F}\x{1F300}-\x{1F5FF}\x{1F680}-\x{1F6FF}\x{2600}-\x{26FF}\x{2700}-\x{27BF}\x{FE00}-\x{FE0F}\x{1F900}-\x{1F9FF}]/u, , $nickname);这串正则覆盖了最常用的emoji区段但说实话随着Unicode版本迭代新的emoji越来越多很难用一个正则把所有emoji都覆盖完。所以如果只是为了防止数据库报错我建议优先做utf8mb4升级而不是做数据过滤。防得住一时防不住一世搞内容的产品允许用户带表情是大势所趋。4. 实操示例从数据库到PHP代码的一次完整检查4.1 一套可以直接抄的PDO配置这里给出一套我实际项目里在用的PDO初始化方式你拿过去可以直接用$host 127.0.0.1; $port 3306; $dbname myapp; $user myuser; $pass mypassword; $dsn sprintf(mysql:host%s;port%s;dbname%s;charsetutf8mb4, $host, $port, $dbname); $options [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES false, ]; try { $pdo new PDO($dsn, $user, $pass, $options); } catch (PDOException $e) { exit(数据库连接失败: . $e-getMessage()); }重点说明一下为什么设置PDO::ATTR_EMULATE_PREPARES false。在PDO连接MySQL时如果开启模拟预处理默认是开启的一些数据类型的处理可能让你对字符集的预期失效。关闭模拟预处理让MySQL原生处理预处理语句能减少很多和编码相关的诡异问题。当然这个选项还会影响一些LIMIT参数绑定等细节但总体来说是利大于弊的。4.2 插入与查询emoji数据的完整演示假设你的user表已经改成了utf8mb4现在来演示一个完整的插入和查询流程。插入数据$nickname 小明 ; // 用户输入带有emoji $sql INSERT INTO user (nickname) VALUES (:nickname); $stmt $pdo-prepare($sql); $stmt-execute([:nickname $nickname]); echo 插入成功新用户ID: . $pdo-lastInsertId();查询数据并输出$id 1; $sql SELECT id, nickname FROM user WHERE id :id; $stmt $pdo-prepare($sql); $stmt-execute([:id $id]); $user $stmt-fetch(); if ($user) { header(Content-Type: text/html; charsetutf-8); echo 用户昵称是 . htmlspecialchars($user[nickname], ENT_QUOTES, UTF-8); }这里用htmlspecialchars是为了防止XSS里面第三个参数传UTF-8确保它知道当前字符串是UTF-8编码。如果省略这个参数PHP老版本默认用的是ISO-8859-1或者空字符串在输出用户昵称时可能导致某些字符被错误转义。再看一个从第三方接口获取数据并存储的场景。微信接口返回的用户信息里带emoji你在PHP里拿到后直接走同样的预处理插入即可。此前有不少教程让你在插入前用base64包一层、或者用urlencode转义都是治标不治本的做法。base64后虽然能存进utf8表但查询时所有字段都要求你再做解码业务逻辑被强制侵入后患无穷。4.3 验证修改是否生效的SQL与命令改完了怎么确认真的没问题有一个简单的验证方式先在MySQL命令行里手动插入一条emoji数据。INSERT INTO user (nickname) VALUES (测试emoji: );如果你能正常执行不报错且查询时能显示出来那说明库表层面没问题。然后再通过PHP程序执行同样的插入查看页面输出是否正常。哪一步报错或出乱码就说明哪一层还没改到位。查看表结构确认字符集SHOW FULL COLUMNS FROM user;这个命令会列出每一列的全部属性包括字符集和排序规则。如果nickname这一列显示的Collation是utf8mb4_unicode_ci就说明字段级别已经改好了。查看MySQL服务端默认字符集SHOW VARIABLES LIKE character_set_database; SHOW VARIABLES LIKE collation_database;这两个变量是当前数据库的默认字符集和排序规则。如果建库时指定过utf8mb4这里就应该显示utf8mb4。4.4 一个容易忽略的“脏数据”修复问题如果你的表已经运行了很长时间以前用utf8存过中文现在直接ALTER TABLE CONVERT TO CHARACTER SET utf8mb4它会把已有的字符串按“原字符集 → 新字符集”的方式转换。正常情况下原来正确存储的中文会顺利转成utf8mb4不会出问题。但如果之前数据已经有乱码比如编码错乱后的“ðð”这种转换并不能自动修复因为它不知道那些乱码当初是哪一层弄坏的。这种情况只能把能修的数据修掉不能修的用户昵称要么清空要么重置成默认值没什么优雅的办法。所以如果你已经出现了乱码数据改字符集之前最好先备份改完后再对比检查一下数据。有的场景下乱码是可以反推修复的比如从UTF-8被错误地当成Latin1再转回UTF-8这种经典二次编码问题可以参考“UTF-8修复”的相关工具和函数但这类修复不保证100%成功建议在测试环境先实验。5. 常见问题与排查技巧实录5.1 经典错误速查表把这些年遇到的相关问题整理成一个速查表收藏一下以后遇到类似的可以直接对号入座。现象根因解决方式插入emoji报错“Incorrect string value”字段或表的字符集不是utf8mb4修改库表字段字符集为utf8mb4插入不报错但库里存的是???连接层字符集不是utf8mb4PDODSN加charsetutf8mb4或set_charset查询出来显示乱码但库里看着正常HTTP响应头编码不正确设置Content-Type为utf-8PHP文件本身加了BOM导致页面头部有空白编辑器保存成带BOM的UTF-8另存为UTF-8无BOMmysql命令行能插入PHP程序不行PHP代码里没设置连接字符集在PDO初始化时用SET NAMES utf8mb4json_encode后emoji变成\ud83d\ude00PHP JSON对四字节字符的默认转义行为接受它或者前端自行解析5.2 排查思路三层定位法遇到emoji乱码我的排查顺序基本是固定的给你分享出来参考。第一步先看数据库里存的对不对。用MySQL命令行连接手动跑一条SELECT看库里那个字段存的是什么。如果库里就是问号或乱码说明问题出在写入链路重点检查连接层字符集和字段字符集。如果库里看着正常是前端页面显示乱码说明问题出在读取链路重点检查PHP输出时的响应头和页面编码声明。第二步看连接层。执行SHOW VARIABLES LIKE character_set%确认character_set_client、character_set_connection、character_set_results都是utf8mb4。如果这三项里有别的编码说明你的连接初始化没做对。第三步看存储层。SHOW FULL COLUMNS FROM表名确认出问题的字段Collation是utf8mb4系列。如果字段还是utf8_general_ci那你之前ALTER TABLE的时候八成只改了表没改字段或者只改了一部分字段。按照这个顺序排查绝大多数情况能在十分钟内定位。5.3 容易被忽略的四个细节第一个细节连接池和常驻进程。如果你用Swoole或Workerman这类常驻内存框架MySQL连接是会复用的第一次连接时设置的字符集会一直保持下去。如果中途你改了数据库参数但连接池里的旧连接还没释放那还是旧的字符集容易造成“改了配置但没生效”的错觉。解决办法是改完配置后加个平滑重启让连接池重建。第二个细节Linux和Windows环境下PHP代码里的字符串本身没有编码概念关键在于你给出去的字符串是不是UTF-8。比如你用file_get_contents去抓取一个GBK编码的网页拿回来的字符串内部编码是GBK直接存进utf8mb4数据库显示出来就是乱码。这种时候需要先用iconv或mb_convert_encoding转一下$content file_get_contents(http://xxx.com/api); $content mb_convert_encoding($content, UTF-8, GBK);第三个细节MySQL 8.0和5.7对utf8mb4的支持程度不同。MySQL 5.7支持utf8mb4但utf8mb4的索引字段最大长度是191个字符767字节限制。如果你有unique索引的字段在5.7下用utf8mb4时字段长度不能超过191。到了MySQL 8.0这个限制放宽到3072字节varchar(255)建立unique索引就没问题了。如果你的项目还在用5.7且要为utf8mb4字段建唯一索引记得检查字段长度。第四个细节MySQL的utf8mb4有一个变体叫utf8mb4_0900_ai_ci它只能在MySQL 8.0以上使用。如果你从MySQL 5.7的导出文件导入到8.0没问题但反向从8.0导出到5.7默认排序规则utf8mb4_0900_ai_ci会不被识别导致导入失败。跨版本迁移时建议统一用utf8mb4_unicode_ci兼容性最好。5.4 一个完整案例从微信用户昵称到数据库的emoji之旅最后用微信用户登录的场景把整套流程串一遍。流程是这样的前端拿到微信的code后端调微信接口获取用户昵称“一条咸鱼 ”。后端PHP代码大致这样写$url https://api.weixin.qq.com/sns/userinfo?access_token . $accessToken . openid . $openid; $resp file_get_contents($url); $data json_decode($resp, true); $nickname $data[nickname]; // 这里可能是 一条咸鱼 如果此时你的PDO连接没配charsetutf8mb4那插入这条数据时MySQL客户端会按默认的latin1或者旧utf8来理解这个字符串存储过程就会失控结果就是库里的数据变成乱码。如果你的库字段不是utf8mb4则在写入前MySQL就拒绝了这个4字节字符直接报错或转成问号。所以给微信登录功能做开发时我建议在项目初始化阶段就固定下面三条数据库连接统一使用utf8mb4并显式声明建表语句统一用utf8mb4_unicode_ci输出JSON时统一加JSON_UNESCAPED_UNICODE。三件事都做到基本可以告别emoji乱码这个坑。结尾踩过几次坑之后的真实体会这个问题我在大概三年前第一次碰到当时也是查了一整天才搞清楚后来陆陆续续帮同事排查过几次总结了两个经验一是字符集问题不要靠“试”来解先把链路看清楚库、表、连接、输出四层对不对齐八成问题都在里面二是能改底层就不要做兼容比如能用utf8mb4就坚决不用过滤emoji的方案你能保证今天过滤了所有表情但不能保证明天Unicode又出新的字符。最后建议还在用MySQL 5.5或5.6的同学尽早把版本升上去老版本对utf8mb4的支持多少有些残缺比如5.5时代utf8mb4的索引长度限制更严格升级之后很多历史悠久的问题会自动消失。 
长河君 · 2026/9/14 4:24:15 · 阅读 1.2k PHP程序员必看：MySQL utf8mb4解决emoji存入乱码全攻略
直接用PHP做网站的同学十有八九都遇到过这个鬼问题用户昵称或者评论区里存个emoji入库的时候变成一串问号“???”或者干脆报错“Incorrect string value”。特别是对接微信登录、微博同步这类第三方接口时emoji几乎成了标配十个用户里至少有两个昵称带表情。这个问题说白了就一句话——MySQL的老版本utf8字符集根本不支持四字节字符而emoji基本都是四字节。要解决它得把整个链路的字符集从“utf8”升级成“utf8mb4”。这篇就把原理、操作和踩坑点一次讲透。先说清楚这篇内容能帮你解决什么如果你正在做PHP开发遇到emoji入库变问号、json_encode之后中文变乱码、或者数据库查询报“Incorrect string value”这类错误照这篇的思路排查和配置基本都能搞定。内容涉及PHP代码连接层配置、MySQL库表字符集调整、以及常见的避坑技巧适合刚接触PHP的入门开发者也适合被这个问题折磨过但一直没时间系统梳理的中级开发者。1. 先说清楚emoji和MySQL为什么会有仇1.1 问题还原存进去是问号读出来还是问号先描述一下最常见的现场。你在本地搭了个PHP站点数据库用的是MySQL 5.7或者MariaDB建表语句大概是这样的CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, nickname varchar(255) NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8;建表时选了utf8看起来没毛病。用户从前端提交一个昵称“小明 ”后端用PDO插入$pdo new PDO($dsn, $user, $pass); $stmt $pdo-prepare(INSERT INTO user (nickname) VALUES (?)); $stmt-execute([小明 ]);结果库里存进去的不是“小明 ”而是“小明 ???”。你以为是代码有问题翻来覆去检查PHP文件编码明明也是UTF-8。其实问题不在PHP而在MySQL的utf8字符集根本不认这个emoji。还有一种情况更隐蔽插入不报错但存进去的是乱码。比如有的用户昵称带了一个“滑雪”的emoji⛷️查出来变成一堆“ðð”前端显示更是惨不忍睹。这种多半是连接层字符集没对齐或者列字符集被改成了乱七八糟的编码。1.2 根因分析三字节与四字节的差别要理解这个问题得从Unicode编码说起。Unicode给每个字符分配了一个码点code point而UTF-8是一种变长编码用1到4个字节来表示一个码点。我们日常用的ASCII字符英文字母、数字占1个字节中文汉字大部分在U0800到UFFFF之间需要3个字节而绝大多数emoji分布在U1F300到U1F9FF这个区间也就是“增补平面”需要4个字节才能表示。MySQL在5.5.3版本之前它的utf8字符集实际上是utf8mb3的别名最多只支持3个字节。也就是说MySQL原生的“utf8”天生就有残疾它根本没办法存4字节的emoji。这个问题坑了全世界无数开发者后来MySQL官方也意识到这个命名有误导性在5.5.3之后推出了真正的四字节字符集utf8mb4但为了兼容旧系统还是保留了utf8这个别名。所以你现在在MySQL里写charsetutf8实际上是还在用那个老掉牙的三字节版本。用一句话概括MySQL里的utf8不是真正的UTF-8utf8mb4才是。你如果把库表字符集改成utf8mb4就等于从“残疾版UTF-8”升级到了“完整版UTF-8”emoji自然就能存进去了。1.3 谁最容易踩这个坑根据我实际接触过的项目踩这个坑最多的场景大概有三类第一类是社交类产品用户昵称、个性签名、评论内容都需要存用户自己输入的文字。现在手机上输入法自带的emoji太丰富了用户随手就给你来一个你根本拦不住。第二类是接第三方平台的开发者微信、QQ、微博这些平台允许昵称带特殊字符尤其是微信用户的昵称用emoji的比例特别高你要是没把字符集处理好同步用户数据时直接白屏。第三类是内容管理系统比如博客的标题、文章摘要、标签有人就喜欢在标题里加个表情符号虽然不是常态但一旦遇到就够你排查半天的。这三种场景有个共同特点数据来源不可控用户输入什么你都得接得住。所以与其等到出问题时再修不如一开始就把utf8mb4作为标配。2. 从库到表一次把utf8mb4铺到全链路2.1 数据库和表的字符集修改搞清楚了原理接下来就是动手。先说数据库层面的修改。如果你还没建库建表那最简单直接在建库时指定字符集CREATE DATABASE myapp DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;建表时也明确指定CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT, nickname varchar(255) NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci;如果你已经上线了库表里已经有数据那就得用ALTER语句改。修改的粒度可以分三层库、表、字段。先改库ALTER DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;再改表ALTER TABLE user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;注意这个CONVERT TO它会把你表里所有varchar、text、char类型的字段都转成utf8mb4。如果你只想改某几个字段可以单独用MODIFY指定ALTER TABLE user MODIFY nickname VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;这里有个小细节varchar的字段长度上限是以字符为单位的但不同的字符集占用的字节数不一样。utf8mb4下每个字符最多占4个字节所以如果你原来有varchar(255)那它在utf8mb4下最长可能占用1020字节超出了早期MySQL版本的单行大小限制65535字节不含TEXT/BLOB。大多数情况下varchar(255)没问题但如果一个表里有很多varchar(255)字段可能触发行大小超限的问题这时候要么减小长度要么把不常用的字段改成TEXT类型。排序规则collation的选择也有讲究。utf8mb4下有几种常见的排序规则utf8mb4_general_ci、utf8mb4_unicode_ci、utf8mb4_0900_ai_ciMySQL 8.0。其中utf8mb4_unicode_ci对Unicode的排序规则支持更全面准确性更高一点utf8mb4_general_ci速度稍快但排序不够精准。MySQL 8.0的话默认的utf8mb4_0900_ai_ci是官方推荐的选择性能和准确性都不错。我个人的习惯是能用新版本就用0900_ai_ci老版本就用unicode_ci别太纠结反正日常开发中排序规则对业务的影响远没有字符集大。2.2 连接层也要同步PHP配置无效的坑很多人在这一步掉坑里了。库表和字段都改成utf8mb4了但PHP连接MySQL时的字符集还是老样子数据照样乱。这里的关键在于你的应用程序与MySQL服务器之间有一个“连接字符集”character_set_client和character_set_connection的概念。如果你用MySQL命令行工具连接可以在客户端执行SET NAMES utf8mb4;这条语句会一次性把character_set_client、character_set_connection、character_set_results都设置成utf8mb4。但在PHP里你不可能每次请求都手动执行SQL所以正确做法是在连接初始化时就指定。用PDO的话DSN里直接带charset参数$dsn mysql:host127.0.0.1;port3306;dbnamemyapp;charsetutf8mb4; $pdo new PDO($dsn, username, password);有几个老版本的PDO驱动可能不支持DSN里的charset参数这时候可以在连接后执行$pdo-exec(SET NAMES utf8mb4);用mysqli的话更简单有一个专门的方法$mysqli new mysqli(127.0.0.1, username, password, myapp); $mysqli-set_charset(utf8mb4);这里要特别提醒一下set_charset和直接执行SET NAMES的区别在于set_charset是mysqli官方提供的API它会正确地设置客户端侧的编码信息包括后续$mysqli-real_escape_string等转义函数所需的信息。所以能用API就用API别图省事写成$mysqli-query(SET NAMES utf8mb4)——虽然绝大多数情况下也能用但语义上不严谨某些特殊字符转义时可能有偏差。2.3 MySQL服务端配置与验证方法除了库表和应用连接MySQL服务端本身也有一个默认字符集的配置在my.cnf或my.ini里[mysqld] character-set-server utf8mb4 collation-server utf8mb4_unicode_ci这个配置影响的是新建数据库时的默认字符集。如果你不给数据库显式指定字符集就会用这个。所以建议在服务器初始化时就把它改掉避免后续建库时漏配。改完配置记得重启MySQL服务。验证是否生效可以登录MySQL执行SHOW VARIABLES LIKE character_set_server; SHOW VARIABLES LIKE collation_server;另外连接进去之后可以执行这条来查看当前的连接字符集SHOW VARIABLES LIKE character_set%;正常情况下你会看到这样的结果character_set_client、character_set_connection、character_set_database、character_set_results、character_set_server都是utf8mb4character_set_system是utf8这个是系统内置的不能改也没必要改。注意如果你用的是云数据库服务比如阿里云RDS、腾讯云CDB那服务端的character_set_server很多时候不能修改只能在控制台或者建库参数里指定。遇到这种情况不要硬刚服务端配置建库时显式指定utf8mb4即可应用连接层保持一致就没问题。3. PHP侧的编码处理从入口到出口堵住问题3.1 PHP文件本身编码与响应头设置说完了数据库现在说说PHP这一侧。首先得确认你的PHP源文件本身是UTF-8编码。如果你用Windows下的记事本编辑过代码保存时可能被写成带BOM的UTF-8或者更惨的话被存成GBK。带BOM的文件在PHP解析时有时候会在输出里多一个不可见字符这个小坑排查起来很折磨人。建议用VS Code、PHPStorm这类编辑器右下角会显示文件编码统一改成UTF-8无BOM。然后是HTTP响应头。如果你输出的页面编码不对哪怕数据库里存的是正确数据浏览器显示出来也是乱码。所以PHP页面里最好显式声明编码header(Content-Type: text/html; charsetutf-8);如果你前后端分离接口返回JSON那应该用header(Content-Type: application/json; charsetutf-8);还有数据库查询结果里的字符串如果发现读出来在页面上显示乱码第一件事先查响应头对不对因为PHP本身在处理字符串时是透明的不会帮你做编码转换你的字符串是什么编码输出到浏览器时就是什么编码。3.2 常用函数与emoji处理姿势对于PHP里的字符串函数有一个经典大坑strlen、substr、strpos这些函数在PHP中默认是按字节处理的。一个UTF-8编码的中文占3个字节一个emoji占4个字节。所以如果你直接对包含emoji的字符串用substr截断非常容易把emoji从中截成两半导致半个字符的乱码。正确的做法是使用mbstring扩展的函数先确保ext-mbstring已经安装。可以用php -m命令查看模块列表或者用phpinfo()查看是否有mbstring一项。// 正确按字符个数统计 $count mb_strlen($nickname, UTF-8); // 错误按字节统计emoji会占4个字节 $count strlen($nickname); // 正确按字符截断 $shortName mb_substr($nickname, 0, 10, UTF-8); // 错误可能截断出乱码 $shortName substr($nickname, 0, 10);mbstring函数有个好处它不会改变原始字符串本身。也就是说如果你只是读取一个含emoji的字符串用mb_strlen和mb_substr操作它原始数据不会损坏。但如果你要修改字符串内容建议直接依赖MySQL的utf8mb4存储PHP侧尽量做最小处理。再说一个第三方接口交互时的情况。微信开放平台的用户昵称经常带emoji你把昵称拿到手后如果用json_encode转成JSON返回给前端会发现某些emoji被转成了“\ud83d\ude00”这种格式这其实是PHP在JSON编码时把四字节的Unicode表示成了代理对surrogate pair。更麻烦的是有些场景下json_encode会把中文直接转成\uXXXX格式那其实是你的JSON_UNESCAPED_UNICODE参数没带上。想要输出好看一点可以这样做$json json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);但要注意即使加了JSON_UNESCAPED_UNICODE四字节的emoji还是会变成代理对形式因为PHP的json_encode对超出基础多语言平面BMP的字符默认就是这么处理的。这在绝大多数浏览器和前端解析器里是合法的JSON能正常显示不用过度纠结。3.3 如果需要过滤emoji正则方案与场景权衡有些业务场景比较特殊比如你做的论坛不允许用户昵称带表情或者上游数据库是Oracle且改动成本太高那你可能需要在PHP侧把emoji过滤掉。这事用正则也能做。先看一个简单方案用Unicode属性\p{So}Symbol, other来匹配常见的emoji类字符。$clean preg_replace(/\p{So}/u, , $nickname);这种做法能过滤掉大部分传统符号类emoji但不够全面。因为有些emoji并不是So属性比如一些数字加变音符号组合、国旗之类的特殊组合。更稳妥的是按码点区间正则$clean preg_replace(/[\x{1F600}-\x{1F64F}\x{1F300}-\x{1F5FF}\x{1F680}-\x{1F6FF}\x{2600}-\x{26FF}\x{2700}-\x{27BF}\x{FE00}-\x{FE0F}\x{1F900}-\x{1F9FF}]/u, , $nickname);这串正则覆盖了最常用的emoji区段但说实话随着Unicode版本迭代新的emoji越来越多很难用一个正则把所有emoji都覆盖完。所以如果只是为了防止数据库报错我建议优先做utf8mb4升级而不是做数据过滤。防得住一时防不住一世搞内容的产品允许用户带表情是大势所趋。4. 实操示例从数据库到PHP代码的一次完整检查4.1 一套可以直接抄的PDO配置这里给出一套我实际项目里在用的PDO初始化方式你拿过去可以直接用$host 127.0.0.1; $port 3306; $dbname myapp; $user myuser; $pass mypassword; $dsn sprintf(mysql:host%s;port%s;dbname%s;charsetutf8mb4, $host, $port, $dbname); $options [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES false, ]; try { $pdo new PDO($dsn, $user, $pass, $options); } catch (PDOException $e) { exit(数据库连接失败: . $e-getMessage()); }重点说明一下为什么设置PDO::ATTR_EMULATE_PREPARES false。在PDO连接MySQL时如果开启模拟预处理默认是开启的一些数据类型的处理可能让你对字符集的预期失效。关闭模拟预处理让MySQL原生处理预处理语句能减少很多和编码相关的诡异问题。当然这个选项还会影响一些LIMIT参数绑定等细节但总体来说是利大于弊的。4.2 插入与查询emoji数据的完整演示假设你的user表已经改成了utf8mb4现在来演示一个完整的插入和查询流程。插入数据$nickname 小明 ; // 用户输入带有emoji $sql INSERT INTO user (nickname) VALUES (:nickname); $stmt $pdo-prepare($sql); $stmt-execute([:nickname $nickname]); echo 插入成功新用户ID: . $pdo-lastInsertId();查询数据并输出$id 1; $sql SELECT id, nickname FROM user WHERE id :id; $stmt $pdo-prepare($sql); $stmt-execute([:id $id]); $user $stmt-fetch(); if ($user) { header(Content-Type: text/html; charsetutf-8); echo 用户昵称是 . htmlspecialchars($user[nickname], ENT_QUOTES, UTF-8); }这里用htmlspecialchars是为了防止XSS里面第三个参数传UTF-8确保它知道当前字符串是UTF-8编码。如果省略这个参数PHP老版本默认用的是ISO-8859-1或者空字符串在输出用户昵称时可能导致某些字符被错误转义。再看一个从第三方接口获取数据并存储的场景。微信接口返回的用户信息里带emoji你在PHP里拿到后直接走同样的预处理插入即可。此前有不少教程让你在插入前用base64包一层、或者用urlencode转义都是治标不治本的做法。base64后虽然能存进utf8表但查询时所有字段都要求你再做解码业务逻辑被强制侵入后患无穷。4.3 验证修改是否生效的SQL与命令改完了怎么确认真的没问题有一个简单的验证方式先在MySQL命令行里手动插入一条emoji数据。INSERT INTO user (nickname) VALUES (测试emoji: );如果你能正常执行不报错且查询时能显示出来那说明库表层面没问题。然后再通过PHP程序执行同样的插入查看页面输出是否正常。哪一步报错或出乱码就说明哪一层还没改到位。查看表结构确认字符集SHOW FULL COLUMNS FROM user;这个命令会列出每一列的全部属性包括字符集和排序规则。如果nickname这一列显示的Collation是utf8mb4_unicode_ci就说明字段级别已经改好了。查看MySQL服务端默认字符集SHOW VARIABLES LIKE character_set_database; SHOW VARIABLES LIKE collation_database;这两个变量是当前数据库的默认字符集和排序规则。如果建库时指定过utf8mb4这里就应该显示utf8mb4。4.4 一个容易忽略的“脏数据”修复问题如果你的表已经运行了很长时间以前用utf8存过中文现在直接ALTER TABLE CONVERT TO CHARACTER SET utf8mb4它会把已有的字符串按“原字符集 → 新字符集”的方式转换。正常情况下原来正确存储的中文会顺利转成utf8mb4不会出问题。但如果之前数据已经有乱码比如编码错乱后的“ðð”这种转换并不能自动修复因为它不知道那些乱码当初是哪一层弄坏的。这种情况只能把能修的数据修掉不能修的用户昵称要么清空要么重置成默认值没什么优雅的办法。所以如果你已经出现了乱码数据改字符集之前最好先备份改完后再对比检查一下数据。有的场景下乱码是可以反推修复的比如从UTF-8被错误地当成Latin1再转回UTF-8这种经典二次编码问题可以参考“UTF-8修复”的相关工具和函数但这类修复不保证100%成功建议在测试环境先实验。5. 常见问题与排查技巧实录5.1 经典错误速查表把这些年遇到的相关问题整理成一个速查表收藏一下以后遇到类似的可以直接对号入座。现象根因解决方式插入emoji报错“Incorrect string value”字段或表的字符集不是utf8mb4修改库表字段字符集为utf8mb4插入不报错但库里存的是???连接层字符集不是utf8mb4PDODSN加charsetutf8mb4或set_charset查询出来显示乱码但库里看着正常HTTP响应头编码不正确设置Content-Type为utf-8PHP文件本身加了BOM导致页面头部有空白编辑器保存成带BOM的UTF-8另存为UTF-8无BOMmysql命令行能插入PHP程序不行PHP代码里没设置连接字符集在PDO初始化时用SET NAMES utf8mb4json_encode后emoji变成\ud83d\ude00PHP JSON对四字节字符的默认转义行为接受它或者前端自行解析5.2 排查思路三层定位法遇到emoji乱码我的排查顺序基本是固定的给你分享出来参考。第一步先看数据库里存的对不对。用MySQL命令行连接手动跑一条SELECT看库里那个字段存的是什么。如果库里就是问号或乱码说明问题出在写入链路重点检查连接层字符集和字段字符集。如果库里看着正常是前端页面显示乱码说明问题出在读取链路重点检查PHP输出时的响应头和页面编码声明。第二步看连接层。执行SHOW VARIABLES LIKE character_set%确认character_set_client、character_set_connection、character_set_results都是utf8mb4。如果这三项里有别的编码说明你的连接初始化没做对。第三步看存储层。SHOW FULL COLUMNS FROM表名确认出问题的字段Collation是utf8mb4系列。如果字段还是utf8_general_ci那你之前ALTER TABLE的时候八成只改了表没改字段或者只改了一部分字段。按照这个顺序排查绝大多数情况能在十分钟内定位。5.3 容易被忽略的四个细节第一个细节连接池和常驻进程。如果你用Swoole或Workerman这类常驻内存框架MySQL连接是会复用的第一次连接时设置的字符集会一直保持下去。如果中途你改了数据库参数但连接池里的旧连接还没释放那还是旧的字符集容易造成“改了配置但没生效”的错觉。解决办法是改完配置后加个平滑重启让连接池重建。第二个细节Linux和Windows环境下PHP代码里的字符串本身没有编码概念关键在于你给出去的字符串是不是UTF-8。比如你用file_get_contents去抓取一个GBK编码的网页拿回来的字符串内部编码是GBK直接存进utf8mb4数据库显示出来就是乱码。这种时候需要先用iconv或mb_convert_encoding转一下$content file_get_contents(http://xxx.com/api); $content mb_convert_encoding($content, UTF-8, GBK);第三个细节MySQL 8.0和5.7对utf8mb4的支持程度不同。MySQL 5.7支持utf8mb4但utf8mb4的索引字段最大长度是191个字符767字节限制。如果你有unique索引的字段在5.7下用utf8mb4时字段长度不能超过191。到了MySQL 8.0这个限制放宽到3072字节varchar(255)建立unique索引就没问题了。如果你的项目还在用5.7且要为utf8mb4字段建唯一索引记得检查字段长度。第四个细节MySQL的utf8mb4有一个变体叫utf8mb4_0900_ai_ci它只能在MySQL 8.0以上使用。如果你从MySQL 5.7的导出文件导入到8.0没问题但反向从8.0导出到5.7默认排序规则utf8mb4_0900_ai_ci会不被识别导致导入失败。跨版本迁移时建议统一用utf8mb4_unicode_ci兼容性最好。5.4 一个完整案例从微信用户昵称到数据库的emoji之旅最后用微信用户登录的场景把整套流程串一遍。流程是这样的前端拿到微信的code后端调微信接口获取用户昵称“一条咸鱼 ”。后端PHP代码大致这样写$url https://api.weixin.qq.com/sns/userinfo?access_token . $accessToken . openid . $openid; $resp file_get_contents($url); $data json_decode($resp, true); $nickname $data[nickname]; // 这里可能是 一条咸鱼 如果此时你的PDO连接没配charsetutf8mb4那插入这条数据时MySQL客户端会按默认的latin1或者旧utf8来理解这个字符串存储过程就会失控结果就是库里的数据变成乱码。如果你的库字段不是utf8mb4则在写入前MySQL就拒绝了这个4字节字符直接报错或转成问号。所以给微信登录功能做开发时我建议在项目初始化阶段就固定下面三条数据库连接统一使用utf8mb4并显式声明建表语句统一用utf8mb4_unicode_ci输出JSON时统一加JSON_UNESCAPED_UNICODE。三件事都做到基本可以告别emoji乱码这个坑。结尾踩过几次坑之后的真实体会这个问题我在大概三年前第一次碰到当时也是查了一整天才搞清楚后来陆陆续续帮同事排查过几次总结了两个经验一是字符集问题不要靠“试”来解先把链路看清楚库、表、连接、输出四层对不对齐八成问题都在里面二是能改底层就不要做兼容比如能用utf8mb4就坚决不用过滤emoji的方案你能保证今天过滤了所有表情但不能保证明天Unicode又出新的字符。最后建议还在用MySQL 5.5或5.6的同学尽早把版本升上去老版本对utf8mb4的支持多少有些残缺比如5.5时代utf8mb4的索引长度限制更严格升级之后很多历史悠久的问题会自动消失。