根本原因是ODBC驱动默认用ANSI编码（如Windows-1252）解码，而Access文件实际为GBK/GB2312编码；需改用支持Unicode的ACCDB驱动、注册表设置CP=936、确保Navicat与Access引擎位数一致。

Navicat连接Access时中文显示为问号或方块

根本原因不是navicat本身，而是odbc驱动层默认用了ansi编码（如windows-1252），而你的access文件实际是gbk/gb2312编码存的中文。odbc不识别access内部的文本编码标记，直接按系统区域设置解码，一 mismatch 就乱码。

实操建议：

• 确认Access文件真实编码：用Access 2016+打开 → 文件 → 选项 → 高级 → 勾选「以Unicode格式保存所有新文本字段」；旧版Access（如2003）默认无Unicode支持，必须先升级或导出为.accdb
• 在Navicat中新建连接时，**不要选「Microsoft Access Driver (*.mdb)」**，改用「Microsoft Access Driver (*.mdb, *.accdb)」——后者支持Unicode路径和宽字符读取
• 连接成功后，在查询窗口执行：SELECT TOP 1 * FROM [表名]，如果仍乱码，说明ODBC数据源配置没生效

ODBC数据源里「Unicode translation for all data sources」不起作用

这个勾选项只影响SQL Server等远程库的传输层，对本地Access文件完全无效。Access ODBC驱动（尤其是32/64位混用时）根本不走这个路径。

真正起效的是注册表级强制编码策略：

• 关闭Navicat和所有Access进程
• 运行regedit，定位到：HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\你的DSN名称
• 新建字符串值：CP，值设为65001（UTF-8）或936（GBK）——优先试936，因为Access老版本导出的文本基本是GBK
• 若用的是用户DSN，路径改为：HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\你的DSN名称

导入到MySQL/PostgreSQL后还是乱码

这是两段式乱码：第一段是Navicat从Access读错，第二段是Navicat写入目标库时再错一次。不能只调目标库的character_set_client，得先确保源头数据正确。

关键检查点：

• 在Navicat中右键表 →「对象信息」→ 查看「字符集」列，如果是binary或空，说明Navicat根本没识别出字段编码，此时导入必然失败
• 手动建目标表时，显式指定字段字符集：VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
• 导入向导中务必取消勾选「使用目标表结构」，改选「自定义字段映射」，把源字段类型强制设为TEXT或VARCHAR，避免Navicat自动映射成BLOB

Access是ACCDB格式但Navicat提示「未发现可安装的ISAM」

这不是编码问题，是驱动架构冲突。64位Navicat无法调用32位Access Database Engine，反之亦然。

最稳解法：

• 查Navicat进程位数：任务管理器 → 详细信息 → 看Navicat.exe是否带*32后缀
• 去微软官网下载对应位数的Microsoft Access Database Engine Redistributable（注意：**不要装完整Office**，只装Engine）
• 安装时加参数/quiet，并确保勾选「仅安装驱动程序」——否则会和已装Office冲突报错
• 重装后重启Navicat，新建连接时驱动列表里应出现带「ACCDB」字样的选项，选它

复杂点在于Access引擎不支持并发写入，哪怕只是预览表结构，也要求Access文件没被其他程序（包括Windows资源管理器缩略图生成器）锁定。一个常被忽略的细节：关掉OneDrive实时同步，否则它会在后台偷偷打开.accdb文件。