口碑好的家装前十强公司网站优化方案

记录一下趴~

今天遇到一个问题在解析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 字节