根本原因是windows用gbk编码文件名而linux服务器以utf-8解析，导致$_files['file']['name']乱码；thinkphp不自动转码，需在调用$request->file()前用mb_convert_encoding将gbk转utf-8。
Windows上传文件名在Linux服务器显示乱码
根本原因是Windows默认用GBK编码生成文件名，而Linux服务器（尤其是Nginx+PHP-FPM环境）通常以UTF-8处理请求头中的filename字段，导致$_FILES['file']['name']直接读取时出现乱码（如“测试.pdf”变成“æµè¯.pdf”）。
ThinkPHP自身不自动转码$_FILES原始值，所以不能依赖$request->file()返回的对象直接取getClientOriginalName()——它只是原样封装了$_FILES['xxx']['name']，未做任何编码修正。
- 优先检查服务器PHP是否启用
mbstring扩展：php -m | grep mbstring，缺失则需安装，否则后续转码函数不可用 - 不要用
iconv('UTF-8', 'GBK', $name)反向猜测，Windows上传的GBK字节流被当作UTF-8解析后已损坏，无法无损还原 - 正确做法是：先判断原始字节流是否为合法UTF-8，不是则按GBK解码再转UTF-8——ThinkPHP 6.0+ 可在中间件或上传前统一拦截处理
ThinkPHP 6 中手动修复上传文件名编码
在控制器接收文件前，对$_FILES中所有name字段做预处理。推荐在基类控制器或全局中间件中插入以下逻辑：
// 示例：在中间件 handle() 方法中
foreach ($_FILES as &$file) {
if (is_array($file['name'])) {
// 多文件上传，遍历每个 name
array_walk($file['name'], function (&$name) {
if (!mb_check_encoding($name, 'UTF-8')) {
$name = mb_convert_encoding($name, 'UTF-8', 'GBK');
}
});
} else {
if (!mb_check_encoding($file['name'], 'UTF-8')) {
$file['name'] = mb_convert_encoding($file['name'], 'UTF-8', 'GBK');
}
}
}
注意：mb_convert_encoding第二个参数是目标编码（UTF-8），第三个是源编码（GBK）。若部分用户用Mac（UTF-8）上传，该逻辑不会误伤，因为mb_check_encoding会跳过合法UTF-8字符串。
- 此操作必须在
think\facade\Filesystem或$request->file()调用前完成，否则ThinkPHP内部已缓存原始乱码值 - 避免在
moveTo()之后再处理文件名，重命名应基于修复后的名称，而非原始getClientOriginalName() - 如果使用
think\filesystem\Driver上传到OSS/S3，也要确保传入的$savename是已转码的UTF-8字符串，否则OSS控制台可能显示方块
nginx + fastcgi 配置影响文件名解析
某些旧版nginx（fastcgi_param时，会将HTTP请求头中的非ASCII字符截断或转义，导致PHP收到的$_FILES['file']['name']本身就是损坏值，此时仅靠PHP层转码无效。
确认nginx配置中包含以下两项（尤其当使用fastcgi_pass时）：
fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length;
更关键的是，禁用underscores_in_headers on（如果开启），它可能导致带下划线的header字段被丢弃，间接影响multipart解析稳定性。
- 临时验证方法：在PHP中打印
var_dump($_SERVER['CONTENT_TYPE'])，确认是否含boundary=且未被截断 - 若发现
$_FILES['file']['name']为空或极短（如单个问号），大概率是nginx未正确透传multipart header，需升级或调整fastcgi配置 - Apache用户较少遇到此问题，因mod_php直接接入，但启用
mod_security时也可能过滤掉非ASCII filename，需检查规则日志
兼容Mac/Linux/Windows三端上传的健壮写法
单纯假设Windows用GBK、其他用UTF-8仍不够——部分Windows浏览器（如Edge最新版）已开始发送UTF-8编码的filename，而国产双核浏览器行为更混乱。更稳妥的方式是尝试多种编码回退：
$name = $_FILES['file']['name'];
$encodings = ['UTF-8', 'GBK', 'BIG5', 'ISO-8859-1'];
foreach ($encodings as $encoding) {
$decoded = mb_convert_encoding($name, 'UTF-8', $encoding);
if (mb_check_encoding($decoded, 'UTF-8') && $decoded !== $name) {
$name = $decoded;
break;
}
}
这段代码不保证100%准确，但比单编码方案容错更强。实际项目中建议记录$name原始字节长度和常见编码匹配结果，用于后续统计哪些客户端需要特殊处理。
- 不要在生产环境无条件使用
iconv(..., 'IGNORE')，它会静默丢弃无法转换的字节，导致文件名被截断 - 如果业务允许，最彻底的方案是放弃原始文件名，用UUID+时间戳重命名，并将原始名存数据库（经
mb_detect_encoding识别后保存），但需额外字段支持 - 移动端（Android/iOS）App直传文件时，务必让客户端在POST body中额外传一个
filename_utf8字段，服务端优先取它，绕过HTTP header编码歧义
跨系统文件名从来不是单纯的编码问题，而是HTTP协议、Web服务器、PHP运行时、浏览器实现四层叠加的兼容性缝合。真正稳定的方案，往往要同时动nginx配置、PHP中间件、客户端约定三处，缺一不可。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
