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

Question

我已经查看了询问目录/文件名在 Windows 环境中是否区分大小写的问题/答案，以及那些讨论区分大小写搜索需求的问题/答案[通常在 Python 中，而不是在 C 中]，所以我想我理解必不可少的事实，但没有一个帖子包含我的特定应用程序架构，以及我正在解决的问题。所以，让我简要解释一下我所说的应用程序架构。该应用程序的核心是使用 Adob​​e AIR 构建的。是的，这意味着大部分 U/I 都涉及 Flex 框架，但我需要帮助的文件处理问题不依赖于应用程序的 Flex U/I 部分。当我试图处理一个非常大的递归目录结构列表时，

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

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

现在，我应该澄清一下，当这段代码作为 Native Extension 执行时，它不是将数据传回 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，但无论我选择什么配置，结果都保持不变：独立 API 提供大小写正确的字符串，运行作为从 AIR 调用的 dll 中的任务，相同的 API 仅提供小写字符串。

Answer 1

首先，我感谢奥美先生和帕桑先生提出的有益建议。

其次，作为一个不常来访的人，我很抱歉不太了解这里的协议。如果我应该将任何一个回答标记为有帮助并因此是正确的，那么这些词至少反映了这一事实。

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

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

B. 当我看到一个输出包含对 FindFirstFileExW 的引用（我曾经尝试过该函数来解决我认为的问题）时，我想我可能已经找到了不同结果的原因。在这种情况下，这只是一个转移注意力的事情，我并不是想以我的低水平经验和理解来浪费论坛的时间，但记录这种故障排除方法似乎很有用，可以为其他人提供可能的帮助。

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

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

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