ci框架中文文件名乱码的根本原因是$_files'file'在windows+ie/edge等环境下为gbk编码，而ci默认按utf-8处理，导致路径比对失败；需在set_filename()中双向转码，并同步修正do_upload()中的move_uploaded_file()路径编码，或改用前端标准化+业务层映射方案。
Upload类中文文件名乱码的根本原因
不是CI框架本身“不支持中文”，而是它在处理$_FILES原始数据时，直接拿浏览器传来的$_FILES['file']['name']做后续操作——而这个值在Windows+IE/Edge或部分旧版Chrome下，极大概率是GBK/GB2312编码，但CI默认按UTF-8解析和拼接路径，导致file_exists()、move_uploaded_file()等函数内部字节流比对失败。
典型现象：上传“测试.pdf”后，实际保存为“娴嬭瘯.pdf”；或同名文件不重命名直接覆盖；或$this->upload->data('file_name')返回乱码字符串。
修改Upload类的set_filename()函数
必须同时解决两个问题：检查是否存在同名文件（需用目标编码比对），以及最终保存时用目标编码写入磁盘。不能只改一处。
- 找到
system/libraries/Upload.php中的set_filename()方法 - 在生成
$filename后、调用file_exists()前，先转成目标系统编码（通常是GB2312或GBK）：$filename = iconv('UTF-8', 'GB2312//IGNORE', $filename); - 检查完
file_exists($path . $filename)后，再把$filename转回UTF-8供后续逻辑使用：$filename = iconv('GB2312', 'UTF-8', $filename); - 如果启用了
$config['encrypt_name'] = TRUE，跳过转换，避免干扰哈希逻辑
do_upload()中move_uploaded_file()路径编码要同步
Upload类的do_upload()最终调用move_uploaded_file()，此时$this->upload_path . $this->file_name必须是操作系统能识别的编码格式。Linux一般没问题，Windows服务器必须是GBK系。
- 定位到
do_upload()里@move_uploaded_file()那一行 - 把目标路径包裹进
iconv()：iconv('UTF-8', 'GB2312//IGNORE', $this->upload_path . $this->file_name) - 注意：
//IGNORE参数很重要，可跳过无法转换的字符，防止整个上传失败 - 如果服务器是Linux且locale设为
zh_CN.UTF-8，可省略此步；但跨平台部署时建议保留
更干净的替代方案：前端统一用英文名+后端映射
硬改核心类容易被升级覆盖，也增加维护成本。推荐在控制器层拦截并标准化：
- 上传前用
mb_convert_encoding($_FILES['file']['name'], 'UTF-8', 'auto')统一源编码 - 用
pathinfo()提取扩展名，再用uniqid()或时间戳生成安全文件名 - 把原始中文名存进数据库字段（如
original_name），下载时再用于force_download()的filename参数 - 这样Upload类完全不用动，所有中文处理收敛到业务逻辑层，CI升级也不受影响
真正麻烦的从来不是转码本身，而是不同环节用的编码假设不一致——比如你用iconv('UTF-8','GB2312')，但系统locale其实是zh_CN.GBK，这时候//IGNORE和mb_detect_encoding()的 fallback 顺序就非常关键。别信“一次转换搞定”的说法。
