根本原因是HTML文件字符编码与Navicat连接/表编码不一致，需统一为utf8mb4；Navicat不解析HTML标签，导入前须预处理提取纯文本或规范表格CSV；注意BOM头、字段长度及sql_mode导致的截断。
Navicat导入HTML时显示问号或方块字
根本原因是html文件的字符编码和navicat当前连接/表的编码不一致，常见于utf-8文件被当成了latin1或gbk读取。navicat本身不解析html标签，它只是把整个html源码当纯文本塞进字段——所以乱码源头在「文件保存编码」和「数据库连接编码」两个环节。
- 先用文本编辑器（如VS Code、Notepad++）打开HTML文件，右下角确认实际编码是
UTF-8还是UTF-8 with BOM；带BOM的UTF-8在MySQL里容易触发异常识别 - 检查Navicat连接属性里的
Character set是否设为utf8mb4（不是utf8） - 目标表的列必须是
utf8mb4字符集，仅改连接编码不够：执行ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
用Navicat「导入向导」导入HTML文件时跳过HTML标签
Navicat不会自动剥离、<p></p>这些标签——它按你选的分隔符（比如换行、逗号）切数据，原样存入字段。如果你的HTML是网页正文，想只存文字内容，得预处理。
- 不要直接拖HTML文件进导入向导；先用Python或命令行提取纯文本：
lynx -dump your.html > clean.txt（Linux/macOS）或用BeautifulSoup脚本 - 如果HTML结构固定（比如每段
<div class="content">），可先用正则或<code>sed提取：sed -n '/<div class="content">/,//p' file.html | sed 's/]*>//g' <li>导入时在向导里取消勾选<code>First row contains column names，除非你手动准备了带标题的CSV - 登录MySQL命令行，运行
SHOW VARIABLES LIKE 'character_set%';，重点看character_set_client、character_set_connection、character_set_database是否全为utf8mb4 - 临时生效可在Navicat执行：
SET NAMES utf8mb4;（每次连接都要重设） - 永久生效需修改MySQL配置文件
my.cnf，在[mysqld]下加：character-set-server = utf8mb4，并重启MySQL - Navicat导入时勾选
Text qualifier并设为"，否则含逗号的单元格会分裂成多列
MySQL客户端编码设置影响Navicat导入结果
即使Navicat连接设对了，如果MySQL服务端默认编码仍是latin1，某些场景下仍会退化。尤其当你用LOAD DATA INFILE方式导入（Navicat底层可能调用该命令），服务端变量优先级更高。
从HTML中提取表格数据到MySQL字段对齐失败
HTML里的<table>转成CSV再导入时，常因嵌套标签、换行、引号未转义导致列错位。Navicat的CSV导入对格式敏感，不兼容HTML原生表格结构。
<ul><li>别用浏览器“另存为CSV”——它保存的是渲染后表格，不是源码；要用<code>pandas.read_html()或xml.etree.ElementTree解析<tr><td>结构
<li>导出前确保每行<code><tr>对应一行CSV，每个<code><td>内容用双引号包裹，内部双引号要转义为<code>""
最易被忽略的是HTML文件本身的BOM头和MySQL的sql_mode：如果启用了STRICT_TRANS_TABLES，而字段长度不足（比如VARCHAR(50)却存了100字节UTF-8汉字），导入会静默截断——看着没报错，数据却丢了后半截。
立即学习“前端免费学习笔记（深入）”；
