Windows 7 下 PHP 中文路径问题根源是系统 API 对宽字符支持缺陷及 PHP 路径解析未适配 UTF-16LE，需统一使用英文路径并显式转码文件操作。
PHP 脚本执行时报“failed to open stream”或空白页
Windows 7 下 PHP 读取中文路径（如 D:\网站\index.php）失败，常见现象是 include、require、file_get_contents 报错 failed to open stream: No such file or directory，或整个页面空白无输出。根本原因不是编码问题，而是 Windows API 层面对宽字符路径的处理缺陷 + PHP 内部路径解析逻辑在 Win7 上未完全适配 UTF-16LE。
Apache 或 Nginx 配置中 DocumentRoot 含中文导致 403/500 错误
把 DocumentRoot "D:\我的项目" 直接写进 httpd.conf 或 nginx.conf，Apache 可能启动失败并报 service error 1，Nginx 则常返回 403 或 “No input file specified.”。这不是权限问题，而是服务进程在初始化阶段调用 CreateDirectory 或 FindFirstFile 时，对非 ASCII 路径解析失败，直接拒绝加载该目录。
- Apache 2.4+ 在 Windows 上对中文路径支持极弱，即使文件系统权限全开，
<directory></directory>块中的路径含中文也会让Require all granted失效 - Nginx 的
root指令若含中文，其内部拼接SCRIPT_FILENAME时会生成乱码路径，FastCGI 传给 PHP 后无法定位文件 - IIS 的 FastCGI 映射若指向含中文的
php-cgi.exe路径，进程会静默退出，事件查看器只记 “FastCGI process exited unexpectedly”
php.ini 中 extension_dir、session.save_path 等路径含中文引发扩展加载失败
例如设 extension_dir = "D:\PHP扩展\ext"，PHP 启动时会找不到任何 .dll 文件，php -m 输出里看不到 mysqli、pdo_mysql；设 session.save_path = "C:\用户\张三\sessions"，则 session_start() 直接报 Warning 并返回 false。这是因为 PHP 初始化扩展和会话模块时，调用的是 ANSI 版本的 Windows API（如 LoadLibraryA），不支持 UTF-16 路径解码。
- 必须使用绝对英文路径，且避免空格和长路径（如
C:\php\ext、D:\php_sessions） -
extension_dir必须指向实际存在.dll文件的目录，不能是父级（如D:\php不行，得是D:\php\ext） - 修改后需重启 Web 服务（
iisreset /restart或net stop w3svc && net start w3svc），仅 reload 配置无效
PHP 脚本内 fopen()、scandir() 处理中文文件名时乱码或跳过
即使 Web 服务器能正常加载含中文路径的脚本，脚本里用 fopen('测试.txt', 'r') 或 scandir('D:/data') 仍可能失败。Win7 默认代码页是 GBK（936），而 PHP 内部字符串是 UTF-8，两者不转换就会导致路径字节错位。
立即学习“PHP免费学习笔记（深入）”；
- 不要依赖
mb_convert_encoding临时转码——它不改变底层 API 调用的编码方式 - 正确做法是：用
iconv('UTF-8', 'GBK', $filename)显式转为当前系统代码页再传入文件函数 - 更稳妥方案是彻底规避：重命名文件/目录为英文（如
test.txt、upload_dir），或改用 base64 编码文件名存储（base64_encode('测试.txt')） - 注意：
$_FILES['file']['name']上传来的中文名已是 UTF-8，但保存到磁盘前必须转码，否则move_uploaded_file会失败
Win7 对中文路径的支持是系统级残缺，不是配置能绕过的。所有路径——从 Web 服务器配置、PHP 安装目录、php.ini 设置，到脚本里硬编码的 include 和 fopen ——只要含中文，就等于埋了随时触发异常的地雷。最省事的修复，就是全部换成纯英文短路径。
