首先我问过：ftp directory listing timeout. Huge number of subdirs。我得到了答案。
仍然因为我可以在目录中拥有数十万个FTP对象，所以扫描它可能需要很长时间。但是我认为有可能检索所有以'A'开头然后'B'的对象等等......当它检索目录时，它可以开始在另一个线程上处理它们，而不必等到它获得整个列表
是否可以使用标准FtpWebRequest？
答案 0 :(得分：7)
FTP specification (RFC 3659)的最新更新明确禁止它。来自section 2.2.2 of that specification, titled "Wildcarding"（强调我的）：
对于本规范中定义的命令，所有路径名都是 按字面意思对待。也就是说，对于作为参数给出的路径名 一个命令，其名称与给定的路径名相同的文件是 默示。路径名中的任何字符都不能被视为特殊字符或 “魔法”，因此没有模式匹配（除了完全相等） 在给定的路径名和NVFS中存在的文件之间 允许服务器-FTP。
需要某种形式模式的客户 匹配功能必须获得相关的列表 目录或目录，并实现自己的文件名 选择程序。
也就是说，如果您的服务器支持它，您仍然可以使用FtpWebRequest class，但您必须自己处理响应以处理项目列表，因为.NET类将无法理解您的特定于服务器的扩展。
答案 1 :(得分：0)
FTP规范说文件列表命令（LIST，NLIST，MLSD等）的参数是路径名。所以不应该没有任何通配符。
RFC 959（LIST + NLIST）：
<强> 2.2。术语
...
pathname路径名被定义为必须的字符串 用户输入文件系统以识别文件。 路径名通常包含设备和/或目录名称，以及 文件名规范。 FTP尚未指定标准 路径名约定。每个用户都必须遵循文件命名 传输中涉及的文件系统的约定。
...
<强> 5.3.1。 FTP命令
...
LIST [<SP> <pathname>] <CRLF>
NLST [<SP> <pathname>] <CRLF>
RFC 3659（MLSD）：
<强> 2.2.2。通配
对于本规范中定义的命令，所有路径名都是 按字面意思对待。也就是说，对于作为参数给出的路径名 命令，该文件的名称与给定的路径名相同 隐含着。路径名中的任何字符都不能被视为 特殊或“魔法”，因此没有模式匹配（除了精确的 给定的路径名和存在的文件之间的相等性 允许使用服务器FTP的NVFS。
...
<强> 7.1。 MLSx请求的格式
...
MLSx命令的语法是：
mlst = "MLst" [ SP pathname ] CRLF mlsd = "MLsD" [ SP pathname ] CRLF
实际上，虽然许多FTP服务器在参数中支持wilcards。但是由于规范不允许这样做，显然没有支持的通配符的设定标准。
vsftpd 支持*，?和{} LIST。 vsftpd不支持现代MLSD。
proftpd 支持*，?和[]。但仅针对LIST。它明确地不允许带有现代MLSD的通配符带注释：
RFC3659明确不支持glob字符。所以警告 这个，但让命令继续保持原样。
pureftpd 支持*和?的{{1}}，[]和LIST。
FileZilla服务器仅支持MLSD和*的{{1}}。
但总的来说，你不应该依赖FTP服务器来支持任何通配符。
唯一可靠的方法是检索完整的目录列表并在本地过滤文件。例如，您可以使用正则表达式（Regex class）