Navicat不支持直接导入PDF，因PDF是二进制格式而非文本；必须先用pdftotext、Adobe Acrobat或OCR工具转为CSV/Excel，再确保UTF-8编码（无BOM）、MySQL连接与字段均为utf8mb4_unicode_ci，最后通过Navicat正常导入。

Navicat导入PDF时根本不会读取编码——PDF不是文本文件

navicat 不支持直接“导入 pdf 报表”到数据库，它没有 pdf 解析引擎。所谓“导入 pdf”，实际是用户误操作：把 pdf 文件拖进数据传输、导入向导或执行了 load data infile 之类命令，结果报错或显示乱码。pdf 是二进制格式，含字体、矢量图、压缩流，不是 utf-8 或 gbk 可解码的纯文本。

常见错误现象：

• 导入后字段全是方块、问号或空格
• Navicat 提示 Error 1300: Invalid utf8mb4 character string
• 用“导入向导”选中 PDF 文件，下一步就卡住或跳过内容

真正该走的路径：PDF → 文本/表格 → 导入数据库

必须先将 PDF 转为结构化数据（如 CSV、Excel、TXT），再通过 Navicat 正常导入。关键在转换环节是否保留原始编码和中文对齐。

实操建议：

• 优先用 pdftotext（Linux/macOS）或 pdf2csv.com（在线，慎传敏感数据）提取文字；Windows 用户可用 Adobe Acrobat DC 的“导出为 Excel”功能（比复制粘贴更保格式）
• 若 PDF 是扫描件，需 OCR：用 ABBYY FineReader 或 WPS PDF 工具箱，导出时明确选择 UTF-8 编码保存 CSV/TXT
• 导出的 CSV 文件，用记事本打开 → “另存为” → 编码选 UTF-8（无BOM），避免 Navicat 识别成 ANSI

Navicat 导入时编码设置不生效的几个硬坑

即使源文件是 UTF-8，Navicat 仍可能乱码，原因不在“没点对编码选项”，而在底层连接或字段定义不匹配。

容易踩的坑：

• MySQL 连接字符集不是 utf8mb4：检查 Navicat 连接属性 → “高级” → Initial SQL 加上 SET NAMES utf8mb4;
• 目标表字段是 CHAR/VARCHAR 但排序规则为 utf8mb4_general_ci（已弃用）或 latin1_swedish_ci：必须改成 utf8mb4_unicode_ci
• 导入向导里勾了 Use same encoding for all files，但 CSV 实际含 BOM —— 此时应取消勾选，手动为每个文件指定 UTF-8 (with BOM) 或 UTF-8 (no BOM)

为什么用 Excel 中转比直接导 CSV 更稳？

因为 Excel（.xlsx）本身不依赖外部编码声明，Navicat 导入 Excel 时会绕过文本编码解析层，直接读取单元格字符串值。这对含混合中文、数字、符号的报表更鲁棒。

注意事项：

• 不要用 Excel “另存为 CSV”，而要用原生 .xlsx 格式导入
• 确保 Excel 单元格内无不可见控制字符（如 \u200E 零宽空格），可用 =CLEAN(A1) 清洗
• Navicat 导入 Excel 时，“第一行作为列名”必须与实际一致，否则字段错位，看着像乱码

PDF 本身没有“编码格式”可调，所有乱码问题都源于把它当文本处理。真正要盯紧的，是 PDF 转出环节的工具链选择、中间文件的 BOM 状态、以及 MySQL 表定义与连接层的三重编码一致性。