根本原因是CSV文件编码(如GBK)与PHP默认UTF-8解析不匹配;Excel乱码因嵌入非UTF-8字符串;数据库“正常显示”实为双重编码假象;文件上传名编码因浏览器/系统而异;需统一转码、清洗特殊Unicode字符。
fgetcsv 读取时中文全变成问号?根本原因不是 PHP 本身,而是 CSV 文件实际编码和你读取时假设的编码不一致。Windows 下用 Excel 保存的 CSV 默认是 GBK(或 GB2312),而 PHP 的 fgetcsv 默认按 UTF-8 解析,字节对不上,自然乱码。
实操建议:
mb_detect_encoding(file_get_contents($file), ['GBK', 'UTF-8', 'BIG5'], true) 粗略判断源文件编码(注意:不能完全依赖,仅作参考)iconv('GBK', 'UTF-8//IGNORE', $line) 转换每一行,//IGNORE 可跳过无法转换的非法字节str_getcsv 处理单行字符串,务必确保该字符串已是 UTF-8 编码,否则解析字段边界会错位新版 PhpSpreadsheet 默认以 UTF-8 处理文本,但 Excel 文件本身可能嵌入了非 UTF-8 的字符串(尤其老版本 Excel 或用户手动改过编码)。关键不在读取,而在单元格值取出后的使用环节。
实操建议:
mb_convert_encoding($cellValue, 'UTF-8', 'auto'),auto 会尝试 UTF-8, GBK, BIG5, SJIS 等常见编码mb_substr、mb_strlen 替代原生函数echo mb_internal_encoding() . ' | ' . mb_detect_encoding($cellValue);,确认当前环境和数据实际编码是否一致这是典型的“双重编码”假象:数据以 GBK 存入 MySQL,但连接时设了 SET NAMES utf8,MySQL 把 GBK 字节误当 UTF-8 解码返回,浏览器又按页面声明的 UTF-8 渲染,恰好“歪打正着”显示对了。一旦换环境或查日志就露馅。
实操建议:
mysqli_set_charset($conn, 'utf8mb4')(不是 SET NAMES)SHOW CREATE TABLE student_contact;,确认字段 CHARACTER SET 是 utf8mb4,且 COLLA
TE 是 utf8mb4_unicode_ci
$data = iconv('GBK', 'UTF-8//TRANSLIT', $data);,//TRANSLIT 比 //IGNORE 更稳妥,能将生僻字转为近似 ASCII 字符HTTP 协议本身不传编码信息,$_FILES 中的 name 字段在不同浏览器、不同操作系统下编码差异极大:Chrome on Windows 用 GBK,Safari on macOS 用 UTF-8,Firefox 则可能用原始字节。这不是 PHP 的锅,是历史遗留问题。
实操建议:
$_FILES['file']['name'] 的编码,用 mb_convert_encoding($_FILES['file']['name'], 'UTF-8', 'auto') 强制归一encodeURIComponent 编码文件名,PHP 端用 urldecode + mb_convert_encoding(..., 'UTF-8', 'UTF-8') 安全还原file -i $tmp_name(Linux 命令)或 exif_imagetype() 验证文件类型,防止绕过扩展名校验最易被忽略的一点:班级通信录常含 Excel 自动补全的“智能引号”(如 “中文”)、不间断空格、零宽空格等 Unicode 特殊字符,它们在 GBK 下无法表示,转换时会被静默丢弃或替换成 。处理前先用 preg_replace('/[\x{2000}-\x{206F}\x{FEFF}]/u', '', $str) 清洗一遍,比硬扛编码问题更省心。