前言
此答案中的大部分信息是根据在 Vista 机器上运行的实验收集的。除非另有明确说明，否则我尚未确认该信息是否适用于其他 Windows 版本。
FINDSTR 输出
文档从不费心解释 FINDSTR 的输出。它暗示了打印匹配行的事实，但仅此而已。
匹配行输出格式如下：
文件名：lineNumber：lineOffset：文本
在哪里
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 上显示为点
FINDSTR 在 XP 上将来自匹配行的大多数不可打印控制字符显示为屏幕上的点（句点）。以下控制字符是例外；它们显示为自己：0x09 Tab、0x0A LineFeed、0x0B Vertical Tab、0x0C Form Feed、0x0D Carriage Return。
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:file或未/G:file找到
- 255（错误）
要搜索的数据源 （根据 Windows 7 测试更新）
Findstr 只能从以下来源之一搜索数据：
参数/选项优先于重定向，重定向优先于管道数据。
文件名参数，/F:file可以组合。可以使用多个文件名参数。如果指定了多个/F:file选项，则只使用最后一个。文件名参数中允许使用通配符，但在 . 指向的文件中不允许使用通配符/F:file。
搜索字符串的来源 （根据 Windows 7 测试更新）
和选项可以组合。可以指定多个选项。如果指定了多个选项，则只使用最后一个。如果使用or ，则所有非选项参数都被假定为要搜索的文件。如果既不使用也不使用，则第一个非选项参数被视为以空格分隔的搜索词列表。/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 名称。假设当前文件夹包含以下非空文件：
b1.txt
b.txt2
c.txt
以下命令将成功找到所有 3 个文件：
findstr /m "^" *.txt
b.txt2匹配，因为相应的短名称B9F64~1.TXT匹配。这与所有其他 Windows 命令的行为一致。
但是/Dand/S选项的错误导致以下命令只能找到b1.txt
findstr /m /d:. "^" *.txt
findstr /m /s "^" *.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 将以下控制字符视为可打印：
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 不会改变重定向输入。
如果重定向输入不以结尾，FINDSTR 在 XP 和 Windows 7 上挂起<LF>
这是 XP 和 Windows 7 上的一个讨厌的“功能”。如果用作重定向输入的文件的最后一个字符不以 结尾<LF>，那么 FINDSTR 将无限期挂起到达重定向文件的末尾。
如果管道数据的最后一行由单个字符组成，则可以忽略它
如果输入是管道输入并且最后一行由一个没有后跟的单个字符组成<LF>，则 FINDSTR 完全忽略最后一行。
示例 - 第一个具有单个字符且 no 的命令<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.*goodbye" /c:"goodbye.*hello"
-i -r -c:"hello.*goodbye" /c:"goodbye.*hello"
/irc:"hello.*goodbye" /c:"goodbye.*hello"
选项也可能被引用。所以/i, -i,"/i"和"-i"都是等价的。同样，、/c:string和都是等价的。"/c":string"/c:"string"/c:string"
如果搜索字符串以/or-文字开头，则必须使用/Cor选项。/G感谢Stephan在评论中报告此问题（已删除）。
搜索字符串长度限制
在 Vista 上，单个搜索字符串的最大允许长度为 511 个字节。如果任何搜索字符串超过 511，则结果是FINDSTR: Search string too long.ERRORLEVEL 2 的错误。
进行正则表达式搜索时，最大搜索字符串长度为 254。长度在 255 和 511 之间的正则表达式将导致FINDSTR: Out of memory错误 ERRORLEVEL 2。正则表达式长度 >511 将导致FINDSTR: Search string too long.错误。
在 Windows XP 上，搜索字符串的长度显然更短。Findstr 错误：“搜索字符串太长”：如何在“for”循环中提取和匹配子字符串？
对于文字和正则表达式搜索，XP 限制为 127 个字节。
行长度限制
指定为命令行参数或通过 /F:FILE 选项指定的文件没有已知的行长度限制。对不包含单个 <LF> 的 128MB 文件成功运行搜索。
管道数据和重定向输入限制为每行 8191 个字节。此限制是 FINDSTR 的“功能”。它不是管道或重定向所固有的。使用重定向标准输入或管道输入的 FINDSTR 永远不会匹配 >=8k 字节的任何行。Lines >= 8k 向 stderr 生成错误消息，但如果在至少一个文件的至少一行中找到搜索字符串，则 ERRORLEVEL 仍为 0。
默认搜索类型：文字与正则表达式
/C:"string"- 默认为 /L 文字。将 /L 选项与 /C:"string" 显式组合当然有效，但也是多余的。
"string argument"- 默认值取决于第一个搜索字符串的内容。（请记住，<space> 用于分隔搜索字符串。）如果第一个搜索字符串是有效的正则表达式，并且至少包含一个未转义的元字符，则所有搜索字符串都被视为正则表达式。否则，所有搜索字符串都被视为文字。例如，"51.4 200"将被视为两个正则表达式，因为第一个字符串包含未转义的点，而"200 51.4"将被视为两个文字，因为第一个字符串不包含任何元字符。
/G:file- 默认值取决于文件中第一个非空行的内容。如果第一个搜索字符串是包含至少一个未转义元字符的有效正则表达式，则所有搜索字符串都被视为正则表达式。否则，所有搜索字符串都被视为文字。
建议 - 使用时始终明确指定/L文字选项或/R正则表达式选项"string argument"or /G:file。
BUG - 指定多个文字搜索字符串可能会产生不可靠的结果
以下简单的 FINDSTR 示例无法找到匹配项，即使它应该找到。
echo ffffaaa|findstr /l "ffffaaa faffaffddd"
此错误已在 Windows Server 2003、Windows XP、Vista 和 Windows 7 上得到确认。
根据实验，如果满足以下所有条件，FINDSTR 可能会失败：
- 搜索使用多个文字搜索字符串
- 搜索字符串的长度不同
- 较短的搜索字符串与较长的搜索字符串有一定程度的重叠
- 搜索区分大小写（无
/I选项）
在我看到的每一次失败中，失败的总是较短的搜索字符串之一。
有关更多信息，请参阅为什么这个具有多个文字搜索字符串的 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 正则表达式搜索字符串中转义引号和反斜杠
这是转义序列根据文档按预期工作的一种情况。引号不是正则表达式元字符，因此不需要转义（但可以转义）。反斜杠是一个正则表达式元字符，所以它必须被转义。
命令行参数的字符限制 - 扩展 ASCII 转换
空字符 (0x00) 不能出现在命令行的任何字符串中。任何其他单字节字符都可以出现在字符串中 (0x01 - 0xFF)。但是，FINDSTR 会将它在命令行参数中找到的许多扩展 ASCII 字符转换为其他字符。这在两个方面产生了重大影响：
如果在命令行上用作搜索字符串，许多扩展的 ASCII 字符将不会匹配它们自己。对于文字和正则表达式搜索，此限制是相同的。如果搜索字符串必须包含扩展 ASCII，/G:FILE则应使用该选项。
如果名称包含扩展的 ASCII 字符并且在命令行上指定了文件名，则 FINDSTR 可能无法找到文件。如果要搜索的文件在名称中包含扩展的 ASCII，/F:FILE则应使用该选项。
这是 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 字符串终止符。nul 字符之后的任何字符都被视为不同的字符串，就好像它们在另一行上一样。
<CR>和<LF>字符被视为终止字符串的行终止符，并且不包含在字符串中。
所有其他单字节字符都完美地包含在字符串中。
搜索 Unicode 文件
FINDSTR 无法正确搜索大多数 Unicode（UTF-16、UTF-16LE、UTF-16BE、UTF-32），因为它无法搜索 nul 字节并且 Unicode 通常包含许多 nul 字节。
但是，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> 的存在与否对换行没有影响。
跨换行符搜索
正如预期的那样，.正则表达式元字符将不匹配 <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 字符夹在中间的正则表达式字符类范围表达式。
注意 - 以上是正则表达式字节流的符号表示，因为我无法以图形方式表示字符。
答案在下面的第 2 部分继续......