不安全，str_replace和preg_replace直接处理多语言文件名易出错：utf-8截断、大小写误匹配、编码混淆；应优先用mbstring函数并结合pathinfo拆解文件名，预检目标路径防覆盖，控制长度，统一大小写，并按路径结构精准替换语言码。
PHP 中用 str_replace 或 preg_replace 替换文件名是否安全？
不安全，直接用 str_replace 处理多语言文件名极易出错。比如把 "café.jpg" 中的 "é" 当普通 ASCII 处理，或在 UTF-8 环境下用 substr 截断导致乱码；更严重的是，某些系统（如 Windows）对大小写不敏感，但 PHP 字符串函数默认区分大小写，str_replace('EN', 'ZH', 'english.txt') 可能误伤 "backend" 里的 "EN"。
真正该做的是：先确认原始文件名编码（基本都是 UTF-8），再用 mbstring 函数操作：
mb_internal_encoding('UTF-8');
$newName = mb_ereg_replace('^en_', 'zh_', $oldName); // 安全匹配前缀
// 或更稳妥：用 basename + pathinfo 拆解，只替换文件名主体，不动扩展名
$info = pathinfo($oldName);
$base = $info['filename'];
$ext = $info['extension'];
$replacedBase = str_replace('_en', '_zh', $base); // 此处若含非 ASCII，必须用 mb_* 版本
$newName = $replacedBase . '.' . $ext;批量重命名多语言文件时，怎么避免覆盖或冲突？
常见错误是直接 rename() 而不检查目标路径是否存在，尤其多语言场景下："about_en.html" → "about_zh.html"，但如果已有 "about_zh.html"，就会被静默覆盖。
- 必须用
file_exists()预检目标路径，建议加时间戳或哈希后缀防撞：$newPath = $dir . '/' . $base . '_zh_' . substr(md5($oldName), 0, 6) . '.' . $ext; - Windows 下注意长文件名限制（260 字符），多语言字符（如日文假名）占 3 字节/字符，容易超限，建议提前用
mb_strlen($name, 'UTF-8')控制总长度 ≤ 100 - Linux/macOS 区分大小写，但用户上传的文件名可能混用
"EN"/"en"/"En"，统一转小写再替换更可靠：$safeBase = mb_strtolower($base, 'UTF-8');
本地化文件名替换要适配哪些实际路径结构？
真实项目里文件名不会孤立存在，而是嵌套在特定约定路径中，硬编码替换会失效。例如：
立即学习“PHP免费学习笔记（深入）”；
-
/locales/en/messages.php→/locales/zh/messages.php：应替换路径段，不是文件名 -
/assets/img/product_en.png→/assets/img/product_zh.png：需保留目录层级，只动最后一级文件名 -
config_i18n_en.json→config_i18n_zh.json：下划线位置不固定，正则比str_replace更准：preg_replace('/_([a-z]{2})\.json$/i', '_zh$1.json', $file)不行，得用'/_([a-z]{2})(?=\.)/i'精确锚定语言码
推荐封装一个函数，接受旧语言码、新语言码和完整路径，自动识别并替换：
function replaceLangCodeInPath($path, $from, $to) {
return preg_replace(
'/(?<=\/|_)' . preg_quote($from, '/') . '(?=_|\.[a-zA-Z0-9]+$)/i',
$to,
$path
);
}
// 使用：replaceLangCodeInPath('pages/about_en.php', 'en', 'ja'); // → about_ja.php为什么不能依赖 setlocale() 来处理文件名替换？
setlocale(LC_ALL, 'zh_CN.UTF-8') 对文件名字符串操作完全无效——它只影响 strftime()、strcoll() 等少数函数，跟 str_replace、正则、路径拼接零关系。很多开发者误以为设了 locale 就能“自动支持中文”，结果在 CentOS 服务器上因缺失 locale 包导致 setlocale() 返回 false，后续逻辑照常执行却悄悄出错。
真正起作用的是：明确指定编码（mb_internal_encoding('UTF-8')）、用 mb_* 系列函数、所有 I/O 操作（fopen, file_get_contents）显式声明 encoding 参数（如果支持），以及 Web 服务器（Nginx/Apache）配置中确保 charset utf-8 生效。
最易忽略的一点：PHP 的 opcache 默认不缓存包含非 ASCII 文件名的脚本，但如果你用 include 动态加载本地化文件，而文件名含中文或日文，opcache.revalidate_path=0 会导致缓存失效或报错，必须关掉或改用绝对路径加载。
