DBeaver导出Excel中文变问号，90%是Windows Excel误用GBK解析UTF-8字节流所致；根本解法为导出时选UTF-8并勾选Write BOM header，再通过Excel“数据→从文本/CSV”手动指定UTF-8编码加载，或改用GB2312导出以适配系统默认编码。
直接说结论：DBeaver导出Excel后中文变问号，90%不是DBeaver或Excel本身坏了，而是CSV中间环节被Windows Excel用GBK（如GB2312）错误解析了UTF-8字节流——你导出的其实是对的，只是Excel没“认出来”。
导出时选UTF-8 + BOM，但Excel仍乱码
这是最典型的“假失败”。DBeaver导出CSV时若只选UTF-8但不勾选Write BOM header，生成的文件是UTF-8 without BOM。Windows版Excel默认跳过BOM检测，直接按系统区域编码（通常是GBK或GB2312）解码，结果把中（UTF-8三字节E4 B8 AD）当成三个独立的GBK字符，显示为???或方块。
解决方法很简单：
- 导出向导中，
Character set选UTF-8，必须勾选Write BOM header - 导出后，别双击打开——用Excel菜单栏
数据 → 从文本/CSV，手动选择该文件，编码下拉框里明确选UTF-8再加载 - 如果必须双击就开，那就放弃UTF-8，改用
GB2312或GBK导出（仅限简体中文环境），Excel能自动识别
数据库连接URL没配encoding参数
DBeaver界面里中文显示正常，不代表导出数据也可靠。如果连接MySQL时URL里没带useUnicode=true&characterEncoding=UTF-8，JDBC驱动可能用平台默认编码（如Windows-1252）解包数据库返回的UTF-8字节，内存里就已经错了一次，后续导出全是错的源数据。
检查和修复步骤：
- 右键连接 →
Edit Connection→Driver Properties - 确认存在两个键值：
useUnicode=true，characterEncoding=UTF-8 - PostgreSQL用户则加
charSet=UTF-8，SQL Server加characterSet=UTF-8 - 改完重启连接，重查一次表确认界面上中文是否依然正常
导入CSV回DBeaver时又乱码
反过来操作时容易踩坑：你用Excel另存为CSV，却没注意它默认用GBK保存；然后在DBeaver导入向导里还选UTF-8，等于让DBeaver用UTF-8去解GBK编码的字节，必然乱码。
快速判断和处理：
- 用
Notepad++打开那个CSV文件，看右下角状态栏显示的编码是ANSI（即GBK系）还是UTF-8 - 如果是
ANSI，DBeaver导入时Charset就得选GBK或GB2312 - 如果想统一用UTF-8，就在Excel里用
文件 → 另存为 → CSV UTF-8 (逗号分隔)（Excel 2016+才有此选项） - 导入前务必检查目标表字段的字符集，比如MySQL里
SHOW CREATE TABLE your_table，确保是utf8mb4，否则即使导入成功，存进数据库也会被截断或转成?
真正麻烦的点不在设置多难，而在于整个链路有5个环节（数据库→JDBC→DBeaver内存→文件写入→Excel解析）都可能各自用不同编码，且其中任意一环静默失败都不会报错，只默默给你一堆问号。动手前先用Notepad++或file -i your.csv确认实际编码，比反复试导出选项高效得多。
