Windows FINDSTR命令已被严格记录。通过FINDSTR /?或HELP FINDSTR可以使用非常基本的命令行帮助，但它严重不足。在https://docs.microsoft.com/zh-cn/windows-server/administration/windows-commands/findstr上有更多在线文档。

文档中甚至没有暗示许多FINDSTR功能和限制。没有事先的知识和/或仔细的实验??，也无法预料到它们。

因此，问题是-未记录的FINDSTR有哪些功能和限制？

这个问题的目的是提供许多未记录功能的一站式存储库，以便：

A)开发人员可以充分利用其中的功能。

B)开发人员不会浪费时间去思考为什么某些东西在看起来应该正确时不起作用。

在进行响应之前，请确保您了解现有文档。如果该信息包含在帮助中，则该信息不属于此处。

这也不是显示FINDSTR有趣用途的地方。如果有逻辑的人可以根据本文档来预期FINDSTR特定用法的行为，那么它不属于此处。

同样，如果有逻辑的人可以根据任何现有答案中包含的信息来预期特定用法的行为，那么同样，它也不属于此处。

前言

该答案中的许多信息都是基于在Vista机器上运行的实验收集的。除非另有明确说明，否则我尚未确认该信息是否适用于其他Windows版本。

FINDSTR输出
该文档从不费心去解释FINDSTR的输出。它暗示了印有匹配线的事实，仅此而已。

匹配行输出的格式如下：

文件名：行号：lineOffset：文本

哪里

fileName：=包含匹配行的文件的名称。如果请求是显式的单个文件请求，或者搜索管道输入或重定向输入，则不打印文件名。打印时，fileName将始终包含提供的任何路径信息。如果使用/S选项，将添加其他路径信息。打印的路径始终相对于提供的路径，如果没有提供，则相对于当前目录。

注意-使用非标准(且文献记录不充分)通配符<和>来搜索多个文件时，可以避免使用文件名前缀。这些通配符如何工作的确切规则可以在这里找到。最后，您可以看一下非标准通配符如何与FINDSTR一起使用的示例。

lineNumber：=匹配行的行号，以十进制值表示，其中1表示输入的第一行。仅在指定/N选项时打印。

lineOffset：=匹配行开头的十进制字节偏移量，其中0表示第一行的第一个字符。仅在指定/O选项时打印。这不是行内匹配的偏移量。它是从文件开头到行开头的字节数。

text =匹配行的二进制表示形式，包括任何和/或。二进制输出不遗余力，因此与所有行匹配的此示例将生成原始文件的精确二进制副本。

大多数控制字符和许多扩展的ASCII字符在XP上均显示为点
XP上的FINDSTR在屏幕上将匹配行中的大多数不可打印的控制字符显示为点(句点)。以下控制字符是例外；它们将自己显示：0x09制表符，0x0A LineFeed，0x0B垂直制表符，0x0C换页，0x0D回车。

XP FINDSTR还可以将许多扩展的ASCII字符转换为点。在XP上显示为点的扩展ASCII字符与在命令行上提供时进行转换的扩展ASCII字符相同。请参阅本文后面的"命令行参数的字符限制-扩展ASCII转换"部分

如果输出通过管道传输，重定向到文件或在FOR IN()子句中，则控制字符和扩展ASCII不会在XP上转换为点。

Vista和Windows 7始终将所有字符显示为自己，而不是点。

返回码(ERRORLEVEL)

要搜索的数据源(基于Windows 7的测试进行了更新)
Findstr只能从以下来源之一搜索数据：

参数/选项优先于重定向，重定向优先于管道数据。

文件名参数和/F:file可以组合使用。可以使用多个文件名参数。如果指定了多个/F:file选项，则仅使用最后一个。文件名参数中允许使用通配符，但/F:file所指向的文件中不允许使用通配符。

搜索字符串的来源(根据Windows 7的测试进行了更新)
/G:file和/C:string选项可以组合使用。可以指定多个/C:string选项。如果指定了多个/G:file选项，则仅使用最后一个。如果使用/G:file或/C:string，则所有非选项参数均假定为要搜索的文件。如果既不使用/G:file也不使用/C:string，则第一个非选项参数将被视为以空格分隔的搜索项列表。

使用/F:file选项时，文件名中不能包含引号。
文件名可能包含空格和其他特殊字符。大多数命令都要求使用此类文件名。但是FINDSTR /F:files.txt选项要求不能引用files.txt中的文件名。如果使用引号将找不到该文件。

BUG-短8.3文件名可能会破坏/D和/S选项
与所有Windows命令一样，FINDSTR在查找要搜索的文件时将尝试同时匹配长名称和短8.3名称。假设当前文件夹包含以下非空文件：

以下命令将成功找到所有3个文件：

b.txt2匹配，因为相应的短名称B9F64~1.TXT匹配。这与所有其他Windows命令的行为一致。

但是/D和/S选项的错误导致以下命令仅找到b1.txt

该错误会阻止在同一目录中找到b.txt2以及在b.txt2之后排序的所有文件名。找到其他之前排序的文件，例如a.txt。触发错误后，以后会丢失其他排序文件，例如d.txt。

搜索的每个目录均被独立对待。例如，/S选项将在未能在父文件夹中找到文件后成功开始在子文件夹中搜索，但是一旦该错误导致子文件夹中缺少简短的文件名，则该子文件夹中的所有后续文件都会也想念。

如果在禁用了NTFS 8.3名称生成的计算机上创建了相同的文件名，这些命令将无错误。当然不会找到b.txt2，但是会正确找到c.txt。

并非所有的短名称都触发该错误。我见过的所有错误行为实例都涉及一个扩展名，该扩展名超过3个字符，且带有一个简短的8.3名称，该名称的开头与不需要8.3名称的普通名称相同。

该错误已在XP，Vista和Windows 7上得到确认。

不可打印字符和/P选项
/P选项使FINDSTR跳过包含以下任何十进制字节码的任何文件：
0-7、14-25、27-31。

换句话说，/P选项将仅跳过包含不可打印控制字符的文件。控制字符是小于或等于31(0x1F)的代码。 FINDSTR将以下控制字符视为可打印的：

所有其他控制字符都被视为不可打印字符，其存在会导致/P选项跳过文件。

管道输入和重定向输入可能附加了
如果输入是通过管道输入的，并且流的最后一个字符不是，则FINDSTR将自动将追加到输入中。在XP，Vista和Windows 7上已经确认了这一点。(我以前认为Windows管道负责修改输入，但是后来我发现FINDSTR实际上是在进行修改。)

Vista上的重定向输入也是如此。如果用作重定向输入的文件的最后一个字符不是，则FINDSTR将自动将附加到输入中。但是，XP和Windows 7不会更改重定向的输入。

如果重定向的输入不以
结尾，则FINDSTR在XP和Windows 7上挂起
在XP和Windows 7上，这是一个令人讨厌的"功能"。如果用作重定向输入的文件的最后一个字符未以结尾，则FINDSTR一旦到达重定向文件的末尾，将无限期挂起。

如果管道数据的最后一行由单个字符组成，则可以忽略
如果输入是管道输入，并且最后一行由单个字符组成，且后跟，则FINDSTR将完全忽略最后一行。

示例-第一个具有单个字符且没有的命令无法匹配，但是第二个具有2个字符的命令可以正常工作，第三个具有一个字符且以换行符结尾的命令也可以。

DosTips用户Sponge Belly报道了新的findstr错误。已在XP，Windows 7和Windows 8上得到确认。尚未听说过Vista。 (我不再需要测试Vista)。

选项语法
选项可以使用/或-作为前缀
选项可以在单个/或-之后串联。但是，级联选项列表最多可以包含一个多字符选项，例如OFF或F :，并且多字符选项必须是列表中的最后一个选项。

以下是表示以任何顺序包含" hello"和"再见"的任何行的不区分大小写的正则表达式搜索的所有等效方法

搜索字符串长度限制
在Vista上，单个搜索字符串的最大允许长度为511字节。如果任何搜索字符串超过511，则结果为ERRORLEVEL 2的FINDSTR: Search string too long.错误。

当执行正则表达式搜索时，最大搜索字符串长度为254。长度在255到511之间的正则表达式将导致FINDSTR: Out of memory错误，而ERRORLEVEL2。正则表达式长度大于511将导致FINDSTR: Search string too long.错误。

在Windows XP上，搜索字符串的长度显然较短。 Findstr错误："搜索字符串太长"：如何在" for"循环中提取和匹配子字符串？
文字搜索和正则表达式搜索的XP限制均为127个字节。

线长限制
指定为命令行参数或通过/ F：FILE选项的文件没有已知的行长限制。已成功对不包含单个的128MB文件运行搜索。

管道数据和重定向的输入每行限制为8191字节。此限制是FINDSTR的"功能"。它不是管道或重定向所固有的。使用重定向的stdin或管道输入的FINDSTR将永远不匹配任何> = 8k字节的行。 > = 8k的行会向stderr生成一条错误消息，但是如果在至少一个文件的至少一行中找到了搜索字符串，则ERRORLEVEL仍为0。

默认搜索类型：文字与正则表达式
/C:"string"-默认为/ L文字。明确地将/ L选项与/ C组合在一起："字符串"当然可以，但是很多余。

"string argument"-默认值取决于第一个搜索字符串的内容。 (请记住，用于定界搜索字符串。)如果第一个搜索字符串是一个有效的正则表达式，其中包含至少一个未转义的元字符，则所有搜索字符串均被视为正则表达式。否则，所有搜索字符串均视为文字。例如，"51.4 200"将被视为两个正则表达式，因为第一个字符串包含未转义的点，而"200 51.4"将被视为两个文字，因为第一个字符串不包含任何元字符。

/G:file-默认值取决于文件中第一个非空行的内容。如果第一个搜索字符串是包含至少一个未转义的元字符的有效正则表达式，则所有搜索字符串均被视为正则表达式。否则，所有搜索字符串均视为文字。

建议-使用"string argument"或/G:file时，始终显式指定/L文字选项或/R正则表达式选项。

BUG-指定多个文字搜索字符串可能会导致结果不可靠

以下简单的FINDSTR示例无法找到匹配项，即使可以找到也是如此。

此错误已在Windows Server 2003，Windows XP，Vista和Windows 7上得到确认。

根据实验，如果满足以下所有条件，则FINDSTR可能会失败：

在我所看到的每一次失败中，它始终是失败的较短搜索字符串之一。

有关更多信息，请参见为什么这个带有多个文字搜索字符串的FINDSTR示例找不到匹配项？

命令行参数中的引号和反斜杠
注意-MC ND用户的注释反映了本节实际的复杂规则。涉及3个不同的解析阶段：

首先，cmd.exe可能需要将某些引号转为^"(与FINDSTR无关)

接下来的FINDSTR使用2008年以前的MS C / C ++参数解析器，该解析器对"和"具有特殊的规则。

参数解析器完成后，FINDSTR还将后面跟一个字母数字字符视为文字，但将后面跟一个非字母数字字符视为转义字符。

此突出显示部分的其余部分不是100％正确。它可以作为许多情况的指南，但是要完全理解，需要上述规则。

在命令行搜索字符串中转义引号
命令行搜索字符串中的引号必须使用反斜杠进行转义，例如
\"。对于文字和正则表达式搜索字符串都是如此。这个
在XP，Vista和Windows 7上已确认信息。

注意：对于CMD.EXE解析器，可能还需要转引号，但这与FINDSTR无关。例如，搜索
您可以使用单引号：

FINDSTR \^" file && echo found || echo not found

在命令行文字搜索字符串中转义反斜杠
文字搜索字符串中的反斜杠通常可以表示为
\或作为\\。它们通常是等效的。 (可能有异常
在Vista中总是必须避免反斜杠的情况，但我没有
不再需要测试Vista计算机)。

但是有一些特殊情况：

搜索连续的反斜杠时，除最后一个反斜杠之外的所有反斜杠都必须是
逃过一劫。最后一个反斜杠可以有选择地转义。

\\可以编码为\\\或\\\\

\\\可以编码为\\\\\或\\\\\\

在引号之前搜索一个或多个反斜杠很奇怪。逻辑
表示必须将引号转义，并且每个前导
反斜杠需要被转义，但这是行不通的！代替，
每个前导反斜杠必须加倍转义，并且引号
正常逃脱：

\"必须编码为\\\\\"

\\"必须编码为\\\\\\\\\"

如前所述，对于CMD解析器，一个或多个转义引号可能还需要使用^进行转义。

此部分中的信息已在XP和Windows 7上得到确认。

在命令行正则表达式搜索字符串中转义反斜杠

仅适用于Vista：正则表达式中的反斜杠必须像\\\\那样被双转义，或者在像这样的字符类集中被单义转义。
[\\]

XP和Windows 7：正则表达式中的反斜杠始终可以表示为[\\]。通常可以将其表示为\\。但这从来没有
如果反斜杠在转义的引号之前，则可以使用。

转义引号之前的一个或多个反斜杠必须为
两次转义，否则编码为[\\]

\"可能被编码为\\\\\"或[\\]\"

\\"可能被编码为\\\\\\\\\"或[\\][\\]\"或\\[\\]\"

在/ G：FILE文字搜索字符串中转义引号和反斜杠
/ G：file指定的文字搜索字符串文件中的单引号和反斜杠不需要转义，但是可以转义。

"和\"是等效的。

\和\\是等效的。

如果要找到\，则必须至少转义前导反斜杠。 \\\和\\\\均起作用。

如果要查找"，则必须至少转义反斜杠。\\"和\\\"均有效。

在/ G：FILE正则表达式搜索字符串中转义引号和反斜杠
这是转义序列按文档所述按预期工作的一种情况。 Quote不是正则表达式的元字符，因此不必转义(但可以转义)。反斜杠是正则表达式的元字符，因此必须转义。

命令行参数的字符数限制-扩展ASCII转换
空字符(0x00)不能出现在命令行的任何字符串中。任何其他单字节字符都可以出现在字符串(0x01-0xFF)中。但是，FINDSTR会将在命令行参数中找到的许多扩展ASCII字符转换为其他字符。这在两个方面产生重大影响：

1)如果在命令行中用作搜索字符串，许多扩展的ASCII字符将不匹配。对于文字和正则表达式搜索，此限制是相同的。如果搜索字符串必须包含扩展的ASCII，则应改为使用/G:FILE选项。

2)如果名称包含扩展的ASCII字符并且在命令行上指定了文件名，则FINDSTR可能找不到文件。如果要搜索的文件名称中包含扩展的ASCII，则应改为使用/F:FILE选项。

这是FINDSTR对命令行字符串执行的扩展ASCII字符转换的完整列表。每个字符都表示为十进制字节代码值。第一个代码表示命令行上提供的字符，第二个代码表示将其转换为的字符。注意-此列表是在美国计算机上编译的。我不知道其他语言可能对该列表产生什么影响。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

158 treated as 080     199 treated as 221     226 treated as 071 169 treated as 170     200 treated as 043     227 treated as 112 176 treated as 221     201 treated as 043     228 treated as 083 177 treated as 221     202 treated as 045     229 treated as 115 178 treated as 221     203 treated as 045     231 treated as 116 179 treated as 221     204 treated as 221     232 treated as 070 180 treated as 221     205 treated as 045     233 treated as 084 181 treated as 221     206 treated as 043     234 treated as 079 182 treated as 221     207 treated as 045     235 treated as 100 183 treated as 043     208 treated as 045     236 treated as 056 184 treated as 043     209 treated as 045     237 treated as 102 185 treated as 221     210 treated as 045     238 treated as 101 186 treated as 221     211 treated as 043     239 treated as 110 187 treated as 043     212 treated as 043     240 treated as 061 188 treated as 043     213 treated as 043     242 treated as 061 189 treated as 043     214 treated as 043     243 treated as 061 190 treated as 043     215 treated as 043     244 treated as 040 191 treated as 043     216 treated as 043     245 treated as 041 192 treated as 043     217 treated as 043     247 treated as 126 193 treated as 045     218 treated as 043     249 treated as 250 194 treated as 045     219 treated as 221     251 treated as 118 195 treated as 043     220 treated as 095     252 treated as 110 196 treated as 045     222 treated as 221     254 treated as 221 197 treated as 043     223 treated as 095 198 treated as 221     224 treated as 097

不在上面列表中的任何字符> 0都被视为自身，包括和<< x5>。包括和这样的奇数字符的最简单方法是将它们放入环境变量中，并在命令行参数中使用延迟扩展。

在/ G：FILE和/ F：FILE选项指定的文件中找到的字符串的字符数限制
nul(0x00)字符可以出现在文件中，但其功能类似于C字符串终止符。 nul字符之后的任何字符都被视为不同的字符串，就像它们在另一行一样。

和字符被视为终止字符串的行终止符，并且不包含在字符串中。

所有其他单字节字符都完美地包含在字符串中。

搜索Unicode文件
FINDSTR无法正确搜索大多数Unicode(UTF-16，UTF-16LE，UTF-16BE，UTF-32)，因为它无法搜索nul字节，而Unicode通常包含许多nul字节。

但是，TYPE命令将带BOM的UTF-16LE转换为单字节字符集，因此，以下命令将与带BOM的UTF-16LE一起使用。

1	type unicode.txt|findstr"search"

请注意，活动代码页不支持的Unicode代码点将转换为?字符。

只要您的搜索字符串仅包含ASCII，就可以搜索UTF-8。但是，控制台输出的任何多字节UTF-8字符都不正确。但是，如果将输出重定向到文件，则结果将被正确编码为UTF-8。请注意，如果UTF-8文件包含BOM表，则BOM表将被视为第一行的一部分，这可能会引发与行首匹配的搜索。

如果将搜索字符串放入UTF-8编码的搜索文件(无BOM)中，并使用/ G选项，则可以搜索多字节UTF-8字符。

行尾
FINDSTR在每个之后立即换行。 的存在或不存在对换行符没有影响。

跨行搜索
与预期的一样，.正则表达式元字符将不匹配或。但是可以使用命令行搜索字符串在换行符中进行搜索。 和字符必须明确匹配。如果找到多行匹配项，则仅打印匹配项的第一行。然后，FINDSTR加倍返回到源代码中的第二行，并重新开始搜索-一种"向前看"类型的功能。

假设TEXT.TXT具有这些内容(可以是Unix或Windows风格)

1 2 3 4 5 6

A A A B A A

然后这个脚本

1 2 3 4 5 6 7 8 9 10 11 12 13 14

@echo off setlocal ::Define LF variable containing a linefeed (0x0A) set LF=^ ::Above 2 blank lines are critical - do not remove ::Define CR variable containing a carriage return (0x0D) for /f %%a in ('copy /Z"%~dpf0" nul') do set"CR=%%a" setlocal enableDelayedExpansion ::regex"!CR!*!LF!" will match both Unix and Windows style End-Of-Line findstr /n /r /c:"A!CR!*!LF!A" TEST.TXT

给出这些结果

1 2 3

1:A 2:A 5:A

使用/ G：FILE选项搜索换行符是不精确的，因为匹配或的唯一方法是通过将EOL字符夹在中间的正则表达式字符类范围表达式。

[-<0x0B>]匹配，但也匹配和<0x0B>

[<0x0C>-!]匹配，但它也匹配<0x0C>和！

注意-上面是正则表达式字节流的符号表示，因为我无法以图形方式表示字符。

答案在下面的第2部分中继续...

好。

相关讨论

• +1，我喜欢这种类型的深度分析
• 出色的完整性。如果只有互联网上的所有答案都是这样。
• 我们遇到了来自Q141344和findstr的addpath.bat问题，这可能与上述Win7挂起问题有关。 Ive为感兴趣的任何人创建了一个聊天室，以尝试对其进行跟踪：chat.stackoverflow.com/rooms/13177/
• 编辑-在XP上将控制字符描述为点显示。还记录了源自简短8.3文件名的错误的S和D选项。
• 编辑-1)/ F：FILE指定的文件内的文件名不能用引号引起来。 2)扩展ASCII字符的转换在命令行中提供时会同时影响搜索字符串和文件名。
• 非常感谢您的精彩文章！也许您可以帮助我解决findstr表达问题。我想找到一个包含">"和" <"(大于)字符的字符串。我试图用^或对其进行转义。还使用像<0x3C>和[<0x3C>]这样的语法使用字符代码，但到目前为止没有成功。有任何想法吗？
• @weberik-您应该发布一个问题，说明您希望搜索字符串是什么(逻辑，不一定是有效的FINDSTR语法)，以及应该匹配的字符串。如果您发布一些失败的示例代码尝试以及失败的方式，也将有所帮助。
• 实际上，我的问题是来自stackoverflow stackoverflow.com/questions/14232263/上另一个问题的结果，也许您可??以看一下？据我了解的主要问题是我了解一个与标签匹配的findstr表达式(类似于xml)
• 编辑-添加了以下错误：如果管道输入的最后一行由不带的单个字符组成，则会忽略管道输入的最后一行
• 谢谢，这非常有用！除了多重搜索字符串错误(我无法使用您提供的示例在Vista-X64上重现该错误)之外，您是否还了解多个搜索字符串的限制？我已经使用了/ g来指定最多10000个搜索字符串(显然是成功的，但是我很难手动检查结果！)。
• 编辑-在命令行上重新设计了反斜杠的转义规则。
• 编辑-添加了描述非标准通配符<和>如何避免FINDSTR输出中文件名前缀的文档。
• A:attr为文件名着色的限制是，如果将其通过管道传递给另一个命令，则会去除颜色。
• 关于单词边界：您说\<和\>必须是正则表达式的第一个和最后一个术语，但是类似findstr"\ \"的东西似乎也可以正常工作(@ Win7)；你能澄清一下吗？ (我认为""之间的整个字符串为包含两个搜索字符串的正则表达式-符合您的解释吗？)
• @aschipfl-您的示例在一个参数内有两个独立的正则表达式。我的单词边界规则适用于每个正则表达式，而不适用于整个参数。
• 仅供参考(我不知道您是否已经知道，但您的答案中没有提及)。大多数" bizarre"反斜杠+引号规则的原因是findstr是exe文件，并且某些规则控制参数标记符如何处理反斜杠+引号，但是一旦解析了参数，则代码中有一个字符串，需要将其编译为正则表达式实例。因此，某些反斜杠会被解释两次。
• 文字反斜杠不需要任何转义(findstr l \ *.cmd)，但是双引号文字反斜杠需要它(findstr l"\" *.cmd)以避免转义引号。但是findstr字符串解析器将处理文字反斜杠，后跟非字母数字字符([a-zA-Z0-9])作为转义字符：findstr l c:"\ o" *.cmd搜索空格，后跟o字符，因为反斜杠转义了空格，但是< x6>搜索反斜杠，后跟一个w字符(它是字母数字，因此不会转义)
• @MCND-哇，很棒的链接，谢谢！我相信它可以解释文字FINDSTR搜索。我仍然有一些正则表达式搜索对我来说还没有意义。理解的道路很长很狭窄，两边都下了100米。我已经摔倒好几次了，我的头很痛！我会研究更多，然后尝试修改我的答案。无论哪种方式，我都会以信誉肯定地将您的链接添加到我的答案中。
• @MCND-噢，我从未见过非alpha之前的反斜杠字面搜索规则始终是转义符。好发现。如果需要，可以随意添加您自己的答案，包括您的链接，我肯定会赞成。或者，如果您愿意，可以将其添加到我的答案中。您正在使用什么操作系统？
• @dbenham，如果将信息分组，我认为它更容易找到，请将其添加到您的答案中，谢谢。我使用的是W7 32b和W10 64b，这两个专业版本均为西班牙语言环境。
• 编辑-完善了返回码部分，并将正则表达式讨论移至第2部分。
• 编辑-我终于修改了命令行参数反斜杠和引用规则部分，以包括MC ND C / C ++链接。
• @dbenham，想知道关于A:选项是否应该简短介绍？ findstr帮助未指定在搜索多个文件时仅文件名将使用颜色编码。可以从第一次阅读帮助中推断出，它可以更改输出中找到的字符串的颜色。我猜从技术上讲，它不是未记录的功能或限制，但是Microsoft并未特别指出这一点似乎很奇怪。 SS64上的文档可以。

---

答案从上面的第1部分继续-我遇到了30,000个字符的答案限制:-(

有限的正则表达式(regex)支持
FINDSTR对正则表达式的支持非常有限。如果HELP文档中未包含该内容，则不支持。

除此之外，所支持的regex表达式是以完全非标准的方式实现的，因此结果可能与预期的结果不同，例如grep或perl。

正则表达式行定位锚^和$
^匹配输入流的开始以及紧随之后的任何位置。由于FINDSTR还会在之后打断行，因此简单的正则表达式" ^"将始终匹配文件(甚至二进制文件)中的所有行。

$匹配紧接之前的任何位置。这意味着包含$的正则表达式搜索字符串将永远不会匹配Unix样式文本文件中的任何行，如果缺少 的EOL标记，它将不会匹配Windows文本文件的最后一行。

注–如前所述，通过管道传输和重定向到FINDSTR的输入可能附加了，而该源不在源中。显然，这会影响使用$的正则表达式搜索。

任何在^之前或$之后的字符的搜索字符串将始终找不到匹配项。

位置选项/ B / E / X
位置选项与^和$相同，除了它们也适用于文字搜索字符串。

/ B在正则表达式搜索字符串的开头与^相同。

/ E在正则表达式搜索字符串末尾的功能与$相同。

/ X的功能与正则表达式搜索字符串的开头和结尾处的$相同。

正则词边界
\<必须是正则表达式中的第一个术语。如果有其他字符，则该正则表达式将不匹配任何内容。 \<对应于输入的开头，行的开头(紧随的位置)或紧随任何"非单词"字符的位置。下一个字符不必是"单词"字符。

\>必须是正则表达式中的最后一项。如果后面有其他任何字符，则该正则表达式将不匹配任何内容。 \>对应于输入的结尾，之前的位置或任何"非单词"字符之前的位置。前面的字符不必是"单词"字符。

这是"非单词"字符的完整列表，表示为十进制字节码。注意-此列表是在美国计算机上编译的。我不知道其他语言可能对该列表产生什么影响。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

001   028   063   179   204   230 002   029   064   180   205   231 003   030   091   181   206   232 004   031   092   182   207   233 005   032   093   183   208   234 006   033   094   184   209   235 007   034   096   185   210   236 008   035   123   186   211   237 009   036   124   187   212   238 011   037   125   188   213   239 012   038   126   189   214   240 014   039   127   190   215   241 015   040   155   191   216   242 016   041   156   192   217   243 017   042   157   193   218   244 018   043   158   194   219   245 019   044   168   195   220   246 020   045   169   196   221   247 021   046   170   197   222   248 022   047   173   198   223   249 023   058   174   199   224   250 024   059   175   200   226   251 025   060   176   201   227   254 026   061   177   202   228   255 027   062   178   203   229

正则表达式字符类范围[x-y]
字符类范围无法正常工作。看到以下问题：为什么findstr在某些情况下不能正确处理大小写？以及此答案：https://stackoverflow.com/a/8767815/1012053。

问题是FINDSTR不会按字节码值整理字符(通常认为是ASCII码，但是ASCII仅从0x00-0x7F定义)。大多数正则表达式实现会将[A-Z]视为所有大写英文大写字母。但是FINDSTR使用的排序顺序与SORT的工作原理大致相对应。因此，[A-Z]包括完整的英文字母，大写和小写(" a"除外)以及带有变音符号的非英文字母字符。

以下是FINDSTR支持的所有字符的完整列表，并按FINDSTR用于建立正则表达式字符类范围的排序顺序进行排序。字符表示为其十进制字节代码值。我相信如果使用代码页437查看字符，则整理顺序最有意义。注意-此列表是在美国计算机上编译的。我不知道其他语言可能对该列表产生什么影响。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255

001 002 003 004 005 006 007 008 014 015 016 017 018           019 020 021 022 023 024 025 026 027 028 029 030 031 127 039 045 032 255 009 010 011 012 013 033 034 035 036 037 038 040 041 042 044 046 047 058 059 063 064 091 092 093 094 095 096 123 124 125 126 173 168 155 156 157 158 043 249 060 061 062 241 174 175 246 251 239 247 240 243 242 169 244 245 254 196 205 179 186 218 213 214 201 191 184 183 187 192 212 211 200 217 190 189 188 195 198 199 204 180 181 182 185 194 209 210 203 193 207 208 202 197 216 215 206 223 220 221 222 219 176 177 178 170 248 230 250 048 172 171 049 050 253 051 052 053 054 055 056 057 236 097 065 166 160 133 131 132 142 134 143 145 146 098 066 099 067 135 128 100 068 101 069 130 144 138 136 137 102 070 159 103 071 104 072 105 073 161 141 140 139 106 074 107 075 108 076 109 077 110 252 078 164 165 111 079 167 162 149 147 148 153 112 080 113 081 114 082 115 083 225 116 084 117 085 163 151 150 129 154 118 086 119 087 120 088 121 089 152 122 090 224 226 235 238 233 227 229 228 231 237 232 234

正则表达式字符类术语限制和BUG
FINDSTR不仅在正则表达式中最多限制15个字符类术语，而且不能正确处理超出限制的尝试。使用16个或更多字符类术语将显示一个交互式Windows弹出窗口，提示"查找字符串(QGREP)实用程序遇到问题，需要关闭。对此给您带来的不便，我们深表歉意。"消息文本因Windows版本而略有不同。这是一个失败的FINDSTR示例：

1	echo 01234567890123456|findstr [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]

此错误由DosTips用户Judago在此处报告。已在XP，Vista和Windows 7上得到确认。

如果正则表达式搜索包含字节码0xFF(十进制255)，则失败(并且可能无限期挂起)
包含字节码0xFF(十进制255)的任何正则表达式搜索都将失败。如果直接包含字节码0xFF或隐式包含在字符类范围内，则失败。请记住，FINDSTR字符类范围不会根据字节码值整理字符。字符<0xFF>出现在和字符之间的整理顺序中相对较早。因此，同时包含和的任何字符类范围都将失败。

确切的行为会略有不同，具体取决于Windows版本。如果包含0xFF，Windows 7将无限期挂起。 XP不会挂起，但始终找不到匹配项，并且偶尔会显示以下错误消息-"该进程试图写入不存在的管道。"

我无法再使用Vista机器，因此无法在Vista上进行测试。

正则表达式错误：.和[^anySet]可以匹配文件尾
正则表达式.元字符只能与或以外的任何字符匹配。 如果文件中的最后一行没有被或终止，则存在一个使它与文件结尾匹配的错误。 但是，.将不匹配空文件。

例如，一个名为" test.txt"的文件，其中包含x的一行而没有终止或，将与以下内容匹配：

1	findstr /r x......... test.txt

此错误已在XP和Win7上得到确认。

否定字符集似乎也是如此。 [^abc]之类的东西将与文件结束匹配。 像[abc]这样的正字符集似乎可以正常工作。 我只在Win7上测试过。

好。

相关讨论

• findstr在处理大型文件时也很麻烦。文件> 2GB可能导致findstr挂起。它确实总是发生。为了确认错误，我搜索了一个2.3GB的文件，该文件没有挂起。即使仅搜索单个文件，它也会挂起。解决方法是将type的输出通过管道传输到findstr。
• 还可能值得一提的是，findstr支持多个c:搜索字符串。我知道您的回答确实证明了这一点。但这是没有记录的东西。在使用findstr并没有使用它几年后，我对它的功能感到非常惊讶。
• @CraigYoung-您对搜索字符串源是正确的。我修改了答案，谢谢。
• 否。如我的评论中所述，使用type重定向输出可以解决。 Alos，所有行都以CRLF结尾。病态的会议作为答案，您可以自己尝试。也许您会注意到其他可能导致问题的原因。
• @CraigYoung-但是，如果最后一行不以结尾，则FINDSTR将自动将附加到任何管道输入。因此，如果您将TYPE的结果传递给FINDSTR，我希望它能起作用。如果让FINDSTR以文件名作为参数直接打开文件，它也应该起作用。如果您使用重定向(不是管道)并且最后一行不包含，它可能会挂起。如果这不能解释问题，则打开一个新问题，显示您使用的确切命令，并包括指向包含大文件的DropBox之类的链接。附： 2.9GB文件没有问题。
• 经过进一步调查，它看起来像您记录的LF问题的变体。我意识到我的测试文件没有以LF结尾，因为我在附加模式下使用了copy来创建它。香港专业教育学院把一个命令行会话来演示此问题的答案(stackoverflow.com/a/22943056/224704)。请注意，输入未重定向，但是搜索挂起。完全相同的搜索命令不会挂在较小的文件上，而较小的文件也不以LF结尾。
• 我什至不知道有字符限制
• 新发现(Win7)：findstr R C:"^[0-9][0-9]* [0-3][0-9][0-9]-[0-9][0-9]:[0-5][0-9]:[0-5][0-9]\.[0-9][0-9]* [0-9]*\.[0-9]*"(15个字符类)-ErrorLevel = -1073740791 (0xC0000409)，错误对话框窗口：Find String (QGREP) Utility has stopped working;删除一类或两个元字符(*\.)之后，它可以工作...

---

搜索大文件时，findstr有时会意外挂起。

我尚未确认确切条件或边界大小。我怀疑任何大于2GB的文件都可能有危险。

我对此有不同的经验，所以它不仅仅是文件大小。如果重定向的输入不以LF结尾，这看起来可能是XP和Windows 7上FINDSTR挂起的一种变体，但是正如所证明的，当输入未重定向时，此特定问题就显现出来了。

以下命令行会话(Windows 7)演示了搜索3GB文件时findstr如何挂起。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

C:\Data\Temp\2014-04>echo 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890> T100B.txt C:\Data\Temp\2014-04>for /L %i in (1,1,10) do @type T100B.txt >> T1KB.txt C:\Data\Temp\2014-04>for /L %i in (1,1,1000) do @type T1KB.txt >> T1MB.txt C:\Data\Temp\2014-04>for /L %i in (1,1,1000) do @type T1MB.txt >> T1GB.txt C:\Data\Temp\2014-04>echo find this line>> T1GB.txt C:\Data\Temp\2014-04>copy T1GB.txt + T1GB.txt + T1GB.txt T3GB.txt T1GB.txt T1GB.txt T1GB.txt         1 file(s) copied. C:\Data\Temp\2014-04>dir  Volume in drive C has no label.  Volume Serial Number is D2B2-FFDF  Directory of C:\Data\Temp\2014-04 2014/04/08  04:28 PM    <DIR>          . 2014/04/08  04:28 PM    <DIR>          .. 2014/04/08  04:22 PM               102 T100B.txt 2014/04/08  04:28 PM     1020000016 T1GB.txt 2014/04/08  04:23 PM             1020 T1KB.txt 2014/04/08  04:23 PM         1020000 T1MB.txt 2014/04/08  04:29 PM     3060000049 T3GB.txt                5 File(s)  4081021187 bytes                2 Dir(s)  51881050112 bytes free C:\Data\Temp\2014-04>rem Findstr on the 1GB file does not hang C:\Data\Temp\2014-04>findstr"this" T1GB.txt find this line C:\Data\Temp\2014-04>rem On the 3GB file, findstr hangs and must be aborted... even though it clearly reaches end of file C:\Data\Temp\2014-04>findstr"this" T3GB.txt find this line find this line find this line ^C C:\Data\Temp\2014-04>

注意，我已经在十六进制编辑器中验证了所有行都以CRLF终止。唯一的异常是文件由于copy的工作方式而以0x1A终止。但是请注意，此异常不会对"小"文件造成问题。

通过其他测试，我确认了以下几点：

• 对于二进制文件，将copy与/b选项一起使用可防止添加0x1A字符，并且findstr不会挂在3GB文件上。
• 用不同的字符终止3GB文件也会导致findstr挂起。
• 0x1A字符在"小"文件上不会引起任何问题。 (与其他终止字符类似。)
• 在0x1A之后添加CRLF可解决问题。 (LF本身可能就足够了。)
• 使用type将文件通过管道传输到findstr时无需挂起。 (这可能是由于type或|的副作用，该副作用插入了额外的行尾)。
• 使用重定向输入<也会导致findstr挂起。但这是预料之中的。如dbenham的帖子所述："重定向的输入必须以LF结尾"。

相关讨论

• +1，我可以在Win7机器上确认问题。当最后一个字符不是时，将挂起一个大小为2GiB的文件。一个小两个字节的文件没有挂起。很讨厌！

---

当括号中包含多个命令并且将文件重定向到整个块时：

1 2 3 4 5

< input.txt (    command1    command2    . . . ) > output.txt

...然后，只要块中的命令处于活动状态，文件就保持打开状态，因此命令可以移动重定向文件的文件指针。 MORE和FIND命令都将Stdin文件指针移至文件的开头，然后再对其进行处理，因此同一文件可能在块中被处理了几次。例如，此代码：

1 2	more < input.txt >  output.txt more < input.txt >> output.txt

...产生与这一结果相同的结果：

1 2 3 4

< input.txt (    more    more ) > output.txt

这段代码：

1 2	find   "search string" < input.txt > matchedLines.txt find /V"search string" < input.txt > unmatchedLines.txt

...产生与这一结果相同的结果：

1 2 3 4

< input.txt (    find   "search string"> matchedLines.txt    find /V"search string"> unmatchedLines.txt )

FINDSTR是不同的；它不会从当前位置移动Stdin文件指针。例如，此代码在搜索行之后插入新行：

1 2 3 4 5 6 7 8 9 10 11 12 13 14

call :ProcessFile < input.txt goto :EOF :ProcessFile    rem Read the next line from Stdin and copy it    set /P line=    echo %line%    rem Test if it is the search line    if"%line%" neq"search line" goto ProcessFile rem Insert the new line at this point echo New line rem And copy the rest of lines findstr"^" exit /B

我们可以在辅助程序的帮助下充分利用此功能，该辅助程序允许我们移动重定向文件的文件指针，如本示例所示。

这个行为是jeb在此职位上首次报告的。

编辑2018-08-18：报告了新的FINDSTR错误

FINDSTR命令有一个奇怪的错误，当此命令用于以彩色显示字符并且此命令的输出重定向到CON设备时，会发生此错误。有关如何使用FINDSTR命令以彩色显示文本的详细信息，请参见本主题。

当这种形式的FINDSTR命令的输出重定向到CON时，以期望的颜色输出文本后会发生一些奇怪的事情：所有文本以"不可见"字符输出，尽管更精确的描述是文本是输出为黑色背景上的黑色文本。如果您使用COLOR命令重设整个屏幕的前景色和背景色，则将显示原始文本。但是，当文本为"不可见"时，我们可以执行SET / P命令，因此输入的所有字符都不会出现在屏幕上。此行为可能用于输入密码。

1 2 3 4 5 6 7 8 9 10

@echo off setlocal set /P"=_" < NUL >"Enter password" findstr /A:1E /V"^$""Enter password" NUL > CON del"Enter password" set /P"password=" cls color 07 echo The password read is:"%password%"

---

我想报告一个错误，该错误涉及在文件名中使用破折号(-)或破折号(-)时要在第一个答案中搜索的数据源部分。

更具体地说，如果您要使用第一个选项-指定文件名作为参数，则将找不到该文件。一旦使用选项2-通过重定向的stdin或选项3-来自管道的数据流，findstr就会找到该文件。

例如，以下简单的批处理脚本：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

echo off chcp 1250 > nul set INTEXTFILE1=filename with – dash.txt set INTEXTFILE2=filename with — dash.txt rem 3 way of findstr use with en dashed filename echo. echo Filename with en dash: echo. echo 1. As argument findstr ."%INTEXTFILE1%" echo. echo 2. As stdin via redirection findstr . <"%INTEXTFILE1%" echo. echo 3. As datastream from a pipe type"%INTEXTFILE1%" | findstr . echo. echo. rem The same set of operations with em dashed filename echo Filename with em dash: echo. echo 1. As argument findstr ."%INTEXTFILE2%" echo. echo 2. As stdin via redirection findstr . <"%INTEXTFILE2%" echo. echo 3. As datastream from a pipe type"%INTEXTFILE2%" | findstr . echo. pause

将打印：

带有破折号的文件名：

作为论点
FINDSTR：无法使用-dash.txt打开文件名

通过重定向作为标准输入
我是带破折号的文件。

作为来自管道的数据流
我是带破折号的文件。

带破折号的文件名：

作为论点
FINDSTR：无法使用-dash.txt打开文件名

通过重定向作为标准输入
我是带破折号的文件。

作为来自管道的数据流
我是带破折号的文件。

希望能帮助到你。

M.

相关讨论

• 嗨，马特罗，虽然您的评论可能是正确的，但我不确定他们没有解决实际问题。
• 我相信这是Unicode问题，FINDSTR不支持。 CMD.EXE重定向可以使用Unicode正确打开文件名，就像TYPE命令一样。但是沿着这条线的某个地方，FINDSTR会将破折号和全破折号都转换为普通破折号，并且操作系统当然找不到该名称。如果您创建另一个文件，用破折号代替破折号和/或破折号，则FINDSTR将搜索破折号文件(如果提供的名称中包含破折号或破折号)。
• 我将此问题归类为限制而非错误。
• dbenham，您好，感谢您的反馈。
• 实际上，这不是扩展ASCII的Unicode问题。 我已经在原始答案的命令行参数字符限制-扩展ASCII转换标题下记录了此问题。 FINDSTR将许多扩展的ASCII代码转换为"相关的"真实ASCII，包括破折号和破折号。

---

假设没有无效或不兼容的开关，并且没有搜索字符串超过适用的长度限制，findstr命令将ErrorLevel(或退出代码)设置为以下值之一：

• 0当在所有指定文件的一行中至少遇到一个匹配项时；
• 1否则；

在以下情况下，一行被认为包含匹配项：

• 没有给出/V选项，并且搜索表达式至少出现一次；
• 给出了/V选项，并且不会出现搜索表达式；

这意味着/V选项还会更改返回的ErrorLevel，但它不仅会还原它！

例如，当您有一个包含两行的文件test.txt，其中一行包含字符串text，而另一行则不包含字符串时，findstr"text""test.txt"和findstr /V"text""test.txt"均返回0的ErrorLevel。

基本上可以说：如果findstr返回至少一行，则ErrorLevel设置为0，否则设置为1。

请注意，/M选项不会影响ErrorLevel值，它只会更改输出。

(仅出于完整性考虑：对于/V选项和ErrorLevel，find命令的行为完全相同； /C选项不影响ErrorLevel。)

---

/ D提示多个目录：将目录列表放在搜索字符串之前。所有这些工作：

1 2 3

findstr /D:dir1;dir2"searchString" *.* findstr /D:"dir1;dir2""searchString" *.* findstr /D:"\path\dir1\;\path\dir2""searchString" *.*

如预期的那样，如果您不使用\开头目录，则该路径是相对于位置的。如果目录名称中没有空格，则用"包围路径是可选的。结尾的\是可选的。 location的输出将包括您提供的任何路径。无论使用"包围目录列表，都可以使用它。

相关讨论

• 我在这里看不到任何未记录的内容。 / D选项在内置帮助中进行了描述。这不是有关如何使用FINDSTR的一般提示的问题。严格旨在列出未记录的功能，限制和/或错误。
• @dbenham确实不是真正没有记载的文件，但是我发现我不得不与findstr讨好，以获得所需的结果，并分享了我发现DID可以正常工作的东西，这样人们就不会浪费时间尝试无法正常工作的命令。 hth(很遗憾，您不喜欢我的输入-只是为了具有建设性)
• 恕我直言，/ D开关在内置帮助中很清楚地描述了：D:dirlist Search a semicolon-delimited list of directories，它位于搜索字符串之前，因此我不明白关于" / D"开关"找到的内容"到底是什么(以及"命令"是什么)那行不通")...
• @Aacini在许多语言中，属性的顺序无关紧要。我先了解findstr列表/ D的文档。是的，我对此功能没有论据，只是关于属性顺序很重要的陷阱没有被证明。我很少做命令行工作，所以当我在整理一条命令时，不知道顺序有所不同，我只是在添加属性时添加它们(按字母顺序，C在D之前)。我真的很沮丧，并与其他在命令行中工作不多的人分享了我的"发现"经验。
• 可选属性的顺序通常无关紧要。 findstr文档指定strings部分不是可选的，您必须将其放置在可选属性之后和可选文件名列表之前。如果"您的发现"是使用不遵循其用法格式的命令会导致错误，则说明了这一点。请参见命令语法："语法以必须键入命令及其后的任何参数的顺序显示"

---