php中rename()处理含%文件名失败的根本原因是%在shell、url编码或web服务器层被提前解析，而非php限制；应使用rawurldecode()解码http来源文件名，拼接绝对路径后直接调用rename()。
PHP中用 rename() 替换含 % 的文件名会失败？
直接调用 rename() 处理含百分号（%）的文件名，大概率失败，且不报错或只报 Warning: rename(): No such file or directory。根本原因不是 PHP 本身限制，而是 % 在 shell 层、URL 编码上下文或某些文件系统 API 中被提前解释——尤其当你从 URL、表单或日志里拿到原始文件名时，%20 这类编码可能已混入，或 % 被当成格式化占位符误解析。
先确认文件名里到底有没有真实 % 字符
别急着替换，先用 var_dump() 看清原始字节：
var_dump($filename); // 输出类似：string(15) "report%final.pdf" // 或更危险的：string(17) "report%20final.pdf"
如果看到 %20，说明是 URL 编码残留，必须先 urldecode()；如果看到裸 %（如 %final），则需转义或绕过解析层。
-
%是合法文件名字符（Linux/macOS/NTFS 都支持），但 PHP 的某些扩展（如glob()、scandir()）或 Web 服务器（Nginx/Apache 对 URI 的预处理）可能提前截断或拒绝 - Windows 下
%本身不禁止，但 cmd/powershell 会尝试展开环境变量（如%PATH%），若你用exec()调用 shell 命令重命名，就必然出错 - 最稳妥路径：全程用 PHP 原生函数操作，避免经过 shell
安全替换含 % 的文件名的三步法
核心原则：不依赖外部命令，不拼接字符串进 shell，对 % 不做特殊转义（它本就不需转义），只确保路径字节准确。
立即学习“PHP免费学习笔记（深入）”；
- 用
rawurldecode()处理从 HTTP 请求来的文件名（比urldecode()更严格，能处理%25→%） - 用
realpath()或手动拼接绝对路径，避免相对路径引发的解析歧义 - 直接调用
rename($old_path, $new_path)，两个参数都传完整、未被 shell 解析过的字符串
示例：
$original = "data%report.pdf"; // 来自 $_POST['filename'] 或数据库
$decoded = rawurldecode($original); // 若原串含 %25，则此步必要
$old_path = __DIR__ . '/uploads/' . $decoded;
$new_path = __DIR__ . '/uploads/' . 'clean_report.pdf';
if (rename($old_path, $new_path)) {
echo "OK";
} else {
error_log("rename failed: " . $old_path . " → " . $new_path);
// 检查 error_log 输出的路径是否含意外空格或不可见字符
}
为什么不用 str_replace('%', '\%', $name)？
加反斜杠毫无意义。PHP 的 rename() 不走 shell，不需要 shell 转义；文件系统根本不认 \% 这种写法——它要么找名为 \% 的文件（不存在），要么因路径非法失败。真正要防的是：% 出现在 shell 命令中（如 exec("mv '$old' '$new'")），此时应改用 escapeshellarg()，但更推荐彻底弃用 exec()。
容易被忽略的一点：Web 服务器（尤其是 Nginx）默认会 decode URI，再交给 PHP；如果你在 location 块里用了 rewrite 或 try_files，可能已二次 decode，导致 %2520 变成 %20 再变成空格——这种嵌套编码问题，必须在入口统一 rawurldecode() 一次并仅一次。
