navicat导出的.xlsx实为utf-8编码csv伪装，因缺少zip结构和ooxml标准文件而被linux工具拒绝；可用file命令或检查文件头（非50 4b 03 04）验证，应改用pandas+openpyxl生成真.xlsx。
navicat在windows端导出的.xlsx文件，在linux下打不开（比如用libreoffice、pandas或openpyxl报“not a valid excel file”），根本原因不是跨平台问题，而是它压根就不是真正的.xlsx——绝大多数情况，navicat导出的是utf-8编码的csv文本，却硬把后缀改成.xlsx。
怎么确认你手上的.xlsx其实是CSV？
别信后缀，看内容：
- 在Linux/macOS终端运行
file report.xlsx：若输出是ASCII text或UTF-8 Unicode text，那就是CSV - 在Windows PowerShell中运行
Get-Content report.xlsx -Encoding Byte | Select -First 4：若前4字节是69, 6E, 74, 65（即“inte”），说明开头是明文，不是ZIP头50 4B 03 04 - 把文件后缀临时改为.zip，用
unzip -t report.zip测试：若报cannot find zipfile directory，就是假ZIP
为什么Excel能打开，但pandas/LibreOffice不能？
Windows Excel有兼容逻辑：双击一个.csv伪装成.xlsx的文件，会自动触发“文本导入向导”，按逗号/制表符分列并猜测编码。而Linux下的LibreOffice、pandas的read_excel()、甚至WPS都严格按OOXML标准解析——要求文件必须是ZIP包，内含[Content_Types].xml、xl/目录等结构。没有这些，直接拒绝。
-
pandas.read_excel()报错典型提示：Unsupported format, or corrupt file或InvalidFileException - LibreOffice弹窗：“无法打开此文件，因为格式不受支持”
- 关键差异：Excel做“容错加载”，其他工具做“标准校验”
导出设置里哪些选项会让问题更隐蔽？
Navicat导出向导里的几个选项看似无害，实则埋雷：
- 格式选了
Excel 文件 2007 或以上版本 (.xlsx)，但实际生成逻辑 fallback 到CSV（尤其在无GUI环境或计划任务中） -
Character set下拉菜单对.xlsx格式完全无效——它只影响CSV/TXT导出；选了UTF-8也没用，因为根本没走编码写入流程 - 勾选
Export with BOM对.xlsx无意义，但若你误导出为CSV再手动改后缀，BOM反而会导致pandas读取时多出\ufeff乱码列 - Navicat v16.0.14+ 能识别UTF-8-BOM CSV，但老版本仍当ANSI处理，所以别依赖“导出即可用”
真正可靠的做法：用Python转一次真.xlsx
绕过Navicat的Excel导出模块，让它只干一件事：稳定输出UTF-8无BOM的CSV。后续用脚本生成合规.xlsx：
import pandas as pd
from openpyxl import Workbook
<h1>1. 先让Navicat导出为 UTF-8（不带BOM）CSV</h1><p>df = pd.read_csv('report.csv', encoding='utf-8')</p><h1>2. 写入真.xlsx（openpyxl保证ZIP结构和XML合规）</h1><p>df.to_excel('report_fixed.xlsx', index=False, engine='openpyxl')</p>
- 务必用
encoding='utf-8'读CSV，避免默认系统编码（如GBK）导致中文乱码 - 不要用
engine='xlsxwriter'：它不支持写入已有样式，且对空值处理不如openpyxl鲁棒 - 生成的
report_fixed.xlsx可被pandas、LibreOffice、WPS、openpyxl全链路识别
最易被忽略的一点：Navicat的“Excel导出”本质是个历史包袱，它从早期版本沿用下来的CSV fallback逻辑至今未被彻底移除。无论你换什么版本、调什么参数，只要没验证文件二进制头，就永远可能拿到一个“看着像.xlsx，实则不能跨平台”的假文件。
