问号乱码几乎全是字符集错配导致的，需同步校准文件编码、navicat导入设置、目标表字段字符集及连接层初始化四方面：先确认源文件真实编码（utf-8无bom/utf-8 with bom/gbk），再在navicat导入向导中手动选对character set；检查并显式修改表字段为character set utf8mb4；连接设置中勾选utf8mb4并执行set names utf8mb4，断开重连后验证三变量全为utf8mb4。
问号乱码（???）几乎全是字符集错配导致的，不是数据损坏，也不是 navicat 故障——只要三处编码对齐，99% 的情况能当场修复。
确认 Excel / CSV / TXT 文件的真实编码
Navicat 不会自动识别文件编码，它只按你选的选项去硬解字节。选错就必然出 ???。
- 用 VS Code 或 Notepad++ 打开源文件（如果是
.xlsx，先「另存为」.csv再查），看右下角状态栏显示的编码名称 - 重点区分：
UTF-8（无 BOM）、UTF-8 with BOM、GBK—— 这三者在 Navicat 导入向导里是不同选项，不能混用 - Linux/macOS 下可用
file -i your_file.csv辅助验证；Windows 命令行的chcp无效，别依赖 - Excel 在 Windows 下「另存为 CSV」默认输出
GBK，不是 UTF-8；WPS 同理
Navicat 导入向导中必须手动选对 Character Set
导入第二步（点击“下一步”后）的 Character Set 下拉框，绝不能留空或信 Auto。
- 文件是
UTF-8 with BOM→ 选UTF-8（Navicat 15+ 会自动识别并跳过 BOM） - 文件是纯
UTF-8（无 BOM）→ 也选UTF-8 - 文件是
GBK（常见于 Excel/WPS 导出、老系统生成）→ 必须选GBK，选UTF-8必然全变??? -
Auto模式只扫描前几百字节，中文文本极易误判为ISO-8859-1或GBK，等于放弃控制权
检查目标表字段是否真支持 utf8mb4
即使导入过程预览正常、没报错，最终 SELECT 出来还是 ???，大概率是字段本身不认 utf8mb4 字节。
- 运行
SHOW CREATE TABLE `your_table`;，逐行检查每个中文字段定义末尾是否有CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 若字段定义里没写，它继承表级设置；若表也没显式声明，则继承库级甚至 server 级默认值——而老库常是
latin1或utf8（即utf8mb3） -
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;只改表默认值，已有字段的元数据可能仍残留旧字符集，稳妥做法是显式修改字段：ALTER TABLE your_table MODIFY COLUMN name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
连接层初始化必须强制为 utf8mb4
导入完成后立刻查表仍是 ???？八成是 Navicat 连接初始化没生效，服务端仍用 latin1 解析返回结果。
- 右键对应连接 →「编辑连接」→「高级」→ 勾选
使用 MySQL 字符集→ 下拉选utf8mb4（不是utf8） - 同时勾选
使用初始化命令，填入：SET NAMES utf8mb4; - 改完必须断开重连，再执行：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;—— 三个值必须全为utf8mb4 - 注意：同步、SQL 文件导入、JSON 导入等独立功能，都各自走一套连接逻辑，需单独配置，不继承主连接设置
最易被忽略的是字段级实际字符集 —— SHOW VARIABLES LIKE 'character_set_server' 返回 utf8mb4 并不代表你的 name 字段就能存「?」或 emoji，得亲眼看见建表语句里写了 CHARACTER SET utf8mb4 才算数。
