PHP中rename()处理含加号文件名出错的根源是URL编码混淆：GET/POST参数中的+需用urldecode()转为空格，而字面量+应由前端encodeURIComponent()编码、后端rawurldecode()还原；Linux下需用escapeshellarg()防shell解析，Windows需避保留名并确保权限。
PHP中rename()对含加号（+）的文件名会出错
加号在URL编码中等价于空格，但PHP的rename()函数本身不解析URL编码——它直接操作文件系统。问题通常出现在Web上传或GET参数带+name.jpg时，服务端未解码就拼接路径，导致实际要操作的文件是"my+file.jpg"，而磁盘上可能是"my file.jpg"（浏览器把+当空格提交了），或者反过来：文件名真含字面量+，却被误当成空格处理。
先用urldecode()还原原始文件名
如果你是从$_GET、$_POST或$_FILES里拿到带+的文件名（比如filename=my+photo.jpg），必须先解码，否则rename()找的是错误路径。
if (isset($_GET['old']) && isset($_GET['new'])) {
$old_name = urldecode($_GET['old']); // 把 "my+photo.jpg" → "my photo.jpg"
$new_name = urldecode($_GET['new']);
$old_path = '/var/www/uploads/' . basename($old_name);
$new_path = '/var/www/uploads/' . basename($new_name);
if (file_exists($old_path)) {
rename($old_path, $new_path);
}
}
-
basename()必须套在urldecode()之后，否则+可能被当作路径分隔符干扰解析 - 别用
rawurldecode()替代——它不会把+转成空格，只处理%xx，而表单提交用的是application/x-www-form-urlencoded编码规则，+就是空格 - 如果文件名本身就要含字面量
+（如"v1.2+hotfix.zip"），上传前前端应使用encodeURIComponent()，后端用rawurldecode()，而非urldecode()
Linux下文件名含+本身是合法的，但shell操作要小心
Linux允许文件名含+，但通过exec()调用mv时，shell会把+当通配符或运算符（尤其在glob上下文中）。直接拼接字符串执行命令极易失败或误匹配。
$old = escapeshellarg('/path/to/file+with+.txt');
$new = escapeshellarg('/path/to/new+name.txt');
exec("mv $old $new", $output, $return_code);
- 必须用
escapeshellarg()包裹每个路径，它会自动加单引号并转义内部字符 - 不要用双引号拼接，避免变量插值引发额外解析
- 优先用PHP原生
rename()，它绕过shell，更安全、更快；仅当需保留ACL/扩展属性等rename()不支持的场景才走exec()
Windows对+无特殊含义，但要注意NTFS流和保留名
Windows文件系统本身接受+，但PHP在Windows上运行rename()时，若目标路径存在同名::$DATA流或碰上保留设备名（如AUX、CON），仍会失败。加号不是问题根源，但容易掩盖真正的问题。
立即学习“PHP免费学习笔记（深入）”；
- 检查目标路径是否已存在，
rename()在Windows上不覆盖，需先unlink() - 避免生成类似
"CON+.txt"这种名字——CON是保留名，加+不能绕过限制 - 用
is_writable()确认目录权限，Windows下常因UAC或继承权限缺失导致rename()静默失败
+本身不危险，危险的是混淆了编码层级：HTTP传输层、PHP输入处理层、文件系统层。漏掉一次urldecode()或错用escapeshellarg()，就可能让rename()对着不存在的路径徒劳尝试。 
