Windows 如何绕过批处理文件处理限制

我有一个Windows批处理文件，它处理给定目录中的所有文件。我有206783个文件需要处理：

for %%f in (*.xml) do call :PROCESS %%f
goto :STOP

:PROCESS
:: do something with the file
program.exe %1 > %1.new
set /a COUNTER=%COUNTER%+1
goto :EOF

:STOP
@echo %COUNTER% files processed

运行批处理文件时，会写入以下输出：

已处理65535个文件

作为处理的一部分，将为处理的每个文件创建一个输出文件，扩展名为

.new

。当我执行

dir*.new

时，它报告存在65535个文件

因此，看来我的命令环境对它可以识别的文件数量有一个硬限制，这个限制是64K-1

有没有办法扩展命令环境来管理64K-1以上的文件

如果不是，VBScript或JavaScript是否能够处理所有206783文件

我在Windows2003服务器上运行，企业版，32位

---

更新

看起来我的问题的根本原因是针对ZIP文件的内置Windows“提取”命令

我必须处理的文件是通过ZIP文件从另一个系统复制的。我的服务器没有安装ZIP实用程序，只安装了本机Windows命令。我右键点击ZIP文件，然后做了一个“全部提取…”的操作，这显然只是提取了前65535个文件

我下载并在服务器上安装了7-zip，解压缩了所有文件，我的批处理脚本按预期工作

如果内置了program.exe，则可以 重构它以接受参数，以便 你可以为了这个而放弃它 环路

您可以将输出文件存储到 不同的目录，而不是 在同一目录上创建

您可以将输出分组为 类别，因此输出较少 要处理的文件

两种选择：

1） 我建议您在.exe处理之后添加一个“move”，这样您的批处理文件可以重新启动，并且它将只处理仍在原始目录中的文件。这是一个好主意，不管实际的大小限制，这样你就不必冒着在批次中断或断电等情况下重新处理材料的风险

---

2） 使用另一种脚本语言，如windows Perl解释器，或者。

另一种选择可能是迭代

dir

的输出，而不是直接遍历文件。我通常不喜欢人们这样做，但很明显，标准的迭代习惯用法存在局限性

for /f "delims=" %%f in ('dir /b *.xml') do call :PROCESS %%f 

我目前正在尝试，但可能需要一段时间；刚刚用100k文件填充了一个目录

但是请记住，如果您使用的是光栅字体，那么使用命令的输出与Unicode有问题，因此请确保您的控制台窗口设置了Lucida console或其他TrueType字体。否则，Unicode字符将解析为问号或当前代码页中最接近的等效字符，但程序将找不到该文件

---

预计到达时间：显然，这不是问题所在。您的代码和我的测试代码都在Windows Server 2k3 R2、32位和Windows 7上循环执行

dir

输出300k文件。

program.exe做什么？？它是内部开发的吗？或者你下载的第三方工具？

program.exe

能否接受参数，例如

program.exe*.xml

？？你的输出真的必须是每1个输入文件1个文件吗？@ghostdog74；program.exe是内部开发的，不幸的是，它一次只能处理1个文件（我在QA工作，所以我在程序设计方面几乎没有发言权）。按照程序当前的设计方式，每个输入文件将创建一个输出文件。现在可能是学习PowerShell的时候了。从16位计算的时代起，您似乎达到了一个极限，这并不奇怪。1的旁注：在这种情况下，程序应该接受通配符，而不仅仅是一个文件名列表（由于批处理文件中的命令行限制为8190个字符，因此该列表将更早结束）.+1：我也有同样的想法，并对大约300K的文件进行了测试。工作正常。如果您将

DIR

命令的输出写入文件，然后处理其内容，您将获得更好的性能。@Frank和@Johannes；你们都是对的。事实证明，根本原因是针对ZIP文件的内置Windows“提取”命令存在问题。我必须处理的文件是ZIP文件；我的服务器没有安装ZIP实用程序，只安装了本机Windows命令。显然，“全部提取”只提取前65535个文件。我安装了7-zip，解压了所有文件，我的批处理脚本按预期工作；但愿我也能给@Frank一些信任。谢谢你们调查这些家伙，你们引导我朝着一个有助于解决我的问题的方向前进。@Patrick:嗯，我曾经看到有人在评论中对另一个人的问题/答案给出了一个有帮助的答案，并随机给出了答案。