Mac版Navicat导出Excel在Windows上乱码，核心是UTF-8无BOM文件被Windows Excel按ANSI（如GBK）错误解码；应优先导出xlsx格式，或导出CSV时勾选UTF-8 with BOM，同时确保连接层启用SET NAMES utf8mb4并验证服务端字符集为utf8mb4。
Mac版Navicat导出的Excel在Windows上打开乱码，核心原因是导出时默认用了Mac系统 locale（通常是UTF-8无BOM），而Windows版Excel双击打开CSV或某些.xlsx文件时，会跳过BOM检测、按ANSI（如GBK或Windows-1252）解析字节流——不是文件坏了，是解码器选错了。
导出格式选了CSV却直接双击用Excel打开
这是最常见也最容易修复的场景。Mac版Navicat导出CSV时默认用UTF-8无BOM，但Windows Excel不认这个编码，一打开就当GBK解，中文全变館须这类序列。
- 立刻止损：别再双击CSV，改用Excel「数据 → 自文本/CSV」导入，在弹窗里手动把编码选为
65001: UTF-8 - 长期规避：导出时直接选
Excel 2007-365 (*.xlsx)格式，xlsx容器自带Unicode元信息，跨平台不依赖外部编码声明 - 若必须导CSV：在Navicat导出向导「高级选项」里勾选
UTF-8 with BOM（不是UTF-8），这样Windows Excel双击才能识别
导出的是.xlsx但字段名或注释仍乱码
这说明乱码发生在元数据层——Navicat从MySQL读取COLUMN_COMMENT或表名时，连接层没声明utf8mb4，导致服务端返回的UTF-8字节被当latin1拆解，再塞进xlsx就不可逆损坏了。
记录数据一键导出 Excel/CSV（带样式）
下载
把记录数组导出为带样式的 Excel(xlsx) 或带 BOM 的 CSV。支持列配置（表头/宽度/顺序）、表头冻结首行、斑马纹、布尔值转「是/否」、数组换行、CSV 中文防乱码。零依赖。触发词：导出 Excel、导出 CSV、记录转表格、列配置导出、数据导出、表格美化、JSON 转表格。
- 检查当前连接是否启用
SET NAMES utf8mb4：右键连接 → 编辑连接 → 高级 → 初始化命令填入该语句，保存后**重新连接** - 确认MySQL服务端字符集不是
latin1：执行SHOW VARIABLES LIKE 'character_set_server';，如果是latin1，需改配置文件重启，否则新导出的注释永远会丢 - 临时验证：连接后执行
SELECT @@character_set_client, @@collation_connection;，两个值都应含utf8mb4
Windows Excel打开.xlsx后日期/数字列格式错乱
这不是乱码，是Excel for Windows自动把字符串当数值/日期解析，比如2024-03-15被转成3/15/2024，或金额丢失千分位。Mac版Navicat导出时不会强制格式化，靠Excel自己猜。
- 导出前在SQL里显式格式化：
DATE_FORMAT(created_at, '%Y-%m-%d')（MySQL）或TO_CHAR(created_at, 'YYYY-MM-DD')（PostgreSQL） - 数值列加空字符串转文本：
CONCAT('', amount)或CAST(amount AS CHAR)，避免Excel识别为数字类型 - 导出向导「高级选项」中关闭
自动识别数字/日期（不同版本名称略有差异，通常在「格式设置」页签）
真正麻烦的不是导出动作本身，而是Mac和Windows对「默认编码」和「自动类型推断」的信任机制完全不同——Mac版Navicat不会替你补BOM，也不会帮你把日期转成字符串，这些都得在SQL层或导出设置里提前堵住。漏掉任意一环，Windows端看到的就是不可逆的显示错误。
