Windows FINDSTR命令的文档记录非常糟糕。通过FINDSTR /?，或HELP FINDSTR，但它远远不够。在https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/findstr上有更多的在线文档。
文档中甚至没有提到FINDSTR的许多特性和限制。如果没有事先的知识和/或仔细的实验，也无法预测它们。
那么问题是——没有记录的FINDSTR特性和限制是什么?
这个问题的目的是提供许多未记录的特性的一站式存储库，以便:
A)开发人员可以充分利用现有的功能。
B)开发人员不会浪费时间去思考为什么有些东西看起来应该不能工作。
在回复之前，请确保您了解现有的文档。如果信息包含在HELP中，那么它就不属于这里。
这里也不是展示FINDSTR有趣用法的地方。如果一个有逻辑的人可以根据文档预测FINDSTR的特定用法的行为，那么它就不属于这里。
同样，如果一个有逻辑的人可以根据任何现有答案中包含的信息预测特定用法的行为，那么它也不属于这里。
前言 这个答案中的大部分信息都是基于在Vista机器上运行的实验而收集的。除非另有明确说明，我还没有确认这些信息是否适用于其他Windows版本。
中输出 文档从未费心解释FINDSTR的输出。它暗示了打印匹配行的事实，但仅此而已。
匹配行输出格式如下:
filename: lineNumber lineOffset:文本
在哪里
fileName: =包含匹配行的文件名。如果请求显式地针对单个文件，或者搜索管道输入或重定向输入，则不会打印文件名。打印时，fileName将始终包含所提供的任何路径信息。如果使用了/S选项，则会添加其他路径信息。打印的路径总是相对于提供的路径，如果没有提供，则相对于当前目录。
注意:在搜索多个文件时，可以通过使用非标准通配符<和>来避免文件名前缀。这些通配符如何工作的确切规则可以在这里找到。最后，您可以看看这个例子，看看非标准通配符如何与FINDSTR一起工作。
lineNumber: =匹配行的行号，表示为十进制值，1表示输入的第一行。只有指定/N选项时才打印。
lineOffset: =匹配行开始的十进制字节偏移量，0表示第一行的第一个字符。仅在指定/O选项时打印。这不是行内匹配的偏移量。它是从文件开始到行开始的字节数。
text =匹配行的二进制表示，包括任何<CR>和/或<LF>。二进制输出中没有遗漏任何内容，因此这个匹配所有行的示例将生成原始文件的精确二进制副本。
FINDSTR "^" FILE >FILE_COPY
/A选项只设置fileName:、lineNumber:和lineOffset:输出的颜色。匹配行的文本总是以当前控制台颜色输出。/A选项仅在输出直接显示到控制台时有效。如果输出被重定向到文件或管道，/A选项将不起作用。关于输出重定向到CON时的错误行为的描述，请参见Aacini回答中的2018-08-18编辑。
大多数控制字符和许多扩展ASCII字符在XP上显示为点 XP上的FINDSTR将来自匹配行的大多数不可打印控制字符显示为屏幕上的点(句号)。以下控制字符是例外;它们显示为自身:0x09标签，0x0A换行，0x0B垂直标签，0x0C表单换行，0x0D回车。
XP FINDSTR还将一些扩展的ASCII字符转换为点。在XP上显示为点的扩展ASCII字符与在命令行上提供时转换的字符相同。请参阅本文后面的“命令行参数的字符限制-扩展ASCII转换”部分
如果输出是管道输出、重定向到文件或在FOR IN()子句中，则控制字符和扩展ASCII不会在XP上转换为点。
Vista和Windows 7总是显示所有字符本身，而不是点。
返回码(ERRORLEVEL)
0(成功) 在至少一个文件的至少一行中找到匹配项。 1(失败) 在任何文件的任何一行都没有找到匹配。 /A:xx选项指定的颜色无效 2(错误) 同时指定了不兼容的选项/L和/R /A:， /F:， /C:， /D:，或/G后缺少参数: /F指定的文件:文件或/G指定的文件未找到 255(错误) 太多正则表达式字符类术语 请参见答案的第2部分Regex字符类的期限限制和BUG
要搜索的数据源(根据Windows 7测试更新) Findstr只能从以下来源之一搜索数据:
指定为参数和/或使用/F:file选项的文件名。 通过重定向findstr "searchString" <文件 来自管道类型文件的数据流
参数/选项优先于重定向，重定向优先于管道数据。
文件名参数和/F: File可以组合使用。可以使用多个文件名参数。如果指定了多个/F:文件选项，则只使用最后一个。文件名参数中允许通配符，但在/F:file指向的文件中不允许。
搜索字符串的来源(根据Windows 7测试更新) /G:file和/C:string选项可以组合使用。可以指定多个/C:string选项。如果指定了多个/G:文件选项，则只使用最后一个。如果使用/G:file或/C:string，则所有非选项参数都假定为要搜索的文件。如果既没有使用/G:file也没有使用/C:string，那么第一个非选项参数将被视为一个以空格分隔的搜索词列表。
当使用/F: File选项时，文件名不能在文件中引用。 文件名可能包含空格和其他特殊字符。大多数命令要求这样的文件名加引号。但是FINDSTR /F:files.txt选项要求files.txt中的文件名不能被引用。如果文件名被引用，则无法找到该文件。
短小的8.3文件名会破坏/D和/S选项 与所有Windows命令一样，FINDSTR在查找要搜索的文件时，将尝试同时匹配长名称和短8.3名称。假设当前文件夹包含以下非空文件:
b1.txt
b.txt2
c.txt
下面的命令将成功找到所有3个文件:
findstr /m "^" *.txt
b.txt2匹配，因为对应的短名称B9F64~1.TXT匹配。这与所有其他Windows命令的行为一致。
但是/D和/S选项的错误导致以下命令只能找到b1.txt
findstr /m /d:. "^" *.txt
findstr /m /s "^" *.txt
该错误阻止找到b.txt2，以及在同一目录中以b.txt2排序的所有文件名。找到了之前排序的其他文件，比如a.txt。一旦bug被触发，稍后排序的其他文件(如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将以下控制字符视为可打印的:
8 0x08 backspace
9 0x09 horizontal tab
10 0x0A line feed
11 0x0B vertical tab
12 0x0C form feed
13 0x0D carriage return
26 0x1A substitute (end of text)
所有其他控制字符都被视为不可打印字符，它们的存在会导致/P选项跳过文件。
管道和重定向输入可能有<CR><LF>附加 如果输入是通过管道输入的，并且流的最后一个字符不<LF>，那么FINDSTR将自动将<CR><LF>附加到输入。XP、Vista和Windows 7系统已经证实了这一点。(我曾经认为Windows管道负责修改输入，但我后来发现FINDSTR实际上正在进行修改。)
在Vista上重定向输入也是如此。如果用作重定向输入的文件的最后一个字符不是<LF>，那么FINDSTR将自动将<CR><LF>附加到输入。然而，XP和Windows 7不改变重定向输入。
如果重定向输入不以<LF>结束，FINDSTR挂起在XP和Windows 7上 这是XP和Windows 7上一个令人讨厌的“功能”。如果用作重定向输入的文件的最后一个字符不以<LF>结尾，那么FINDSTR在到达重定向文件的末尾时将无限期挂起。
如果管道数据的最后一行由单个字符组成，则可以忽略它 如果输入是通过管道输入的，并且最后一行由单个字符组成，后面没有<LF>，那么FINDSTR完全忽略最后一行。
示例-第一个带有单个字符且没有<LF>的命令无法匹配，但是第二个带有2个字符的命令可以正常工作，第三个带有一个字符的结束换行符的命令也是如此。
> set /p "=x" <nul | findstr "^"
> set /p "=xx" <nul | findstr "^"
xx
> echo x| findstr "^"
x
DosTips用户Sponge Belly报告了新的findstr错误。在XP, Windows 7和Windows 8上确认。还没听说过Vista。(我不再需要测试Vista了)。
选项的语法 选项字母不区分大小写，因此/i和/i是等效的。
选项可以用“/”或“-”作为前缀 选项可以在单个/或-后连接。但是，连接的选项列表最多只能包含一个多字符选项，例如OFF或F:，并且该多字符选项必须位于列表的最后。
以下是对任意顺序同时包含“hello”和“goodbye”的行进行不区分大小写正则表达式搜索的等效方法
/i /r /c:"hello. "*再见”/ c:“再见。*你好” -i -r -c:"你好。*再见”/ c:“再见。*你好” / irc:“你好。*再见”/ c:“再见。*你好”
期权也可以报价。所以/i -i /i和-i都是等价的。同样，/c:string、"/c":string、"/c:"string和"/c:string"都是等价的。
如果搜索字符串以/或-字面值开头，则必须使用/C或/G选项。感谢Stephan在评论中报告了这一点(已删除)。
如果使用了/c:string或/g:file选项，那么如果文件名参数以-开头，即使引用也会失败。这是因为没有搜索字符串参数，因此文件名参数被视为一个选项。最简单的解决方法是在file参数前加上。反斜杠，如
findstr /c:"searchString" ".\-fileName.txt"
搜索字符串长度限制 在Vista上，单个搜索字符串允许的最大长度是511字节。如果任何搜索字符串超过511，则结果是FINDSTR:搜索字符串太长。error为ERRORLEVEL 2。
使用正则表达式进行搜索时，最大搜索字符串长度为254。长度在255到511之间的正则表达式将导致一个ERRORLEVEL 2的FINDSTR: Out of memory错误。长度为>511的正则表达式会导致FINDSTR: Search字符串过长。错误。
在Windows XP上，搜索字符串的长度明显更短。Findstr错误:“搜索字符串太长”:如何提取和匹配子字符串在“for”循环? 对于文字和正则表达式搜索，XP限制都是127字节。
线长限制 作为命令行参数或通过/F:FILE选项指定的文件没有已知的行长限制。成功对不包含单个<LF>的128MB文件运行搜索。
管道数据和重定向输入每行限制为8191字节。这个限制是FINDSTR的一个“特性”。它不是管道或重定向所固有的。使用重定向stdin或管道输入的FINDSTR将永远不会匹配>=8k字节的任何行。Lines >= 8k向stderr生成错误消息，但是如果在至少一个文件的至少一行中找到了搜索字符串，ERRORLEVEL仍然为0。
默认搜索类型:文字vs正则表达式 /C:"string" -默认为/L文字。显式地组合/L选项和/C:"string"当然可以，但这是多余的。
"string argument" - The default depends on the content of the very first search string. (Remember that <space> is used to delimit search strings.) If the first search string is a valid regular expression that contains at least one un-escaped meta-character, then all search strings are treated as regular expressions. Otherwise all search strings are treated as literals. For example, "51.4 200" will be treated as two regular expressions because the first string contains an un-escaped dot, whereas "200 51.4" will be treated as two literals because the first string does not contain any meta-characters.
/G:file -默认值取决于文件中第一个非空行的内容。如果第一个搜索字符串是一个有效的正则表达式，包含至少一个未转义的元字符，那么所有搜索字符串都被视为正则表达式。否则，所有搜索字符串都被视为字面量。
建议-当使用"string argument"或/G:file时，总是显式指定/L文字选项或/R正则表达式选项。
指定多个文字搜索字符串会给出不可靠的结果
下面的简单FINDSTR示例无法找到匹配，尽管它应该找到匹配。
echo ffffaaa|findstr /l "ffffaaa faffaffddd"
此错误已在Windows Server 2003、Windows XP、Vista和Windows 7上确认。
根据实验，如果满足以下所有条件，FINDSTR可能会失败:
搜索使用多个文字搜索字符串 搜索字符串的长度不同 短搜索字符串与长搜索字符串有一定的重叠 搜索区分大小写(no /I选项)
在我所见过的每一次失败中，失败的总是一个较短的搜索字符串。
有关更多信息，请参阅为什么这个FINDSTR示例与多个文字搜索字符串无法找到匹配?
Quotes and backslahses within command line arguments Note - User MC ND's comments reflect the actual horrifically complicated rules for this section. There are 3 distinct parsing phases involved: First cmd.exe may require some quotes to be escaped as ^" (really nothing to do with FINDSTR) Next FINDSTR uses the pre 2008 MS C/C++ argument parser, which has special rules for " and \ After the argument parser finishes, FINDSTR additionally treats \ followed by an alpha-numeric character as literal, but \ followed by non-alpha-numeric character as an escape character The remainder of this highlighted section is not 100% correct. It can serve as a guide for many situations, but the above rules are required for total understanding. Escaping Quote within command line search strings Quotes within command line search strings must be escaped with backslash like \". This is true for both literal and regex search strings. This information has been confirmed on XP, Vista, and Windows 7. Note: The quote may also need to be escaped for the CMD.EXE parser, but this has nothing to do with FINDSTR. For example, to search for a single quote you could use: FINDSTR \^" file && echo found || echo not found Escaping Backslash within command line literal search strings Backslash in a literal search string can normally be represented as \ or as \\. They are typically equivalent. (There may be unusual cases in Vista where the backslash must always be escaped, but I no longer have a Vista machine to test). But there are some special cases: When searching for consecutive backslashes, all but the last must be escaped. The last backslash may optionally be escaped. \\ can be coded as \\\ or \\\\ \\\ can be coded as \\\\\ or \\\\\\ Searching for one or more backslashes before a quote is bizarre. Logic would suggest that the quote must be escaped, and each of the leading backslashes would need to be escaped, but this does not work! Instead, each of the leading backslashes must be double escaped, and the quote is escaped normally: \" must be coded as \\\\\" \\" must be coded as \\\\\\\\\" As previously noted, one or more escaped quotes may also require escaping with ^ for the CMD parser The info in this section has been confirmed on XP and Windows 7. Escaping Backslash within command line regex search strings Vista only: Backslash in a regex must be either double escaped like \\\\, or else single escaped within a character class set like [\\] XP and Windows 7: Backslash in a regex can always be represented as [\\]. It can normally be represented as \\. But this never works if the backslash precedes an escaped quote. One or more backslashes before an escaped quote must either be double escaped, or else coded as [\\] \" may be coded as \\\\\" or [\\]\" \\" may be coded as \\\\\\\\\" or [\\][\\]\" or \\[\\]\"
转义/G:FILE文本搜索字符串中的引号和反斜杠 由/G:file指定的文字搜索字符串文件中的独立引号和反斜杠不需要转义，但可以进行转义。
“和”是等价的。
\和\\是等价的。
如果目的是查找\\，那么至少必须转义前导反斜杠。\\\和\\\\都可以。
如果目的是查找"，那么至少前导反斜杠必须转义。“\\”和“\\\”都能用。
转义/G:FILE正则表达式搜索字符串中的引号和反斜杠 这是转义序列按照文档的预期工作的一种情况。Quote不是正则表达式元字符，因此不需要转义(但可以转义)。反斜杠是正则表达式元字符，因此必须转义。
命令行参数的字符限制。扩展ASCII转换 空字符(0x00)不能出现在命令行的任何字符串中。任何其他单字节字符都可以出现在字符串(0x01 - 0xFF)中。但是，FINDSTR将在命令行参数中找到的许多扩展ASCII字符转换为其他字符。这在两个方面产生了重大影响:
Many extended ASCII characters will not match themselves if used as a search string on the command line. This limitation is the same for literal and regex searches. If a search string must contain extended ASCII, then the /G:FILE option should be used instead. FINDSTR may fail to find a file if the name contains extended ASCII characters and the file name is specified on the command line. If a file to be searched contains extended ASCII in the name, then the /F:FILE option should be used instead.
下面是FINDSTR对命令行字符串执行的扩展ASCII字符转换的完整列表。每个字符都表示为十进制字节码值。第一个代码表示命令行上提供的字符，第二个代码表示它转换成的字符。注意:这个列表是在一台美国机器上编译的。我不知道其他语言对这个列表会有什么影响。
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都被视为本身，包括<CR>和<LF>。包含奇数字符(如<CR>和<LF>)的最简单方法是将它们放入环境变量中，并在命令行参数中使用延迟展开。
在/G:FILE和/F:FILE选项指定的文件中找到的字符串的字符限制 nul (0x00)字符可以出现在文件中，但它的功能类似于C字符串结束符。null字符之后的任何字符都被视为不同的字符串，就像它们在另一行一样。
<CR>和<LF>字符被视为终止字符串的行终止符，不包含在字符串中。
所有其他单字节字符都被完美地包含在字符串中。
搜索Unicode文件 FINDSTR不能正确搜索大多数Unicode (UTF-16、UTF-16LE、UTF-16BE、UTF-32)，因为它不能搜索空字节，而Unicode通常包含许多空字节。
然而，TYPE命令将带有BOM的UTF-16LE转换为单字节字符集，因此像下面这样的命令将使用带有BOM的UTF-16LE。
type unicode.txt|findstr "search"
请注意，活动代码页不支持的Unicode代码点将被转换为?字符。
只要您的搜索字符串只包含ASCII，就可以搜索UTF-8。但是，任何多字节UTF-8字符的控制台输出都是不正确的。但是如果您将输出重定向到一个文件，那么结果将被正确地编码为UTF-8。请注意，如果UTF-8文件包含一个BOM，那么该BOM将被视为第一行的一部分，这可能会抛出匹配一行开头的搜索。
如果您将搜索字符串放在UTF-8编码的搜索文件(不含BOM)中，并使用/G选项，则可以搜索多字节UTF-8字符。
行结束 FINDSTR在每个<LF>后立即换行。<CR>是否存在对换行符没有影响。
跨换行符搜索 不出所料，。regex元字符将不匹配<CR>或<LF>。但是可以使用命令行搜索字符串跨换行符进行搜索。<CR>和<LF>字符都必须显式匹配。如果找到多行匹配，则只打印匹配的第一行。FINDSTR然后翻回到源代码中的第二行，并重新开始搜索——这是一种“向前看”类型的特性。
假设TEXT.TXT包含以下内容(可以是Unix或Windows样式)
A
A
A
B
A
A
然后这个脚本
@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:A
2:A
5:A
使用/G:FILE选项跨换行搜索是不精确的，因为匹配<CR>或<LF>的唯一方法是通过一个正则表达式字符类范围表达式来夹住EOL字符。
[<TAB>-<0x0B>]匹配<LF>，但它也匹配<TAB>和<0x0B> (< 0 x0c > - - - - - - !]匹配<CR>，但它也匹配<0x0C>和!
注意——以上是正则字节流的符号表示，因为我不能图形化地表示这些字符。
在第二部分继续回答…
继续第一部分的回答-我已经达到了30,000个字符的回答限制:-(
有限的正则表达式支持 FINDSTR对正则表达式的支持非常有限。如果HELP文档中没有，则不支持。
除此之外，所支持的regex表达式是以完全非标准的方式实现的，因此结果可能与来自grep或perl等程序的预期结果不同。
正则表达式行位置锚^和$ ^匹配输入流的开始以及紧跟在<LF>后面的任何位置。因为FINDSTR也会在<LF>之后换行，所以简单的“^”正则表达式将始终匹配文件中的所有行，甚至是二进制文件。
$匹配紧挨着<CR>之前的任何位置。这意味着包含$的正则表达式搜索字符串永远不会匹配Unix样式文本文件中的任何行，如果缺少EOL标记<CR><LF>，它也不会匹配Windows文本文件的最后一行。
注意-如前所述，管道和重定向到FINDSTR的输入可能附加了不在源中的<CR><LF>。显然，这会影响使用$的正则表达式搜索。
任何在^之前或$之后有字符的搜索字符串总是找不到匹配。
位置选项/B /E /X 位置选项的工作原理与^和$相同，除了它们也适用于文字搜索字符串。
/B的功能与正则表达式搜索字符串开头的^相同。
/E的功能与正则表达式搜索字符串末尾的$相同。
/X的功能与正则表达式搜索字符串的开头和结尾都有^和$相同。
正则表达式字边界 \<必须是正则表达式中的第一个项。如果正则表达式前面有其他字符，则正则表达式将不匹配任何字符。\<对应于输入的最开始，一行的开始(紧跟在<LF>后面的位置)，或者紧跟在任何“非单词”字符后面的位置。下一个字符不必是“单词”字符。
\>必须是正则表达式中的最后一项。如果正则表达式后面有其他字符，则它将不匹配任何字符。\>对应于输入的结尾，紧挨着<CR>之前的位置，或者紧挨着任何“非单词”字符之前的位置。前面的字符不必是“word”字符。
下面是“非单词”字符的完整列表，用十进制字节代码表示。注意:这个列表是在一台美国机器上编译的。我不知道其他语言对这个列表会有什么影响。
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不能正确地处理case(在某些情况下)?，并附上这个答案:https://stackoverflow.com/a/8767815/1012053。
问题是FINDSTR不按字节码值(通常认为是ASCII码，但ASCII仅从0x00 - 0x7F定义)对字符进行排序。大多数regex实现将[A-Z]视为所有大写英文大写字母。但是FINDSTR使用大致对应于SORT工作方式的排序序列。所以[a - z]包括完整的英语字母，包括大写字母和小写字母(除了“a”)，以及带变音符的非英语alpha字符。
下面是FINDSTR支持的所有字符的完整列表，按照FINDSTR用于建立正则表达式字符类范围的排序顺序进行排序。字符以十进制字节码值表示。如果使用代码页437查看字符，我认为排序顺序最有意义。注意:这个列表是在一台美国机器上编译的。我不知道其他语言对这个列表会有什么影响。
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
Regex character class term limit and BUG Not only is FINDSTR limited to a maximum of 15 character class terms within a regex, it fails to properly handle an attempt to exceed the limit. Using 16 or more character class terms results in an interactive Windows pop up stating "Find String (QGREP) Utility has encountered a problem and needs to close. We are sorry for the inconvenience." The message text varies slightly depending on the Windows version. Here is one example of a FINDSTR that will fail:
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上已经得到确认。
Regex searches fail (and may hang indefinitely) if they include byte code 0xFF (decimal 255) Any regex search that includes byte code 0xFF (decimal 255) will fail. It fails if byte code 0xFF is included directly, or if it is implicitly included within a character class range. Remember that FINDSTR character class ranges do not collate characters based on the byte code value. Character <0xFF> appears relatively early in the collation sequence between the <space> and <tab> characters. So any character class range that includes both <space> and <tab> will fail.
具体的行为根据Windows版本稍有不同。如果包含0xFF, Windows 7将无限期挂起。XP不会挂起，但它总是找不到匹配的，并偶尔打印以下错误消息——“进程试图写入不存在的管道。”
我不能再使用Vista的机器，所以我不能在Vista上测试。
正则表达式错误:。和[^anySet]可以匹配End-Of-File 正则表达式。元字符只能匹配除<CR>或<LF>之外的任何字符。如果文件中的最后一行不以<CR>或<LF>结束，则允许它匹配End-Of-File。然而，。将不匹配空文件。
例如，一个名为"test.txt"的文件包含一行x，没有终止<CR>或<LF>，将匹配以下内容:
findstr /r x......... test.txt
这个bug已经在XP和Win7上得到确认。
负字符集似乎也是如此。像[^abc]这样的东西将匹配End-Of-File。像[abc]这样的正面字符集似乎很有效。我只在Win7上测试过这个功能。
在搜索大文件时，Findstr有时会意外挂起。
我还没有确认具体的条件和边界大小。我怀疑任何大于2GB的文件都可能存在风险。
我在这方面有过复杂的经历，所以这不仅仅是文件大小的问题。如果重定向输入不以LF结束，这看起来可能是挂在XP和Windows 7上的FINDSTR的变体，但正如所演示的，当输入没有重定向时，这个特定的问题就会出现。
下面的命令行会话(Windows 7)演示了findstr在搜索3GB文件时如何挂起。
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 1 020 000 016 T1GB.txt
2014/04/08 04:23 PM 1 020 T1KB.txt
2014/04/08 04:23 PM 1 020 000 T1MB.txt
2014/04/08 04:29 PM 3 060 000 049 T3GB.txt
5 File(s) 4 081 021 187 bytes
2 Dir(s) 51 881 050 112 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结束。唯一的异常是，由于复制的工作方式，文件以0x1A终止。但是请注意，这种异常不会对“小”文件造成问题。
通过额外的测试，我确认如下:
Using copy with the /b option for binary files prevents the addition of the 0x1A character, and findstr doesn't hang on the 3GB file. Terminating the 3GB file with a different character also causes a findstr to hang. The 0x1A character doesn't cause any problems on a "small" file. (Similarly for other terminating characters.) Adding CRLF after 0x1A resolves the problem. (LF by itself would probably suffice.) Using type to pipe the file into findstr works without hanging. (This might be due to a side effect of either type or | that inserts an additional End Of Line.) Use redirected input < also causes findstr to hang. But this is expected; as explained in dbenham's post: "redirected input must end in LF".
/D对于多个目录的提示:将目录列表放在搜索字符串之前。这些都有效:
findstr /D:dir1;dir2 "searchString" *.*
findstr /D:"dir1;dir2" "searchString" *.*
findstr /D:"\path\dir1\;\path\dir2\" "searchString" *.*
正如预期的那样，如果不以\开始目录，路径是相对于位置的。如果目录名中没有空格，则用"包围路径是可选的。结尾\是可选的。location的输出将包括您给它的任何路径。它可以在目录列表周围使用“”，也可以不使用。
当几个命令被括在括号中，并且有重定向文件到整个块:
< input.txt (
command1
command2
. . .
) > output.txt
．.． 然后，只要块中的命令处于活动状态，文件就保持打开状态，因此这些命令可能会移动重定向文件的文件指针。MORE和FIND命令在处理Stdin文件之前都将Stdin文件指针移动到文件的开头，因此同一个文件可能在块中被处理多次。例如，下面的代码:
more < input.txt > output.txt
more < input.txt >> output.txt
．.． 产生与此相同的结果:
< input.txt (
more
more
) > output.txt
这段代码:
find "search string" < input.txt > matchedLines.txt
find /V "search string" < input.txt > unmatchedLines.txt
．.． 产生与此相同的结果:
< input.txt (
find "search string" > matchedLines.txt
find /V "search string" > unmatchedLines.txt
)
FINDSTR则不同;它不会将Stdin文件指针从当前位置移动。例如，这段代码在搜索行之后插入新行:
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命令以颜色显示文本的详细信息，请参阅本主题。
When the output of this form of FINDSTR command is redirected to CON, something strange happens after the text is output in the desired color: all the text after it is output as "invisible" characters, although a more precise description is that the text is output as black text over black background. The original text will appear if you use COLOR command to reset the foreground and background colors of the entire screen. However, when the text is "invisible" we could execute a SET /P command, so all characters entered will not appear on the screen. This behavior may be used to enter passwords.
@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%"
我想报告一个关于在文件名中使用en - dash(-)或em - dash(-)时在第一个答案中搜索数据源的部分的错误。
更具体地说，如果您打算使用第一个选项—指定为参数的文件名，则无法找到该文件。只要使用选项2 -通过重定向的stdin或选项3 -来自管道的数据流，findstr就会找到该文件。
例如，这个简单的批处理脚本:
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
将打印:
带破折号的文件名:
作为参数 无法使用- dash.txt打开文件名 作为stdin通过重定向 我是带破折号的档案。 作为来自管道的数据流 我是带破折号的档案。
带em破折号的文件名:
作为参数 无法使用- dash.txt打开文件名 作为stdin通过重定向 我就是那个带破折号的文件。 作为来自管道的数据流 我就是那个带破折号的文件。
希望能有所帮助。
M.
findstr命令将ErrorLevel(或退出码)设置为以下值之一，假设没有无效或不兼容的开关，并且没有搜索字符串超过适用的长度限制:
当在所有指定文件的一行中至少遇到一个匹配时，返回0; 1本;
在以下情况下，一行被认为包含匹配项:
没有/V选项且搜索表达式至少出现一次; 给出/V选项，不出现搜索表达式;
这意味着/V选项也改变了返回的ErrorLevel，但它不只是恢复它!
例如，当你有一个文件test.txt有两行，其中一行包含字符串文本，但另一行不包含，findstr "text" "test.txt"和findstr /V "text" "test.txt"都返回0的ErrorLevel。
基本上你可以说:如果findstr返回至少一行，ErrorLevel设置为0，否则为1。
注意，/M选项不会影响ErrorLevel值，它只是改变输出。
(只是为了完整起见:find命令对于/V选项和ErrorLevel的行为完全相同;/C选项不会影响ErrorLevel。)
FINDSTR有一个颜色错误，我在https://superuser.com/questions/1535810/is-there-a-better-way-to-mitigate-this-obscure-color-bug-when-piping-to-findstr/1538802?noredirect=1#comment2339443_1538802上描述并解决了这个错误
总结一下这个线程，这个错误是，如果输入在括号内的代码块中被输送到FINDSTR，内联ANSI转义颜色代码将在以后执行的命令中停止工作。内联颜色代码的一个例子是:echo %magenta%Alert:发生了不好的事情%yellow%(其中magenta和yellow是前面在.bat文件中定义的变量，作为对应的ANSI转义颜色代码)。
我最初的解决方案是在FINDSTR之后调用一个什么都不做的子例程。调用或返回以某种方式“重置”需要重置的东西。
后来我发现了另一个可能更有效的解决方案:将FINDSTR短语放在括号内，如下例所示: echo success | (FINDSTR /R success) 将FINDSTR短语放置在嵌套代码块中似乎可以隔离FINDSTR的colorcode错误，这样它就不会影响嵌套代码块之外的内容。也许这种技术还可以解决其他一些不希望看到的FINDSTR副作用。
