确认CSV真实编码需以VS Code/Notepad++右下角标识为准，非后缀或Excel保存选项；Linux用file -i、Windows用PowerShell验证；导入向导必须手动选编码，Auto不可靠。
确认 CSV 文件真实编码，不是看后缀或Excel保存选项
乱码第一关永远在文件本身：Excel「另存为 CSV」时选了「CSV UTF-8」≠ 文件真是 UTF-8 编码。Windows 默认 Excel 导出的「CSV」实际是 GBK 或 GB18030，且无 BOM；而 VS Code / Notepad++ 右下角显示的编码，才是真实编码。用 file -i your_file.csv（Linux/macOS）或 PowerShell 中运行 Get-Content .\data.csv -Raw | Select-String -Pattern "[\u4e00-\u9fff]" 可辅助验证是否含中文——但最稳的方式仍是打开文件、看编辑器右下角标识。
导入向导里必须手动选 Encoding，Auto 不可靠
DBeaver v23.0+ 的 CSV 导入向导中，Data Format → Encoding 默认是 Auto，但它常误判 GBK 文件为 ISO-8859-1，导致预览页满屏问号。这不是数据写坏了，只是前端解析失败。解决方法很简单：
- 先用编辑器确认文件真实编码（比如是
GBK） - 在向导第二步「Data format」页，下拉菜单里**手动选
GBK或GB18030**，别依赖 Auto - 点「Preview」看中文是否清晰——这一步通过，后续导入基本不会乱
JDBC 连接 URL 缺少字符集参数，导入成功也可能存错
即使预览和导入都显示正常，入库后查出来仍是问号，大概率是 JDBC 层没传字符集。MySQL 连接 URL 必须显式带这两个参数：
?useUnicode=true&characterEncoding=UTF-8
注意：characterEncoding=UTF-8 是针对客户端连接的解码规则，不是数据库默认字符集。如果数据库表本身用的是 utf8mb4，但连接没加这个参数，JDBC 会把 UTF-8 字节流按平台默认编码（如 Windows-1252）去 decode，结果就是 。检查方式：右键连接 → Edit Connection → Connection settings → Driver properties → 看 url 值里是否含上述参数。
表字段字符集不匹配，导入后查出来还是乱码
前面三步全对，但 SELECT 出来仍是方块或问号？执行 SHOW CREATE TABLE your_table;，重点看 COLLATE 值。常见错误是表建在 latin1 或 utf8（非 utf8mb4）上。MySQL 5.7+ 推荐统一用：
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：仅改表默认字符集不够，要确保每个 VARCHAR 字段的 COLLATE 也继承了该值，否则字段级定义会覆盖表级设置。
真正容易被忽略的是「三层校验缺一不可」：文件编码、DBeaver 导入时指定的 encoding、JDBC 连接参数——三者只要有一个不一致，就可能在某个环节出问题。而问题现象（预览乱 vs 查询乱 vs 插入报错）直接对应哪一层失效，比盲目重装或换工具更省时间。
