Question

我已经查看了有关在Windows环境中目录/文件名是否区分大小写的问题/解答，以及讨论了区分大小写搜索需求的问题（通常在Python中，而不是在C中），所以我想了解基本事实，但是没有任何帖子包含我的特定应用程序体系结构以及我正在解决的问题。因此，让我简要解释一下我正在说的应用程序体系结构。该应用程序的核心是使用Adobe AIR构建的。是的，这意味着很多U / I都涉及Flex框架，但是我需要帮助的文件处理问题并不依赖于应用程序的Flex U / I部分。当我尝试处理大量的递归目录结构列表时，我正在通过行为良好的机制使用低级C运行时API，AIR为需要访问主机的本机环境的情况提供了AIR。

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

但是，如果我通过Adobe ANE界面启动了完全相同的功能，那么我收到的输出将完全相同，不同之处在于所有目录名称都将减小为小写。

现在，我应该澄清一下，当此代码作为本机扩展执行时，它没有将数据传递回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将是一个连接的宽字符串，并且其他文件属性将为所示类型。

因此，总结一下：如果我只是编写一个独立的测试，那么所有这些代码都可以完美地工作。但是，当代码作为从Adobe ANE调用的任务运行时，所有子目录部分的名称均减小为小写。我已经测试了文件类型属性的每种组合-二进制，文本和编码-UTF-8和UTF-16LE，但是无论我选择哪种配置，结果都保持不变：独立的API提供了大小写正确的字符串，正在运行作为从AIR调用的dll中的一项任务，相同的API仅提供小写的字符串。

Answer 1

首先，我感谢Ogilvie和Passant先生的有用建议。

其次，我很抱歉没有以很少的访问者身份真正了解协议。如果我应该将任何一种回答都标记为有帮助，因此是正确的，那么让这些词至少反映出这一事实。

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

A。我发现了几种工具，可以帮助我处理.exe和.dll文件的内容。我应该添加一些原始发布所没有的细节：我有意一直在使用mingw-w64工具链而不是Visual Studio进行此开发工作。因此，事实证明，ldd和dumpbin都帮助我了解了两个稍微不同的构建环境是否可能使我具有不同的依赖性。

B。当我看到一个输出包含对FindFirstFileExW的引用时，我曾尝试使用该函数来解决我认为的问题，我认为我可能已经找到了导致不同结果的原因。在这种情况下，这只是一个红色的骗子，我并不是要用我的低水平的经验和理解来浪费论坛的时间，但是将这种故障排除方法作为对其他人的一种帮助可能是有用的。

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

在一个极端的情况下，筛选器可能区分大小写或不区分大小写，并且我误用了_wcslwr，因为该函数表现出AIR / Actionscript3中提供字符串处理方法的一种很好的，与Unicode兼容的方式。我没有注意到该函数实际上是将原字符串替换为小写的原位替换。

用户错误，而不是Adobe的Native Extension互操作性非正常地链接了非标准CRT内核功能，是罪魁祸首。

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

1 个答案: