CSV导出中文或符号变问号是因编码未统一，需确保表字符集、连接编码、导出语句（CHARACTER SET utf8mb4）及目标程序解码方式四层一致，并处理换行符、引号转义及Excel数字精度问题。
导出CSV时中文或符号变问号，是编码没对齐
根本不是MySQL“导不出”，而是导出过程默认用latin1解释字段值，遇到utf8mb4存的中文、度符号（°）、版权符（©）就直接丢字节。你用记事本打开CSV看到乱码，但用VS Code看底部编码显示“UTF-8 with BOM”或“GBK”，说明源头和导出链路没统一。
实操建议：
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 建表时确保
CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci（MySQL 8.0）或utf8mb4_unicode_ci（5.7） - 导出前显式设置会话编码：
SET NAMES utf8mb4; - 用
SELECT ... INTO OUTFILE时必须加CHARACTER SET utf8mb4，例如：SELECT id, title, content FROM articles INTO OUTFILE '/tmp/export.csv' CHARACTER SET utf8mb4 FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY ' ';
- 避免用Excel直接“另存为CSV”——它默认GBK或带BOM；改用VS Code / Notepad++保存为
UTF-8 without BOM
字段含换行符或双引号导致错位截断
导出后某行突然少几列，或Excel里整行数据挤进一个单元格——大概率是content字段里有未转义的
、"或,。MySQL默认不处理这些，直接按原样写入，CSV解析器一碰到就认为该行结束或字段分隔，后面内容全被吞掉。
实操建议：
- 导出前清洗字段：
REPLACE(REPLACE(REPLACE(content, ' ', ' '), ' ', ' '), '"', '""')（注意双引号要转义成两个） - 强制包裹所有字符串字段：
OPTIONALLY ENCLOSED BY '"'比ENCLOSED BY '"'更安全，只包字符型字段 - 启用转义：
FIELDS ESCAPED BY '\'，这样"会被写成"，\n - 如果字段固定含换行，优先用
SELECT ... INTO DUMPFILE导出纯文本再用Python处理，别硬塞CSV
导出后Excel打开数字被截断（如bigint末5位变0）
这不是MySQL导出问题，是Excel的坑：它把超15位数字当浮点数处理，自动丢精度。你用记事本打开CSV确认数据完整，就说明导出成功了。
实操建议：
- 在Excel里用“数据 → 从文本/CSV”导入，导入向导中把对应列设为
文本格式 - 临时方案：导出SQL时给数字字段加单引号，例如
CONCAT("'", id, "'") as id，Excel会当字符串读 - 别用DBeaver等GUI工具一键导出CSV——它们常悄悄把数字列按Excel习惯处理，改用命令行
mysql -N -s -e "SELECT..." > out.csv更可控
phpMyAdmin导出CSV乱码或截断，别信它的“编码选择”
phpMyAdmin界面上选“UTF-8”导出，实际可能仍走latin1通道，尤其老版本（4.x）。它不校验表字符集，也不透传CHARACTER SET参数，纯靠猜。
实操建议：
- 绕过phpMyAdmin，直接连MySQL终端执行
INTO OUTFILE语句（需FILE权限） - 若只能用phpMyAdmin，先导出为
SQL格式，再用iconv -f utf8mb4 -t utf8mb4 your.sql > fixed.sql清理编码，最后用mysql命令导入 - 检查phpMyAdmin配置文件
config.inc.php里是否设了$cfg['DefaultCharset'] = 'utf8mb4';，没设就加上
