我正在编写一个文件管理器，需要扫描目录并处理重命名可能包含多字节字符的文件。我正在 Windows/Apache PHP 5.3.8 上本地处理它，目录中有以下文件名:

• 文件名.jpg
• имяфайла.jpg
• 文件名.jpg
• פילענאַמע.jpg
• 文件名.jpg

在实时 UNIX 服务器上进行测试可以正常工作。使用 glob('./path/*') 在 Windows 上进行本地测试仅返回第一个，filename.jpg。

使用 scandir()，至少会返回正确数量的文件，但我得到的名称类似于 ?????????.jpg(注意: 这些是常规问号，而不是 � 字符。

我最终需要编写一个“搜索”功能来递归搜索整个树中与模式匹配或具有特定文件扩展名的文件名，我假设 glob() 将是正确的工具，而不是扫描所有文件并在应用程序代码中进行模式匹配和数组构建。如果需要，我愿意接受其他建议。

假设这是一个常见问题，我立即搜索了 Google 和 Stack Overflow，但没有发现任何相关内容。这是 Windows 问题吗？ PHP的缺点？解决方案是什么:有什么我可以做的吗？

附录:不确定这有多相关，但 file_exists() 也为这些文件返回 FALSE，传入完整的绝对路径(使用 Notepad++，php文件本身是 UTF-8 编码，没有 BOM)。我确定路径是正确的，因为没有多字节字符的相邻文件返回 TRUE。

编辑:glob() 可以找到一个名为filename-äöü.jpg的文件。以前在我的 .htaccess 文件中，我有 AddDefaultCharset utf-8，这是我之前没有考虑过的。 filename-äöü.jpg 打印为 filename-���.jpg。删除该 htaccess 行的唯一效果似乎是现在文件名打印正常。

我已经完全删除了 .htaccess 文件，这是我实际的完整测试脚本(我从原始帖子中更改了几个文件名):

print_r(scandir('./uploads/')); 
print_r(glob('./uploads/*'));

在 Windows 上本地输出:

Array
(
    [0] => .
    [1] => ..
    [2] => ??? ?????.jpg
    [3] => ???.jpg
    [4] => ?????????.jpg
    [5] => filename-äöü.jpg
    [6] => filename.jpg
    [7] => test?test.jpg
)
Array
(
    [0] => ./uploads/filename-äöü.jpg
    [1] => ./uploads/filename.jpg
)

远程 UNIX 服务器上的输出:

Array
(
    [0] => .
    [1] => ..
    [2] => filename-äöü.jpg
    [3] => filename.jpg
    [4] => test이test.jpg
    [5] => имя файла.jpg
    [6] => פילענאַמע.jpg
    [7] => 文件名.jpg
)
Array
(
    [0] => ./uploads/filename-äöü.jpg
    [1] => ./uploads/filename.jpg
    [2] => ./uploads/test이test.jpg
    [3] => ./uploads/имя файла.jpg
    [4] => ./uploads/פילענאַמע.jpg
    [5] => ./uploads/文件名.jpg
)

由于这是一个不同的服务器，无论平台如何 - 配置可能不同，所以我不确定该怎么想，而且我还不能将它完全固定在 Windows 上(可能是我的 PHP 安装、ini 设置或 Apache 配置)。有什么想法吗？

最佳答案

看起来 glob() 函数取决于您的 PHP 副本是如何构建的，以及它是否使用支持 unicode 的 WIN32 API 进行编译(我不相信标准的构建。

参照。 http://www.rooftopsolutions.nl/blog/filesystem-encoding-and-php

摘自文章评论:

Philippe Verdy 2010-09-26 8:53 am

The output from your PHP installation on Windows is easy to explain : you installed the wrong version of PHP, and used a version not compiled to use the Unicode version of the Win32 API. For this reason, the filesystem calls used by PHP will use the legacy "ANSI" API and so the C/C++ libraries linked with this version of PHP will first try to convert yout UTF-8-encoded PHP string into the local "ANSI" codepage selected in the running environment (see the CHCP command before starting PHP from a command line window)

Your version of Windows is MOST PROBABLY NOT responsible of this weird thing. Actually, this is YOUR version of PHP which is not compiled correctly, and that uses the legacy ANSI version of the Win32 API (for compatibility with the legacy 16-bit versions of Windows 95/98 whose filesystem support in the kernel actually had no direct support for Unicode, but used an internal conversion layer to convert Unicode to the local ANSI codepage before using the actual ANSI version of the API).

Recompile PHP using the compiler option to use the UNICODE version of the Win32 API (which should be the default today, and anyway always the default for PHP installed on a server that will NEVER be Windows 95 or Windows 98...)

Then Windows will be able to store UTF-16 encoded filenames (including on FAT32 volumes, even if, on these volumes, it will also generate an aliased short name in 8.3 format using the filesystem's default codepage, something that can be avoided in NTFS volumes).

All what you describe are problems of PHP (incorrect porting to Windows, or incorrect system version identification at runtime) : reread the README files coming with PHP sources explaining the compilation flags. I really think that the makefile on Windows should be able to configure and autodetect if it really needs to use ONLY the ANSI version of the API. If you are compiling it for a server, make sure that the Configure script will effectively detect the full support of the UNICODE version of the Win32 aPI and will use it when compiling PHP and when selecting the runtime libraries to link.

I use PHP on Windows, correctly compiled, and I absolutely DON'T know the problems you cite in your article.

Let's forget now forever these non-UNICODE versions of the Win32 API (which are using inconsistantly the local ANSI codepage for the Windows graphical UI, and the OEM codepage for the filesystem APIs, the DOS/BIOS-compatible APIs, the Console APIs) : these non-Unicode versions of the APIs are even MUCH slower and more costly than the Unicode versions of the APIs, because they are actually translating the codepage to Unicode before using the core Unicode APIs (the situation on Windows NT-based kernels is exactly the reverse from the situation on versions of Windows based on a virtual DOS extender, such as Windows 95/98/ME).

When you don't use the native version of the API, your API call will pass through a thunking layer that will transcode the strings between Unicode and one of the legacy ANSI or CHCP-selected OEM codepages, or the OEM codepage hinted on the filesystem: this requires additional temporary memory allocation within the non-native version of the Win32 API. This takes additional time to convert things before doing the actual work by calling the native API.

In summary: the PHP binary you install on Windows MUST be different depending on if you compiled it for Windows 95/98/SE (or the old Win16s emulation layer for Windows 3.x, which had a very mimimum support of UTF-8, only to support the Unicode subsets of Unicode used by the ANSI and OEM codapges selected when starting Windows from a DOS extender) or if it was compiled for any other version of Windows based on the NT kernel.

The best proof that this is a problem of PHP and not Windows, is that your weird results will NOT occur in other languages like C#, Javascript, VB, Perl, Ruby... PHP has a very bad history in tracking versions (and too many historical source code quirks and wrong assumptions that should be disabled today, and an inconsistant library that has inherited all those quirks initially made in old versions of PHP for old versions of Windows that are even no longer officially supported, by Microsoft or even by PHP itself !).

In other words : RTM ! Or download and install a binary version of PHP for Windows precompield with the correct settings : I really think that PHP should distribute Windows binaries already compiled by default for the Unicode version of the Win32 API, and using the Unicode version of the C/C++ libraries : internally the PHP code will convert its UTF-8 strings to UTF-16 before calling the Win32 API, and back from UTF-16 to UTF-8 when retrieving Win32 results, instead of converting PHP's internal UTF-8 strings back/to the local OEM codepage (for the filesystem calls) or the local ANSI codepage (for all other Win32 APIs, including the registry or process).

关于php - glob() 在 Windows 上找不到带有多字节字符的文件名？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9659600/