DBeaver导入UTF-8编码CSV必须在向导“处理器属性”中显式设置encoding为UTF-8，不可依赖Auto识别，因其易将UTF-8误判为ISO-8859-1或忽略BOM导致乱码。
直接说结论：DBeaver 导入 UTF-8 编码的 CSV 文件，必须在导入向导的“处理器属性”里显式设为 UTF-8，不能依赖自动识别——它常会误判为 ISO-8859-1 或跳过 BOM 处理导致乱码。
为什么选了 UTF-8 还是乱码？
常见错误现象是：CSV 文件用 Notepad++ 确认是 UTF-8（甚至带 BOM），DBeaver 导入预览页却显示一堆问号或方块。根本原因不是 DBeaver 不支持 UTF-8，而是它默认按平台编码（如 Windows 下是 GBK）或基于文件前几个字节做启发式猜测，而 UTF-8 的纯 ASCII 部分和 ISO-8859-1 完全一致，极易误判。
实操建议：
- 用 Notepad++ 或 VS Code 打开 CSV，确认右下角明确显示
UTF-8或UTF-8-BOM；若显示ANSI或GB2312，说明实际不是 UTF-8，先转码再导入 - 导入时，在向导第二步（参数页）点右下角
处理器属性按钮，找到encoding项，手动输入或选择UTF-8，不要留空 - 如果文件带 BOM，DBeaver 通常能自动识别；但若仍乱码，可尝试在 Notepad++ 中选
Encoding → Convert to UTF-8 without BOM后重试
CSV 是 UTF-8，但数据库是 GBK/GB2312 怎么办？
导入本身不会报错，但中文进库后查出来仍是乱码——因为 DBeaver 只负责把字节流按指定编码解析成字符串，后续插入行为由 JDBC 驱动和数据库服务端编码共同决定。
关键点：
- MySQL 要求连接 URL 包含
?characterEncoding=utf8mb4，且表字段用utf8mb4排序规则；若目标库强制用GBK，则必须让 CSV 也用GBK编码，而非强行 UTF-8 导入 - PostgreSQL 对编码敏感，
client_encoding必须与导入编码一致；设成UTF8时，源文件就必须是 UTF-8 - Oracle 若用
AL32UTF8字符集，接受 UTF-8 导入；但若列定义为VARCHAR2且数据库字符集非 UTF-8，可能截断或报ORA-01401: inserted value too large for column
Excel 另存为 CSV 时怎么确保是真 UTF-8？
Excel 默认“CSV（逗号分隔）”保存的是 ANSI（Windows 下即 GBK），标着“UTF-8”但实际不是。这是最隐蔽的坑。
正确做法：
- Excel 2016+：另存为 → 选择
CSV UTF-8 (逗号分隔) (*.csv)格式（注意名称里带UTF-8） - 旧版 Excel 或不确定时：先另存为普通 CSV → 用 Notepad++ 打开 →
Encoding → Convert to UTF-8→Save - 验证方式：用
file -i your.csv（Linux/macOS）或 PowerShell 执行Get-Content your.csv -Encoding UTF8 | Select-Object -First 1，看是否能正常输出中文
真正容易被忽略的是：即使所有环节都设对了 UTF-8，如果 CSV 里某一行包含未闭合引号、换行符或非法控制字符，DBeaver 的 DataImporterCSV 解析器会在该行直接截断，后续所有列偏移错位——这时预览页看着正常，导入后数据全错位。务必打开预览页，拖到底部看最后几行是否对齐。
