php在windows下处理中文日志路径乱码，需统一编码：脚本保存为UTF-8无bom，路径用mb_convert_encoding转GBK；读取时用mb_detect_encoding探测并转UTF-8；避免glob()改用scandir()；写入前设mb_internal_encoding(‘UTF-8’)并校验编码。
PHP 删除日志文件时中文路径乱码
windows 系统下用 unlink() 或 file_exists() 处理含中文的 log 路径，常返回 false 或报错「No such file or Directory」，本质是 PHP 默认使用 ANSI（如 GBK）编码解析文件系统路径，而脚本源码或终端可能是 UTF-8。
- 确认当前脚本保存编码：用编辑器查是否为 UTF-8 无 BOM；若为 GBK，
unlink('日志_2024.log')可能成功，但换到 linux 就失效 - 统一转为系统本地编码再操作：Windows 下用
mb_convert_encoding($path, 'GBK', 'UTF-8')，Linux/macOS 通常无需转换（默认 UTF-8 文件系统） - 更稳妥的做法是避免中文路径：日志命名用时间戳+哈希，如
log_20240520_8a3f.log，彻底绕过编码争议
file_get_contents() 读取日志时出现乱码或截断
日志文件本身可能是 GBK、BIG5 或 UTF-8-BOM 编码，而 file_get_contents() 不做自动编码识别，直接按字节读取，后续用 strlen() 或正则匹配就容易出错。
- 先用
mb_detect_encoding(file_get_contents($log), ['UTF-8', 'GBK', 'BIG5'], true)探测（注意第三个参数设为true启用 strict 模式） - 探测不准时，优先检查文件 BOM：
hexdump -C $log | head -1，EF BB BF 是 UTF-8-BOM，反之可能是无 BOM 的 UTF-8 或其他编码 - 统一转成 UTF-8 再处理：
$content = mb_convert_encoding($raw, 'UTF-8', $detected)，之后所有字符串操作才可靠
用 glob() 匹配日志文件名时漏掉带中文的文件
glob('logs/*.log') 在 Windows 上默认不支持 UTF-8 路径通配，即使目录里有 错误_记录.log，也返回空数组。
- 不要依赖
glob()处理非 ASCII 文件名；改用scandir()+ 手动过滤：array_filter(scandir('logs'), fn($f) => pathinfo($f, PATHINFO_EXTENSION) === 'log') - 若必须用
glob()，确保 PHP 运行环境 locale 已设为中文：setlocale(LC_ALL, 'Chinese_China.936')（仅 Windows 有效），但该方式跨平台脆弱 - Linux 下若文件系统是 ext4 且挂载时用了
iocharset=utf8，glob()一般正常；否则仍建议回避
日志轮转时 fwrite() 写入内容变乱码
用 fopen($log, 'a') 追加写入中文，结果打开日志看到 符号，常见于脚本开头没声明输出编码，或 fopen 模式未指定文本模式（尤其 Windows）。
立即学习“PHP免费学习笔记（深入）”；
- 写入前明确设置内部编码：
mb_internal_encoding('UTF-8')，避免mb_strlen()等函数误判 - Windows 下用
fopen($log, 'ab')（二进制追加）比'a'更安全，防止换行符被意外转换 - 写入前校验内容编码：
if (mb_check_encoding($line, 'UTF-8') === false) { $line = mb_convert_encoding($line, 'UTF-8', 'auto'); }
实际清理脚本中，编码问题往往藏在路径构造、文件读取、通配匹配、写入四个环节里，任一环没对齐系统/文件/脚本三者编码，就可能悄无声息地删错文件、读歪内容、或生成无法解析的日志。