Navicat 逆向工程中文全是乱码？换条路：SQL 转 ER 图中文名一个不丢

用 Navicat 逆向工程生成 E-R 图中文表注释全是乱码——这个问题网上问得最多解法基本都指向改连接编码、换驱动。但有一类情况容易被忽略如果你的 ER 图工具压根不读COMMENT字段那不管怎么调编码中文名都不会出现。前者是编码问题后者是工具能力问题。分不清这两者你会白折腾一整晚。本文讲清中文 SQL 转 E-R 图会踩的三种坑并用捷码AI 实测中文表名/注释的处理效果。01中文 SQL 转 ER 图三种不同的坑先分清问题出在哪一层否则容易白折腾。坑一连接层编码不对Navicat 乱码的主因Navicat 逆向工程时如果连接字符集和数据库实际字符集不一致读回来的中文就变成??或学生。特征中文变成完全无法辨认的符号且所有中文都乱。解法改连接编码、确认库/表字符集是utf8mb4、必要时更新驱动。这是 Navicat 生态里问得最多的一类。坑二工具不读 COMMENT最容易被误判成编码问题有些 ER 图工具只解析表名和字段名完全忽略COMMENT。特征英文表名正常显示但中文注释一个都不出现你会以为是中文丢失了。真相不是乱码是工具压根没读。看一段常见的建表语句CREATETABLEtb_student(idvarchar(32)NOTNULLCOMMENT学生主键,stuNovarchar(50)NOTNULLCOMMENT学号,namevarchar(50)NOTNULLCOMMENT姓名,gendervarchar(10)COMMENT性别,majorRefvarchar(32)COMMENT所属专业,PRIMARYKEY(id))COMMENT学生信息表;如果工具只取英文名你在图上看到的就是tb_student/stuNo/majorRef——能看懂表结构但没法直接放进中文文档。坑三中文表名/字段名本身的处理少数项目直接用了中文表名或中文字段名。这类 SQL 对工具的要求更高解析器必须正确处理 UTF-8 标识符画布渲染也要能显示中文。特征SQL 能执行但导入工具时报语法错误。解法换用支持中文标识符的解析器。02为什么中文名对毕设特别重要如果是自己开发、自己维护看英文表名没问题。但毕设/课设场景不一样场景为什么需要中文名数据字典学校模板要求字段名 中文名 类型 长度 约束三线表学术格式的字段说明表必须有中文列名设计文档概念结构设计章节要用中文描述实体与属性答辩 PPT评委看的是中文英文表名讲解成本高论文正文“学生信息表包含学号、姓名、性别……”结论中文名不是锦上添花而是毕设材料里的硬性要求。如果 ER 图工具丢掉 COMMENT你就得手工补一遍中文名——11 个实体、92 个字段工作量不小。03捷码AI 实测中文注释怎么落地3.1 导入中文 SQL从 Studio 首页的SQL 导入进入粘贴带中文COMMENT的建表语句解析后进入 E-R 图工作区。关键在于右侧的数据字典数据字典的列结构是列名 | 中文名 | 数据类型 | 唯一键 | 外键引用其中「中文名」这一列直接来自 SQL 里的COMMENT。对照前面的建表语句列名中文名数据类型username用户名VARCHARpassword密码VARCHARname姓名VARCHARgender性别VARCHARjoinTime入会时间DATETIMEstatus会员状态VARCHAR英文名用于生成代码中文名用于生成文档——这是同一份结构的两种视图不用手工维护两套。3.2 中文名进了哪些产物补全中文名之后同一份结构能直接产出中文材料数据字典 / 三线表直接是序号 | 列名 | 中文列名 | 类型 | 长度 | 主键 | 列注释的学术格式可以贴进设计文档。建库 SQL 脚本生成的CREATE TABLE会带上COMMENT中文注释不丢。设计文档概念结构设计章节用中文名描述实体不需要手工翻译。04实测几张中文场景的 E-R 图下面几张图来自不同的中文业务场景可以看出中文表名/注释在成品图上的效果。酒店预订场景—— 客人、预订、房间、房型、入住记录、退房记录、管理员这个场景的关系值得细看同一个房间在不同时间可以有多次预订或入住一次预订与实际入住、退房之间如何衔接——这类时间维度的关系光看表名列表是发现不了的。学生成绩与排课场景—— 重点在学生—选修记录—课表—成绩登记这条链路注意成绩、状态、登记时间这些信息的位置它们不该塞进「学生」或「课程」实体而是一次选课行为的记录属性。教学工作量场景—— 课程、课程安排、教室、教师、工作量记录这张图体现了一个容易混淆的区分课程是相对稳定的基础信息具体哪学期、哪周、在哪个教室上课属于课程安排教师工作量则是另一个需要按学期计算的业务记录。三者不是一回事。学生信息管理场景—— 管理员、教师、学生与班级信息库、课程记录、选课记录读这张图时沿箭头检查谁提交信息、哪个处理接收、写入哪个数据存储、结果返回给谁。05中文名核对清单导入带中文注释的 SQL 之后按这几条核对表的中文名有没有落上来自COMMENT ...的表级注释字段中文名有没有丢尤其是长注释有没有被截断单引号里的转义处理对不对比如注释里本身带多字节字符没被截断VARCHAR(50)存中文时长度是否够中文名是否准确表达字段含义——SQL 里写备注1字段A这种建议改成业务含义数据字典里的中文名与三线表、设计文档是否一致最后一条最容易忽略改了一处中文名记得同步到其他产物。捷码AI 因为同源生成改了会自动同步如果导出后手工编辑过就要留意。06如果工具不读 COMMENT怎么办三条路按代价排序方案一换工具。选一个明确支持读取COMMENT的。判断方法很简单——导入一段带中文注释的 SQL看中文名有没有出现在字段列表里。方案二导出后手工补中文名。11 个实体、92 个字段大概半天工作量。适合项目小、只做一次的情况。方案三把中文名写进字段名。比如stu_name改成更明确的命名但这样代码可读性会下降不推荐。判断建议如果打算用这份结构继续生成设计文档、三线表、答辩 PPT方案一更划算——因为中文名后面还要用很多次一次补对省很多事。07小结回到最初的问题中文表名和注释的 SQL 能转 ER 图吗Navicat 乱码是连接层编码问题改字符集/驱动能解决但有一类乱码其实是工具不读COMMENT调编码没用得换工具中文名对毕设是硬需求数据字典、三线表、设计文档、答辩 PPT 都要用好的做法是英文名 中文名双轨英文名生成代码中文名生成文档。最后一句话中文名不是显示问题是数据模型的一部分。一个字段叫status还是叫会员状态直接决定了后面生成的文档是给人看的还是给机器看的。导入 SQL 时把中文名这一步做对后面所有材料都省事。