确认CSV真实编码比猜测更可靠，应优先检测文件头BOM（如EF BB BF为UTF-8 with BOM），再用StreamReader显式指定Encoding读取；写入时按需选择UTF-8 with BOM（兼容Excel）或without BOM（跨平台）。
确认CSV文件真实编码比猜更可靠
乱码第一反应不是改数据库，而是看文件本身编码对不对。windows记事本标“utf-8”常带bom（开头三个字节 ），phpmyadmin会把它当普通字符吞掉，导致首字段错位；notepad++或vs code底部状态栏显示的编码才是真实值，不是文件后缀或你“以为”的编码。
实操建议：
- 用
file -i your_file.csv（Linux/macOS）或在VS Code里打开后看右下角编码标识 - 若显示
charset=iso-8859-1或gbk，别硬塞utf8mb4——先转码再导入 - 转码时选“UTF-8 without BOM”，Notepad++里叫“转为UTF-8编码”，不是“以UTF-8编码保存”
phpMyAdmin导入页的“字符集”下拉框不能信
phpMyAdmin界面上那个“字符集”选项，只控制它自己读取CSV时的解码方式，不改变MySQL服务端接收数据时的 character_set_client。如果数据库连接层用的是latin1，你在这儿选utf8mb4也没用——数据进表前就被MySQL按latin1解了一次。
实操建议：
- 导入前先执行
SET NAMES utf8mb4;（在phpMyAdmin的SQL标签页运行） - 检查当前连接实际生效的client charset：
SELECT @@character_set_client;，必须是utf8mb4 - 如果返回
latin1，说明phpMyAdmin底层连接没配对，此时手动改表或换工具更省时间
数据库和表的字符集必须显式设为utf8mb4，不能只靠默认
新建库时勾选“utf8mb4”不代表所有已有表都继承——CREATE DATABASE 的字符集只影响后续新建的表，老表的 COLLATION 还卡在 utf8_general_ci 或更旧的编码上，存汉字会静默截断或乱码。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 查表实际编码：
SHOW CREATE TABLE your_table;，重点看字段定义末尾的CHARACTER SET utf8mb4和COLLATE utf8mb4_unicode_ci - 单字段修复：
ALTER TABLE your_table MODIFY COLUMN name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 整库批量改（慎用）：
ALTER DATABASE your_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;，但已有表不会自动同步
导出再导入时Excel兼容性陷阱
用phpMyAdmin导出的CSV，被Excel打开乱码，是因为Excel默认用系统ANSI编码（如Windows-1252）读UTF-8文件，不是数据库问题。反过来，从Excel另存的CSV如果选了“UTF-8”，大概率带BOM；选“CSV UTF-8 (逗号分隔)”才真正无BOM。
实操建议：
- 从Excel导出：文件 → 另存为 → 选择“CSV UTF-8 (逗号分隔) (*.csv)”
- 从phpMyAdmin导出后想用Excel看：用记事本打开 → 另存为 → 编码选“UTF-8”，**不要选“UTF-8-BOM”**
- 如果必须用Excel直接打开，走“数据 → 自文本/CSV → 导入 → 选择UTF-8编码”流程，绕过双击打开的自动识别
