PHP无法直接转换文件夹编码，本质是系统路径编码与PHP环境不匹配；iconv()等函数仅处理字符串，而文件系统API需字节级匹配；应优先通过系统挂载参数、locale设置或COM扩展解决编码问题。
PHP 本身不直接提供「转换文件夹编码」的函数，所谓“文件夹乱码”，本质是操作系统层面的路径编码与 PHP 当前运行环境（尤其是 locale 和文件系统 API）不匹配导致的——常见于 Windows（GBK/GB2312）与 Linux/macOS（UTF-8）混用，或 FTP/Samba 挂载时编码未对齐。
为什么 iconv() 或 mb_convert_encoding() 直接处理文件夹名会失败
这两个函数只转换字符串编码，但文件系统 API（如 scandir()、opendir()、rename()）传入的路径字符串，必须和底层系统期待的字节序列完全一致。如果原始目录名在磁盘上是 GBK 编码的字节，而你用 UTF-8 字符串去调用 scandir()，PHP 会把 UTF-8 字节当作乱码路径发给内核，直接返回 false 或空数组。
-
scandir("测试目录")在 GBK 环境下实际发送的是\xb2\xe2\xca\xd4\xc4\xbf\xc2\xbc；若当前脚本是 UTF-8，该字符串会被解释为 4 个非法 UTF-8 序列，系统找不到路径 -
iconv("UTF-8", "GBK", "测试目录")只有在你知道原始字符串来源编码时才有效；但文件夹名是从系统读出的，不是你构造的字符串 - Linux 下 ext4 默认按字节处理文件名，不校验编码；Windows NTFS 内部用 UTF-16，但 WinAPI 的 ANSI 版本（如
FindFirstFileA）会依赖当前GetACP()
Windows 下 PHP 读取 GBK 中文文件夹的实操方案
关键不是“转编码”，而是让 PHP 的文件操作走宽字符（Unicode）路径，绕过 ANSI 层级的编码陷阱。PHP 7.4+ 在 Windows 上已默认启用 UNICODE 支持，但仍需注意：
- 确保 Web 服务器（如 Apache、Nginx）和 PHP 进程的控制台代码页为 UTF-8：
chcp 65001（仅调试时有效，生产环境靠setlocale(LC_ALL, "Chinese_China.65001")） - 用
scandir()前，先用mb_internal_encoding("UTF-8")统一内部编码，避免mb_*函数误判 - 若仍报错，改用 COM 扩展（需开启
extension=php_com_dotnet.dll）：$fso = new COM("Scripting.FileSystemObject");—— COM 自动桥接 Unicode，不经过 PHP 的 C 层路径解析
$folder = $fso->GetFolder("D:\\中文目录");
foreach ($folder->Files as $file) { echo $file->Name; }
Linux/macOS 下遇到挂载 SMB/NFS 中文文件夹乱码
问题根源在挂载参数，而非 PHP。例如挂载 Windows 共享时，若服务端用 GB2312 发送文件名，客户端必须显式声明：
mount -t cifs //192.168.1.100/share /mnt/win -o username=user,password=pass,iocharset=utf8或更稳妥地指定服务端编码：
iocharset=gb2312,codepage=cp936
立即学习“PHP免费学习笔记（深入）”；
- 挂载后检查：
ls /mnt/win能否正常显示中文？不能则 PHP 必然也读不到——先解决 shell 层面的显示，再谈 PHP - PHP 中统一用 UTF-8 处理：
scandir("/mnt/win")返回的文件名已是 UTF-8 字节，可直接mb_strlen($name, "UTF-8")或json_encode($name) - 避免用
exec("ls /mnt/win")解析输出：shell 环境变量（如LANG）可能与 PHP 不一致，造成二次乱码
真正棘手的是跨平台迁移场景：一个在 Windows 上创建的 GBK 编码目录，拷贝到 Linux 后，文件系统不自动重编码，ls 显示为乱码，PHP scandir() 返回的也是原始 GBK 字节——此时你得先确认这些字节确实是 GBK，再用 iconv("GBK", "UTF-8", $raw_bytes) 转换，但必须确保没有损坏（GBK 中的 0x5c 会和路径分隔符 \ 冲突）。这种修复不可逆，且极易出错。
