Navicat导出的.xlsx文件实为CSV伪装，无ZIP结构，导致WPS/pandas等无法识别；根本解法是导出UTF-8 CSV后用pandas+openpyxl转为真.xlsx。
navicat 导出的 excel 文件打不开、提示“文件损坏”或被其他软件（如 wps、libreoffice、python pandas）拒绝读取，根本原因不是文件“坏了”，而是它压根就不是真正的 .xlsx ——多数情况下，navicat 在后台导出的是 csv，却硬把后缀改成 .xlsx，连 zip 结构都没有。
Navicat 实际导出的是 CSV，不是 Excel
你在导出向导里选了“Excel 文件 2007 或以上版本（.xlsx）”，但 Navicat 15+ 版本在无 GUI 环境（比如计划任务、服务模式）下根本不会调用 Excel COM；即使在桌面环境下，它也常 fallback 到 CSV 生成逻辑。你看到的 .xlsx 文件，用 7-Zip 或 WinRAR 打开会发现里面没有 [Content_Types].xml、xl/ 目录等任何 OOXML 结构，纯文本内容 + 逗号分隔 —— 这就是 CSV。
- 双击用 Excel 打开能显示，是因为 Windows 关联了 .xlsx 后缀并自动启用“文本导入向导”兼容逻辑
- WPS / LibreOffice /
pandas.read_excel()不做这种妥协，直接按标准解析，自然报错“not a valid Excel file”或“Unsupported format” - 用
file report.xlsx命令（Linux/macOS）或 PowerShell 的Get-Content report.xlsx -Encoding Byte | Select -First 4查看前几个字节：如果是44 4F 43 58（即 “DOCX”）才是真 Word，Excel 应是50 4B 03 04（ZIP 头）；若开头是文本（如69,6E,74,65,72,6E,61,6C→ “internal”），那就是 CSV
导出时选错格式导致编码不可靠
就算 Navicat 真生成了 .xlsx（极少见），中文字段仍可能乱码，因为它的 Excel 导出不支持指定编码 —— 它依赖系统 locale（Windows 默认 GBK），而目标软件（如 Python、网页后台）默认按 UTF-8 解析。结果就是 Excel 里看着正常，pandas.read_excel() 读出来全是 。
- 导出向导里的
Character set选项对 .xlsx 格式**完全无效**，只影响 CSV/TXT 导出 - 如果你必须用 .xlsx 输出，唯一可控方式是：先导出为 UTF-8-BOM 编码的 CSV，再用脚本转成真 Excel（见下一条）
- Navicat v16.0.14+ 开始识别 Excel「另存为 → CSV UTF-8」生成的带 BOM 文件，但老版本仍会当 ANSI 处理，所以别信“导出即可用”
用 pandas + openpyxl 转 CSV 为真 Excel（推荐方案）
绕过 Navicat 的 Excel 导出逻辑，让它只干一件事：稳定输出 UTF-8 编码的 CSV。后续交由 Python 脚本生成标准 .xlsx，彻底解决兼容性问题。
- Navicat 导出设置：格式选
CSV 文件，勾选第一行为列名，编码选UTF-8，路径用绝对路径（如C:\data\report.csv） - 写一个转换脚本
convert.py：
import pandas as pd df = pd.read_csv(r"C:\data\report.csv", encoding="utf-8") df.to_excel(r"C:\data\report.xlsx", index=False, engine="openpyxl")
- 确保已安装：
pip install pandas openpyxl（openpyxl是写 .xlsx 的标准引擎，xlsxwriter不支持读，xlrd已弃用） - 在 Navicat 计划任务的“执行后”动作中运行该脚本，或用 Windows 任务计划程序直接调度
python convert.py
为什么不用 Navicat 自带的 Excel 导出功能
不是不能用，而是它在三个关键维度不可控：格式真假、编码隐式、环境依赖。尤其当你需要自动化、跨平台（比如导出后发邮件给 Mac 用户）、或接入 ETL 流程时，那个看似方便的 .xlsx 选项反而成了故障单上的高频项。
真正稳定的链路永远是：Navicat → UTF-8 CSV → 脚本 → 真 Excel。中间少一层黑盒，就少一个甩锅对象。
