Windows 中区分大小写的目录路径

Question

我已经查看了询问目录/文件名在 Windows 环境中是否区分大小写的问题/答案，以及那些讨论区分大小写搜索需求的问题/答案 [通常在 Python 中，而不是 C]，所以我认为我了解基本事实，但没有任何帖子包括我的特定应用程序架构，以及我正在解决的问题。 那么，让我简要解释一下我所说的应用程序架构。该应用程序的核心是使用 Adob​​e AIR 构建的。是的，这意味着大部分 U/I 都涉及 Flex 框架，但我需要帮助解决的文件处理问题与应用程序的 Flex U/I 部分无关。 当我试图处理一个非常大的递归目录结构列表时，我通过一种行为良好的机制使用低级 C 运行时 API，AIR 为需要访问主机的 native 环境的情况提供这种机制。

我正在使用的函数套件是 FindFileFirst、FindFileNext 和 FindClose。如果我编写一个独立的测试程序，它会很好地列出目录、子目录和文件。目录和文件的大小写正确显示——就像它们在 Windows 资源管理器中或使用 dir 命令正确显示一样。

但是，如果我通过 Adob​​e ANE 界面启动完全相同的功能，我会收到完全相同的输出，只是所有目录名称都将缩减为小写。

现在，我应该澄清一下，当这段代码作为 native 扩展执行时，它并没有将数据传回 AIR，而是直接将结果输出到一个完全在 CRT 世界中打开和关闭的文件中，所以我们不是在谈论通过在两个不同世界之间传递文本或字节数组而引起的任何形式的通信困惑。

在不使用大量无关代码来搞砸这个论坛的情况下，我认为这些片段对任何能够帮助我的人都有帮助:

// This is where the output gets written.
FILE* textFile = _wfopen (L"Peek.txt", L"wt,ccs=UTF8");

WIN32_FIND_DATAW fdf;
HANDLE find = NULL;
wchar_t fullPath[2048];

// I am just showing the third argument as a literal to exemplify
// what, in reality is passed into the recursively-called function as
// a variable.
wsprintf (fullPath, L"\\\\?\\%ls\\*.*", L"F:\\");
hFind = FindFirstFile (fullPath, &fdf);

// After checking for success there appears a do..while loop
// inside which there is the expected check for the "." and ".."
// pseudo directories and a test of fdf.dwFileAttributes for
// file versus sub-directory.
// When the NextFile is a file a function is called to format
// the output in the textFile, like this:

fwprintf (textF, L"%ls\t%ls\t%2.2x\t%4d/%02d/%02d/%02d/%02d/%02d  \t%9ld.\n",
     parentPath, fdf.cFileName,
    (fdf.dwFileAttributes & 0x0f),
    st.wYear, st.wMonth, st.wDay,
    st.wHour, st.wMinute, st.wSecond,
    fSize);

此时 parentPath 将是一个连接的宽字符串并且 其他文件属性将是显示的类型。

因此，总结一下:如果我只编写一个独立测试，所有这些代码都能完美运行。但是，当代码作为从 Adob​​e ANE 调用的任务运行时，所有子目录部分的名称都缩减为小写。我已经测试了文件类型属性的每种组合——二进制和文本以及编码——UTF-8 和 UTF-16LE，但无论我选择什么配置，结果都是一样的:Standalone the API delivers case-correct strings, running作为从 AIR 调用的 dll 中的任务，相同的 API 仅提供小写字符串。

Answer 1

首先，感谢 Messrs Ogilvie 和 Passant 提供的有益建议。

其次，作为一个非常罕见的访客，我并不真正了解这里的协议(protocol)，我深表歉意。如果我应该将任何一个响应标记为有帮助并因此是正确的，那么让这些词至少反射(reflect)出这一事实。

我提供的答案是采纳上述建议后发现的。

一个。我发现了几种工具可以帮助我处理 .exe 和 .dll 文件的内容。我应该添加一些不属于原始帖子的细节:我一直故意使用 mingw-w64 工具链而不是 Visual Studio 进行此开发工作。因此，事实证明，ldd 和 dumpbin 都帮助我了解了这两个略有不同的构建环境是否可能给我留下了不同的依赖关系。

B.当我看到一个输出包含对 FindFirstFileExW 的引用时，我曾尝试使用该函数来解决我认为的问题，我认为我可能找到了导致不同结果的原因。事实上，那只是转移注意力，我并不是想以我的低水平经验和理解来浪费论坛的时间，但将这种故障排除方法作为对其他人的可能帮助似乎是有用的.

C.那么问题是什么？实际上，递归目录搜索的独立实现和 ANE 集成实现之间的代码存在细微差别。在生产 ANE 用例中，存在对返回结果应用过滤级别的逻辑。实际的应用程序允许用户通过查询父字符串的一部分以及文件名字符串本身来限定对重复文件的搜索。

在一个角落条件下，过滤器可能区分大小写或不区分大小写，我在使用 _wcslwr 时错误地认为该函数的行为与 AIR/Actionscript3 中提供的字符串处理方法的良好、符合 Unicode 的方式有关。我没有注意到该函数实际上将原始字符串替换为一个缩减为小写的字符串。

罪魁祸首不是用户错误，而是 Adob​​e 的 native 扩展互操作性对非标准 CRT 内核函数的任何不良链接。