申请域网站市场调研方法
记录一下趴~
今天遇到一个问题在解析doc文件后想把拆解后的内容 存到mysql数据库表的一个字段当中，但是死活是存不进去报错
上传文件失败: (pymysql.err.DataError) (1366, "Incorrect string value: '\\xF0\\x9D\\x91\\xA0\\xF0\\x9D...' for column 'slice' at row 1") [SQL: INSERT INTO knowledge_chunk_info (file_id, status, slice, word_num, create_time, create_by, vectordb_id, del_flag, dify_chunk_id, title_id, question) VALUES (%(file_id)s, %(status)s, %(slice)s, %(word_num)s, %(create_time)s, %(create_by)s, %(vectordb_id)s, %(del_flag)s, %(dify_chunk_id)s, %(title_id)s, %(question)s)]这一看就猜到是编码的问题
但是为啥呢？
首先排查我的表的字符编码发现字符编码是utf8 utf8_general_ci的平时也没太注意过这些后来去了解了一下两者的区别
1. utf8 vs utf8mb4
utf8
- 实际是 utf8mb3，最多支持 3 字节字符
- 每个字符最多占用 3 个字节
- 不支持 emoji 表情和部分特殊字符
- 存储空间相对较小
- 历史遗留原因导致的不完整 UTF-8 实现
utf8mb4
- 完整的 UTF-8 实现，支持 4 字节字符
- 向下兼容 utf8
- 支持 emoji、特殊符号等
- 存储空间相对较大
- 是 MySQL 5.5.3 之后版本的推荐字符集
2. 排序规则(Collation)对比
2.1 utf8mb4_general_ci
- 排序和比较速度更快
- 不区分字母大小写
- 内存占用较少
- 排序规则相对简单
- 适合一般应用场景
2.2 utf8mb4_unicode_ci
- Unicode 标准的排序规则
- 更准确的多语言排序
- 区分音调符号
- 资源消耗相对较大
- 适合多语言环境
2.3 utf8mb4_bin
- 基于二进制比较
- 区分大小写
- 最快的比较速度
- 适合需要精确比较的场景
3. 实际应用建议
3.1 选择字符集
- 新项目推荐使用 utf8mb4
- 需要兼容老系统时可以使用 utf8
- 存储 emoji 必须使用 utf8mb4
3.2 选择排序规则
- 一般应用选择 utf8mb4_general_ci
- 多语言应用选择 utf8mb4_unicode_ci
- 对大小写敏感的应用选择 utf8mb4_bin
3.3 性能影响
- 索引长度限制
- 存储空间大小
- 排序和比较性能
综上所述
- utf8mb4 是 utf8 的超集
- utf8 能表示的所有字符，utf8mb4 都能表示
- utf8mb4 还能额外表示 4 字节的字符
- 编码范围对比：- utf8：每个字符 1-3 字节
- utf8mb4：每个字符 1-4 字节