-
我建表时一直顺手写 CHARSET=utf8 自以为这就是万国通吃的 UTF-8 什么字都存得下,直到有用户把昵称改成带了个笑脸 emoji,插入直接报 Incorrect string value 整条失败、宽松模式下昵称还被从 emoji 那里齐刷刷截断,排查很久才知道 MySQL 的 utf8 根本不是完整 UTF-8 而是只支持三字节的 utf8mb3 存不下四字节 emoji 的深度复盘
我建数据库表时一直习惯性地写 CHARSET=utf8,心里笃定 utf8 就是大名鼎鼎的 UTF-8、万国码、什么语言什么字符都能存,中英日韩这么多年也确实一直好好的。直到有个用户把昵称改成带了一个笑脸 emoji,保存直接炸了:严格 sql_mode 下报 ERROR 1366 Incorrect string value 'xF0x9Fx98x80' for column…- 3
- 0
-
用户昵称带个 emoji 就插入数据库失败、报 Incorrect string value,我数据库明明设的是 utf8 字符集,我对着 MySQL 的"假 utf8"排查了大半天的复盘
做用户系统一切正常,直到有用户昵称里加了个 emoji,保存瞬间接口就报 Incorrect string value: 'xF0x9Fx98x80' for column nickname。一脸困惑:数据库字符集明明设的是 utf8,UTF-8 不是号称能编码所有字符吗怎么连个 emoji 都存不下?排查大半天才得知一个大跌眼镜的真相:MySQL 里的 utf8 根本不是真正…- 0
- 0
-
本地能读换环境就崩:Python 字符编码避坑复盘
有个 Python 脚本功能很简单:读一个文本文件处理里面的数据,我在自己的 Mac 上开发测试跑得顺顺当当处理了成千上万条都没事。可一上线到生产服务器、或换一批从别的系统导出的文件来处理,它就时不时啪一声崩掉抛出 UnicodeDecodeError: utf-8 codec can not decode byte 0xb4。明明同样的代码同样的逻辑在我这儿好好的,换个环境换个文件就解码失败。查…- 0
- 0
字符集
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×