Na vicat中文显示问号或方块？先查连接层编码
遇到中文乱码，先别急着怪编辑器。问题的本质，往往是客户端与数据库之间的编码“对话”失败了。Na vicat本身并不存储数据，它只是一个“翻译官”，负责把服务端返回的字节流，按照我们指定的编码规则进行解读。试想一下，如果服务端发来的是utf8mb4编码的字节，但Na vicat却用latin1的规则去硬解，显示出一堆问号或方块，也就不足为奇了。
那么，具体该怎么排查和解决呢？可以遵循以下几步：
- 首先，在Na vicat的连接设置里找到「高级」选项卡，确认「MySQL字符集」一项是否设置为
utf8mb4（注意，是utf8mb4，不是utf8）。 - 接着，执行一个关键查询：
SHOW VARIABLES LIKE 'character_set%';。你需要重点关注character_set_client、character_set_connection、character_set_results这三个变量的值，它们是否全部为utf8mb4。 - 如果发现其中某项是
latin1或gbk，那说明连接初始化的SQL命令可能没生效。这时，就需要回到「高级」设置，在「初始化命令」中手动加上一句：SET NAMES utf8mb4;。
建表时用utf8就够了？别信旧文档
这里有一个经典的认知误区。很多人以为MySQL里的utf8就是万能的，其实不然。MySQL中的utf8是一个“阉割版”，它最多只支持3字节的字符，这意味着像Emoji表情、部分生僻汉字等4字节字符根本无法存储。真正能兼容所有中文全集的，是utf8mb4。很多乱码问题的根源，其实从表结构设计时就埋下了。
因此，我们的操作建议必须明确：
- 新建表时，务必在字段定义后显式地写上
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。 - 修复已有表：执行
ALTER TABLE `table_name` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;这条命令。 - 需要特别提醒的是：仅仅修改表的默认字符集（使用
ALTER TABLE ... DEFAULT CHARACTER SET）是远远不够的，字段级别的编码可能仍然保留着旧值，隐患依旧存在。
Na vicat查询结果中文正常，但双击编辑就变乱码？关掉「自动SQL」模式
这可能是Na vicat里最隐蔽的一个“坑”了。当开启「自动SQL」功能后，你双击单元格进行编辑，会触发一条隐式的SELECT ... FOR UPDATE语句。问题就在于，这条隐式语句执行的字符集上下文，可能与主连接的设置不一致，尤其是在事务中切换过连接参数的情况下，乱码就很容易出现。
解决这个问题的思路很直接：
- 打开菜单栏的「工具」→「选项」→「查询」，找到并取消勾选
自动SQL功能。 - 改为手动执行模式：先编写好完整的SQL语句，例如
UPDATE table SET col = '中文' WHERE id = 1;，然后按F9运行。 - 如果某些场景下必须使用双击编辑，那么请务必确保当前连接未处于事务中（观察Na vicat右下角状态栏，不应显示
IN TRANS字样）。
Mac上Na vicat中文输入法候选框错位或无法上屏？换字体比调系统更有效
Mac用户可能遇到过这种尴尬：编码都设对了，但输入中文时，候选框要么位置飘忽不定，要么根本打不上字。这其实不是编码问题，而是Na vicat（尤其是15及以上版本）使用的Qt渲染框架与macOS输入法框架之间的兼容性小缺陷。调整系统语言或输入法设置通常收效甚微，但换个字体却能巧妙地绕过这个渲染异常。
具体操作很简单：
- 点击菜单栏「Na vicat」→「偏好设置」→「外观」，找到「编辑器字体」选项。
- 将其更改为
Monaco或SF Mono这类等宽字体。 - 尽量避免使用
Helvetica Neue、System Font等带有可变轴特性的字体。 - 重启Na vicat后，你会发现中文输入时候选框的位置和上屏成功率都有明显改善。
当然，最复杂的情况是多层嵌套的连接场景。比如，通过SSH隧道连接远程MySQL，中间还可能经过跳板机。在这种情况下，每一层连接的character_set_client都可能在传递中被重置。此时，仅仅调整Na vicat客户端的设置是徒劳的，必须逐层检查服务器端的my.cnf配置文件，以及SSH配置中的LC_ALL等环境变量，确保整个链路编码一致。这才是治本之道。
