MySQL报错1366是因字符集不匹配导致非法UTF-8字节（如emoji、生僻字）被拒绝，需统一client/server/table为utf8mb4，清洗脏数据，禁用静默跳过。
MySQL 导入报错 1366：Incorrect string value 是什么情况
这是 mysql 在插入或更新含非目标字符集（尤其是 utf-8 兼容性不足）的字符串时抛出的典型错误，本质是服务端 character_set_client 与表字段实际支持的编码不匹配，导致某些字节序列（如 emoji、生僻汉字、windows-1252 污染字符）被拒收。
检查并统一字符集链路：从连接到表结构
错误常因“表面 UTF-8”但底层不一致引起。必须逐层确认，缺一不可：
-
SHOW VARIABLES LIKE 'character_set%';看character_set_client、character_set_connection、character_set_results是否均为utf8mb4 -
SHOW CREATE TABLE `your_table`;确认字段定义带CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，不是utf8（MySQL 的utf8实为utf8mb3，不支持 emoji） - 客户端连接时显式指定：
mysql --default-character-set=utf8mb4 -u user -p；应用代码中连接字符串加?charset=utf8mb4（如 Python 的pymysql、Go 的mysql驱动）
清洗脏数据：用正则剔除非法 UTF-8 字节序列
若源数据已混入损坏字节（如从 Windows 记事本导出、旧系统导出），MySQL 不会自动修复，需预处理。重点不是“转码”，而是“删掉无法解释的字节”：
- Python 示例（读取 CSV 后清洗）：
import re def clean_utf8_bytes(s): return re.sub(b'[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f]', b'', s.encode('utf-8', errors='ignore')).decode('utf-8') - Linux 命令行快速过滤（适用于纯文本导入前）：
iconv -f UTF-8 -t UTF-8//IGNORE your_file.csv > cleaned.csv - 注意：
errors='replace'会插入 ，而errors='ignore'直接丢弃非法字节——后者更安全，避免污染后续逻辑
导入时强制跳过 1366 错误？别这么做
设置 SET sql_mode = ''; 或 SET NAMES latin1; 可能暂时绕过报错，但结果是数据静默损坏：中文变乱码、emoji 变空格、甚至整行截断。真正代价在后期查数、对账、导出回传时才爆发。
复杂点在于：同一份数据里可能混合合法 UTF-8、Windows-1252 编码的引号、以及 BOM 头。清洗不能只靠一次 iconv，得先用 file -i your_file 看真实编码，再分段处理。没人会告诉你，有些 Excel 导出的 CSV 其实是 GBK 编码却声称自己是 UTF-8——这时候强转反而雪上加霜。
