216 lines
4.4 KiB
Markdown
216 lines
4.4 KiB
Markdown
# 用户资料乱码完整修复方案
|
||
|
||
## 问题现象
|
||
|
||
用户个人资料页面显示乱码（<EFBFBD>），包括：
|
||
- 用户名
|
||
- 真实姓名
|
||
- 其他中文字段
|
||
|
||
## 根本原因
|
||
|
||
**数据库中存储的数据本身就是乱码**，不是前端显示问题。
|
||
|
||
可能的原因：
|
||
1. 数据库字符集不是 UTF-8
|
||
2. 表字符集不是 UTF-8
|
||
3. 插入数据时使用了错误的字符编码
|
||
4. 数据导入时编码转换错误
|
||
|
||
## 完整修复步骤
|
||
|
||
### 步骤1：检查数据库字符集
|
||
|
||
```sql
|
||
-- 执行这个SQL查看当前字符集
|
||
SELECT
|
||
SCHEMA_NAME,
|
||
DEFAULT_CHARACTER_SET_NAME,
|
||
DEFAULT_COLLATION_NAME
|
||
FROM information_schema.SCHEMATA
|
||
WHERE SCHEMA_NAME = 'peidu';
|
||
|
||
-- 查看 user 表的字符集
|
||
SHOW CREATE TABLE user;
|
||
```
|
||
|
||
### 步骤2：检查用户数据
|
||
|
||
```sql
|
||
-- 查看用户数据
|
||
SELECT
|
||
id,
|
||
username,
|
||
real_name,
|
||
HEX(real_name) as real_name_hex,
|
||
phone,
|
||
role
|
||
FROM user
|
||
WHERE id IN (1, 2);
|
||
```
|
||
|
||
如果 `real_name_hex` 显示的是类似 `EFBFBD` 的值，说明数据已经损坏。
|
||
|
||
### 步骤3：修复数据库字符集
|
||
|
||
```sql
|
||
-- 1. 备份数据
|
||
CREATE TABLE user_backup_20260128 AS SELECT * FROM user;
|
||
|
||
-- 2. 修改数据库字符集
|
||
ALTER DATABASE peidu CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
|
||
|
||
-- 3. 修改表字符集
|
||
ALTER TABLE user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
|
||
```
|
||
|
||
### 步骤4：修复乱码数据
|
||
|
||
**方案A：如果知道原始数据**
|
||
|
||
```sql
|
||
-- 手动更新正确的数据
|
||
UPDATE user SET real_name = '张小明' WHERE id = 1;
|
||
UPDATE user SET real_name = '李四' WHERE id = 2;
|
||
```
|
||
|
||
**方案B：如果有备份数据**
|
||
|
||
从备份中恢复正确的数据。
|
||
|
||
**方案C：如果数据无法恢复**
|
||
|
||
让用户重新填写个人资料。
|
||
|
||
### 步骤5：验证修复
|
||
|
||
```sql
|
||
-- 查看修复后的数据
|
||
SELECT id, username, real_name, phone, role
|
||
FROM user
|
||
WHERE id IN (1, 2);
|
||
```
|
||
|
||
### 步骤6：重启后端
|
||
|
||
修改数据库后，重启后端服务：
|
||
|
||
```bash
|
||
cd peidu/backend
|
||
# 停止当前服务（Ctrl+C）
|
||
mvn spring-boot:run
|
||
```
|
||
|
||
### 步骤7：测试前端
|
||
|
||
1. 刷新小程序
|
||
2. 进入个人资料页面
|
||
3. 检查中文是否正常显示
|
||
|
||
## 快速修复脚本
|
||
|
||
如果你知道用户的正确姓名，可以直接执行：
|
||
|
||
```sql
|
||
-- 修复用户 ID=1 的数据（张小明）
|
||
UPDATE user SET
|
||
real_name = '张小明',
|
||
update_time = NOW()
|
||
WHERE id = 1;
|
||
|
||
-- 修复用户 ID=2 的数据（请替换为实际姓名）
|
||
UPDATE user SET
|
||
real_name = '实际姓名',
|
||
update_time = NOW()
|
||
WHERE id = 2;
|
||
|
||
-- 验证
|
||
SELECT id, username, real_name, phone FROM user WHERE id IN (1, 2);
|
||
```
|
||
|
||
## 预防措施
|
||
|
||
### 1. 确保数据库使用 UTF-8
|
||
|
||
在创建数据库时：
|
||
```sql
|
||
CREATE DATABASE peidu
|
||
CHARACTER SET utf8mb4
|
||
COLLATE utf8mb4_unicode_ci;
|
||
```
|
||
|
||
### 2. 确保表使用 UTF-8
|
||
|
||
在创建表时：
|
||
```sql
|
||
CREATE TABLE user (
|
||
...
|
||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
|
||
```
|
||
|
||
### 3. 确保连接使用 UTF-8
|
||
|
||
在 `application.yml` 中：
|
||
```yaml
|
||
spring:
|
||
datasource:
|
||
url: jdbc:mysql://localhost:3306/peidu?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
|
||
```
|
||
|
||
### 4. 确保前端使用 UTF-8
|
||
|
||
在前端代码中：
|
||
```javascript
|
||
// request.js
|
||
headers: {
|
||
'Content-Type': 'application/json;charset=UTF-8'
|
||
}
|
||
```
|
||
|
||
## 故障排查
|
||
|
||
### 问题1：修改字符集后仍然乱码
|
||
|
||
**原因**：数据已经损坏，修改字符集不会自动修复已损坏的数据
|
||
|
||
**解决**：手动更新数据或从备份恢复
|
||
|
||
### 问题2：新插入的数据正常，旧数据乱码
|
||
|
||
**原因**：旧数据在错误的字符集下插入
|
||
|
||
**解决**：只修复旧数据，新数据会自动正常
|
||
|
||
### 问题3：数据库显示正常，前端显示乱码
|
||
|
||
**原因**：前端编码问题
|
||
|
||
**解决**：检查前端请求头和响应头的字符编码
|
||
|
||
## 执行清单
|
||
|
||
- [ ] 检查数据库字符集
|
||
- [ ] 检查表字符集
|
||
- [ ] 检查用户数据（查看是否乱码）
|
||
- [ ] 备份数据
|
||
- [ ] 修改数据库字符集为 utf8mb4
|
||
- [ ] 修改表字符集为 utf8mb4
|
||
- [ ] 手动修复乱码数据
|
||
- [ ] 验证数据是否正确
|
||
- [ ] 重启后端服务
|
||
- [ ] 测试前端显示
|
||
|
||
## 需要你提供的信息
|
||
|
||
1. **用户ID=1的真实姓名是什么？**（从截图看是"张小明"）
|
||
2. **用户ID=2的真实姓名是什么？**
|
||
3. **是否有数据库备份？**
|
||
|
||
提供这些信息后，我可以生成准确的修复SQL脚本。
|
||
|
||
## 📅 创建时间
|
||
2026-01-28
|
||
|
||
## 👤 创建人员
|
||
Kiro AI Assistant
|