什么是Windows FINDSTR命令的无证功能和限制？ [英] What are the undocumented features and limitations of the Windows FINDSTR command?

问题描述

在Windows FINDSTR命令是可怕的记录。有一个可用非常​​简单的命令行帮助通过 FINDSTR /？或 HELP FINDSTR ，却是少得可怜。还有更多的一丁点在线文档在<一个href=\"http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/findstr.mspx?mfr=true\">http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/findstr.mspx?mfr=true.

The Windows FINDSTR command is horribly documented. There is very basic command line help available through FINDSTR /?, or HELP FINDSTR, but it is woefully inadequate. There is a wee bit more documentation online at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/findstr.mspx?mfr=true.

有未在文件中甚至暗示许多FINDSTR功能和限制。也不可能，他们没有事先知识和/或认真尝试，可以预期。

There are many FINDSTR features and limitations that are not even hinted at in the documentation. Nor could they be anticipated without prior knowledge and/or careful experimentation.

所以，问题是 - 什么是无证FINDSTR功能和限制

So the question is - What are the undocumented FINDSTR features and limitations?

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

The purpose of this question is to provide a one stop repository of the many undocumented features so that:

A）开发人员可以利用那些有功能全面的优势。

A) Developers can take full advantage of the features that are there.

B）开发商不浪费自己的时间想知道为什么东西不工作时，它看起来像它应该。

B) Developers don't waste their time wondering why something doesn't work when it seems like it should.

请确保您知道响应之前已有的文档。如果信息被HELP覆盖，那么它不属于这里。

Please make sure you know the existing documentation before responding. If the information is covered by the HELP, then it does not belong here.

这都不是显示FINDSTR有趣的用途的地方。如果一个逻辑人可以预见基于文档的FINDSTR特定使用的行为，那么它不属于这里。

Neither is this a place to show interesting uses of FINDSTR. If a logical person could anticipate the behavior of a particular usage of FINDSTR based on the documentation, then it does not belong here.

按照同样的思路，如果一个合乎逻辑的人可以预见基于包含在任何现有的答案信息的特殊用途的行为，然后再次，它不属于这里。

Along the same lines, if a logical person could anticipate the behavior of a particular usage based on information contained in any existing answers, then again, it does not belong here.

推荐答案

preface 的

的大部分在这个答案的信息是基于聚集在实验Vista的计算机上运行。除非另有明确规定，我还没有证实的信息是否适用于其他Windows版本。的

FINDSTR输出

文档从未困扰解释FINDSTR输出。它暗示了一个事实，即匹配行打印，但仅此而已。

FINDSTR output
The documentation never bothers to explain the output of FINDSTR. It alludes to the fact that matching lines are printed, but nothing more.

匹配行输出的格式如下：

The format of matching line output is as follows:

文件名：行号：lineOffset：文本的

filename:lineNumber:lineOffset:text

其中，

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

fileName: = The name of the file containing the matching line. The file name is not printed if the request was explicitly for a single file, or if searching piped input or redirected input. When printed, the fileName will always include any path information provided. Additional path information will be added if the /S option is used. The printed path is always relative to the provided path, or relative to the current directory if none provided.

注 - 可以使用的非标（和不良记录）通配符 ＆LT; 和＆GT; 。这些通配符是如何工作的确切规则可以在这里找到 。最后，你可以看看的非标准通配符是如何工作的这个例子与FINDSTR 。

Note - The filename prefix can be avoided when searching multiple files by using the non-standard (and poorly documented) wildcards < and >. The exact rules for how these wildcards work can be found here. Finally, you can look at this example of how the non-standard wildcards work with FINDSTR.

行号：的 = psented与1重presenting输入一号线十进制值匹配的行再$ P $的行号。只有当指定 / N 选项打印。

lineOffset：的 =小数字节的匹配行的开始偏移，0重新presenting一号线的第一个字符。只有当 / O 指定选项打印。这是的不的的行内匹配的偏移量。它是一个字节从文件到该行的开头的开始数目。

lineOffset: = The decimal byte offset of the start of the matching line, with 0 representing the 1st character of the 1st line. Only printed if /O option is specified. This is not the offset of the match within the line. It is the number of bytes from the beginning of the file to the beginning of the line.

文本的 =匹配线的二进制重新presentation，包括任何与LT; CR>和/或LT; LF>。没有什么是冷落的二进制输出，比如，这个例子的所有行匹配会产生原始文件的确切的二进制副本。

text = The binary representation of the matching line, including any <CR> and/or <LF>. Nothing is left out of the binary output, such that this example that matches all lines will produce an exact binary copy of the original file.

FINDSTR "^" FILE >FILE_COPY

大多数控制字符和许多扩展ASCII字符显示为在XP
点
FINDSTR在XP上显示从匹配屏幕上的行为点（段）最不可打印控制字符。下面的控制字符例外;它们显示以自己：为0x09选项卡，0x0A的换行，0x0B中垂直制表，表格的0x0C饲料，0X0D回车

Most control characters and many extended ASCII characters display as dots on XP
FINDSTR on XP displays most non-printable control characters from matching lines as dots (periods) on the screen. The following control characters are exceptions; they display as themselves: 0x09 Tab, 0x0A LineFeed, 0x0B Vertical Tab, 0x0C Form Feed, 0x0D Carriage Return.

XP FINDSTR也可将数字转换的扩展ASCII字符圆点为好。这显示为对XP点的扩展ASCII字符相同的命令行上时被转化。看到的的字符数限制为命令行参数 - 扩展ASCII转型的部分，以后在这个帖子

XP FINDSTR also converts a number of extended ASCII characters to dots as well. The extended ASCII characters that display as dots on XP are the same as those that are transformed when supplied on the command line. See the "Character limits for command line parameters - Extended ASCII transformation" section, later in this post

如果它的管道输出，重定向到一个文件，或者在（）子句中控制字符和扩展ASCII不会转换为点在XP。

Control characters and extended ASCII are not converted to dots on XP if the output is piped, redirected to a file, or within a FOR IN() clause.

Vista和Windows 7中始终显示所有的字符，永不为点。

Vista and Windows 7 always display all characters as themselves, never as dots.

返回code

设置错误级别向0（成功），如果匹配是在至少一个文件中的至少一个线中。

会将ERRORLEVEL设置为1（失败）如果比赛没有任何文件的任何行中。

Return Code
Sets ERRORLEVEL to 0 (success) if match is found in at least one line of at least one file.
Sets ERRORLEVEL TO 1 (failure) if a match is not found in any line of any file.

数据来源进行搜索 （基于与Windows 7的测试更新）的

Source of data to search (Updated based on tests with Windows 7)
Findstr can search data from only one of the following sources:

• 指定为参数和/或使用文件名/ F：。文件选项

通过标准输入重定向 FINDSTR搜索字符串＆LT;文件

从管道中的数据流键入文件| FINDSTR搜索字符串

参数/选项采用precedence了重定向，这需要precedence过管道的数据。

Arguments/options take precedence over redirection, which takes precedence over piped data.

文件名参数和 / F：文件可合并。可以使用多个文件名的参数。如果多个 / F：文件选项指定，则使用只有最后一个。通配符被允许在文件名参数，而不是内部文件被指向 / F：。文件

File name arguments and /F:file may be combined. Multiple file name arguments may be used. If multiple /F:file options are specified, then only the last one is used. Wild cards are allowed in filename arguments, but not within the file pointed to by /F:file.

搜索字符串源 （更新基于测试与Windows 7）的

在 / G：文件和 / C：字符串选项可以组合。多个 / C：字符串选项可能被指定。如果多个 / G：文件选项指定，则使用只有最后一个。如果 / G：文件或 / C：字符串时，则所有非选项参数假定文件进行搜索。如果没有 / G：文件也不 / C：字符串被使用，那么第一个非选项参数被视为搜索字词的空格分隔列表。

Source of search strings (Updated based on tests with Windows 7)
The /G:file and /C:string options may be combined. Multiple /C:string options may be specified. If multiple /G:file options are specified, then only the last one is used. If either /G:file or /C:string is used, then all non-option arguments are assumed to be files to search. If neither /G:file nor /C:string is used, then the first non-option argument is treated as a space delimited list of search terms.

文件名不得使用时，在文件中引用/ F：。文件选项

文件名可以包含空格和其它特殊字符。大多数命令都需要这样的文件名被引用。但FINDSTR /F:files.txt 选项要求files.txt内的文件名必须不能被引用。如果名称是引用的文件不会被发现。

File names must not be quoted within the file when using the /F:FILE option.
File names may contain spaces and other special characters. Most commands require that such file names are quoted. But the FINDSTR /F:files.txt option requires that filenames within files.txt must NOT be quoted. The file will not be found if the name is quoted.

BUG - 短8.3文件名可以打破 / D 和 / S 选项

与所有的Windows命令，FINDSTR将尝试寻找文件中搜索时，同时匹配的长名称和短8.3名。假定当前文件夹包含以下非空文件：

BUG - Short 8.3 filenames can break the /D and /S options
As with all Windows commands, FINDSTR will attempt to match both the long name and the short 8.3 name when looking for files to search. Assume the current folder contains the following non-empty files:

b1.txt
b.txt2
c.txt

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

The following command will successfully find all 3 files:

findstr /m "^" *.txt

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

b.txt2 matches because the corresponding short name B9F64~1.TXT matches. This is consistent with the behavior of all other Windows commands.

但与 / D 和 / S 选项的错误会导致以下命令只能找到 b1.txt

But a bug with the /D and /S options causes the following commands to only find b1.txt

findstr /m /d:. "^" *.txt
findstr /m /s "^" *.txt

该bug prevents b.txt2 被发现，以及所有文件名诸如此类后 b.txt2 在同一目录中。那种前，如 A.TXT ，被发现的其他文件。那种之后，如 d.txt ，一旦有错误被触发错过其他文件。

The bug prevents b.txt2 from being found, as well as all file names that sort after b.txt2 within the same directory. Additional files that sort before, like a.txt, are found. Additional files that sort later, like d.txt, are missed once the bug has been triggered.

搜索每个目录单独处理。例如， / S 选项将成功地开始没有找到在父文件后，寻找在子文件夹，但一旦错误导致短文件名在错过孩子，然后在子文件夹的所有后续文件也将错过。

Each directory searched is treated independently. For example, the /S option would successfully begin searching in a child folder after failing to find files in the parent, but once the bug causes a short file name to be missed in the child, then all subsequent files in that child folder would also be missed.

的命令的工作无缺陷，如果有NTFS 8.3名称生成禁用一台机器上创建相同的文件名。当然， b.txt2 将不会被发现，但 c.txt 将正确找到。

The commands work bug free if the same file names are created on a machine that has NTFS 8.3 name generation disabled. Of course b.txt2 would not be found, but c.txt would be found properly.

不是所有的短名称触发该漏洞。我见过的窃听行为的所有实例涉及的延伸长度超过3个字符与开头一样不需要8.3名普通的名字很短的8.3名。

Not all short names trigger the bug. All instances of bugged behavior I have seen involve an extension that is longer than 3 characters with a short 8.3 name that begins the same as a normal name that does not require an 8.3 name.

该错误已被证实在XP，Vista和Windows 7。

The bug has been confirmed on XP, Vista, and Windows 7.

非打印字符和 / P 选项

在 / P 选项将导致FINDSTR跳过包含以下任何小数字节$ C $的CS的任何文件：

0-7，14-25，27-31。

Non-Printable characters and the /P option
The /P option causes FINDSTR to skip any file that contains any of the following decimal byte codes:
0-7, 14-25, 27-31.

换句话说，在 / P 选项才会跳过包含非打印控制字符的文件。控制字符codeS小于或等于31（0x1F的）。 FINDSTR对待下面的控制字符作为可打印的：

Put another way, the /P option will only skip files that contain non-printable control characters. Control characters are codes less than or equal to 31 (0x1F). FINDSTR treats the following control characters as printable:

 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)

所有其他控制字符都被视为不可打印时，presence其中引起 / P 选项来跳过该文件。

管道输送和重定向的输入可能有＆LT; CR＆GT;＆LT; LF＆GT; 追加

如果输入的是管道和流的最后一个字符不是＆LT; LF＆GT; ，然后FINDSTR会自动追加＆LT; CR＆GT;＆LT; LF＆GT; 来输入。这已被证实在XP，Vista和Windows 7的（我常想，在Windows管负责修改输入，但是我后来发现，FINDSTR实际上是在做修改。）的

Piped and Redirected input may have <CR><LF> appended
If the input is piped in and the last character of the stream is not <LF>, then FINDSTR will automatically append <CR><LF> to the input. This has been confirmed on XP, Vista and Windows 7. (I used to think that the Windows pipe was responsible for modifying the input, but I have since discovered that FINDSTR is actually doing the modification.)

同样是在Vista上重定向输入正确的。如果用作重定向输入文件的最后一个字符不是＆LT; LF＆GT; ，然后FINDSTR会自动追加＆LT; CR＆GT;＆LT; LF＆GT; 来输入。但是，XP和Windows 7不会改变重定向输入。

The same is true for redirected input on Vista. If the last character of a file used as redirected input is not <LF>, then FINDSTR will automatically append <CR><LF> to the input. However, XP and Windows 7 do not alter redirected input.

如果重定向输入不符合＆LT结束对XP和Windows 7的 FINDSTR挂起; LF＆GT;

这是XP和Windows 7的一个讨厌的功能如果一个文件的最后一个字符作为重定向输入不符合＆LT结束; LF＆GT; ，然后FINDSTR将挂起无限期一旦到达重定向的文件的末尾。

FINDSTR hangs on XP and Windows 7 if redirected input does not end with <LF>
This is a nasty "feature" on XP and Windows 7. If the last character of a file used as redirected input does not end with <LF>, then FINDSTR will hang indefinitely once it reaches the end of the redirected file.

管道输送数据的最后一行也可以，如果它是由一个单独的字符忽略

如果输入的管道，最后行包括未后跟单个字符的＆LT; LF方式＆gt; ，然后FINDSTR完全忽略了最后一行

Last line of Piped data may be ignored if it consists of a single character
If the input is piped in and the last line consists of a single character that is not followed by <LF>, then FINDSTR completely ignores the last line.

示例 - 使用单个字符，和第一个命令没有＆LT; LF＆GT; 不匹配，但与2个字符第二个命令工作正常，一样的第三个命令一个与终止换行一个字符。

Example - The first command with a single character and no <LF> fails to match, but the second command with 2 characters works fine, as does the third command that has one character with terminating newline.

> set /p "=x" <nul | findstr "^"

> set /p "=xx" <nul | findstr "^"
xx

> echo x| findstr "^"
x

由DosTips用户海绵肚皮在新FINDSTR错误报道。证实XP，Windows 7和Windows 8还没有听说过Vista的呢。 （我不再有Vista的测试）。

Reported by DosTips user Sponge Belly at new findstr bug. Confirmed on XP, Windows 7 and Windows 8. Haven't heard about Vista yet. (I no longer have Vista to test).

选项语法

选项​​可以与pfixed $ P $或者 / 或 -
选项​​可以在单个后级联/ 或 - 。然而，级联选项列表可以含有至多一个多字符选项，如关或F：与多字符选项必须在列表的最后一个选项。

Option syntax
Options can be prefixed with either / or - Options may be concatenated after a single / or -. However, the concatenated option list may contain at most one multicharacter option such as OFF or F:, and the multi-character option must be the last option in the list.

以下是前$ P $的pssing既包含你好，以任何顺序再见

The following are all equivalent ways of expressing a case insensitive regex search for any line that contains both "hello" and "goodbye" in any order

• / I / R /c:\"hello.*goodbye/c:\"goodbye.*hello

-i -r -c：你好*再见/c:\"goodbye.*hello

/ IRC：你好*再见/c:\"goodbye.*hello

搜索字符串长度的限制

在Vista允许的长度为一个单一的搜索字符串，最大为511个字节。如果任何搜索字符串超过了511，那么结果是 FINDSTR：用ERRORLEVEL 2搜索字符串太长错误

在做一个普通的前pression搜索时，最大搜索字符串长度为254 255和511之间的长度定期EX pression将导致 FINDSTR：内存不足误差ERRORLEVEL 2.定期EX pression长度> 511导致 FINDSTR：搜索字符串太长错误

When doing a regular expression search, the maximum search string length is 254. A regular expression with length between 255 and 511 will result in a FINDSTR: Out of memory error with ERRORLEVEL 2. A regular expression length >511 results in the FINDSTR: Search string too long. error.

在Windows XP中搜索字符串的长度显然短。 <一href=\"http://groups.google.com/group/alt.msdos.batch.nt/browse_thread/thread/9f7e951942da7155\">Findstr错误：搜索字符串太长：如何提取和匹配子在for循环？
XP的限制是两个文字和正则表达式搜索127个字节。

On Windows XP the search string length is apparently shorter. Findstr error: "Search string too long": How to extract and match substring in "for" loop? The XP limit is 127 bytes for both literal and regex searches.

线长限制

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

Line Length limits
Files specified as a command line argument or via the /F:FILE option have no known line length limit. Searches were successfully run against a 128MB file that did not contain a single <LF>.

管道数据和重定向输入被限定每行8191个字节。此限制FINDSTR的功能。它不是固有的管道或重定向。 FINDSTR使用重定向标准输入或者管道输入绝不会匹配任何行是> = 8K字节。行> = 8K产生错误信息到stderr，但ERRORLEVEL仍然是0，如果搜索字符串在至少一个文件中的至少一个行找到。

Piped data and Redirected input is limited to 8191 bytes per line. This limit is a "feature" of FINDSTR. It is not inherent to pipes or redirection. FINDSTR using redirected stdin or piped input will never match any line that is >=8k bytes. Lines >= 8k generate an error message to stderr, but ERRORLEVEL is still 0 if the search string is found in at least one line of at least one file.

默认搜索类型：文字VS普通防爆pression

/ C：串 - 默认为/ L文字。明确地结合/ C / L选项：串当然有效，但是多余的。

Default type of search: Literal vs Regular Expression
/C:"string" - The default is /L literal. Explicitly combining the /L option with /C:"string" certainly works but is redundant.

字符串参数 - 默认依赖于第一个搜索字符串的内容。的（记住，＆LT;空间>用于分隔搜索字符串）的如果第一个搜索字符串是一个有效的常规前pression包含至少一个非转义元字符，那么所有搜索字符串被视为常规的前pressions。否则，所有的搜索字符串被视为文字。例如，51.4 200将被视为两个经常EX pressions因为第一个字符串包含非转义点，而 200 51.4将被视为两个文字，因为第一个字符串不包含任何元字符。

"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：文件 - 默认依赖于文件中的第一个非空行的内容。如果第一个搜索字符串是包含至少一个非转义元字符有效的规则前pression，那么所有的搜索字符串被视为常规的前pressions。否则，所有的搜索字符串都被视为文字。

/G:file - The default depends on the content of the first non-empty line in the file. 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.

的建议 - 始终明确指定 / L 文字选项或 / R 常规EX pression 。文件 的

Recommendation - Always explicitly specify /L literal option or /R regular expression option when using "string argument" or /G:file.

错误 - 指定多个文字搜索字符串可以给不可靠的结果

下面这个简单的例子FINDSTR无法找到匹配，即使它应该。

The following simple FINDSTR example fails to find a match, even though it should.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

此bug已证实在Windows Server 2003和Windows XP，Vista和Windows 7。

This bug has been confirmed on Windows Server 2003, Windows XP, Vista, and Windows 7.

如果下列所有条件都满足，FINDSTR可能失败：

Based on experiments, FINDSTR may fail if all of the following conditions are met:

• 搜索是使用多个文字搜索字符串


• 的搜索字符串的长度不同


• 短搜索字符串有一个较长的搜索字符串
重叠一定量

• 搜索是大小写敏感的（无/ I选项）

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

In every failure I have seen, it is always one of the shorter search strings that fails.

有关更多信息请参见<一个href=\"http://stackoverflow.com/questions/8921253/why-doesnt-this-findstr-example-with-multiple-literal-search-strings-find-a-mat/8921279#8921279\">Why不使用多个文字搜索字符串FINDSTR这个例子找到一个匹配？

命令行搜索字符串中的逃离报价

命令行搜索字符串中的引号必须用反斜线转义像 \\，这对于包括文本和正则表达式搜索字符串真。本信息已经被证实在XP，Vista和Windows 7操作系统。

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.

的注：该报价可能还需要进行转义为CMD.EXE解析器，但这无关FINDSTR。例如，要搜索，你可以使用一个单引号：的

FINDSTR \\ ^档案与和放大器;回声发现||回声没有找到

中转义反斜线命令行文字搜索字符串内

反斜线文字搜索字符串能够正常进行重新psented为 \\ $ P $或 \\\\ 。它们通常当量。的（有可能是不寻常的情况下，在Vista中，其中反斜杠必须始终逃脱了，但我不再有Vista的机器进行测试）的

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).

但也有一些特殊情况：

当寻找连续的反斜杠，除了最后的必须的转义。最后一个反斜杠可以选择性地逃脱了。

When searching for consecutive backslashes, all but the last must be escaped. The last backslash may optionally be escaped.

• \\\\ 可以是codeD为 \\\\\\ 或 \\\\ \\\\


• \\\\\\ 可以是codeD为 \\\\\\\\\\ 或 \\\\\\\\\\\\

• \\ 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:

• \\必须是codeD为 \\\\\\\\\\


• \\\\必须是codeD为 \\\\\\\\\\\\\\\\\\

• \" must be coded as \\\\\"
• \\" must be coded as \\\\\\\\\"

的作为previously指出，一个或多个转义引号也可能需要使用转义 ^ 的CMD解析器的

As previously noted, one or more escaped quotes may also require escaping with ^ for the CMD parser

在本节中的信息已经证实XP和Windows 7。

The info in this section has been confirmed on XP and Windows 7.

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

• 仅适用于Vista：反斜线正则表达式必须是双转义像 \\\\\\\\ ，否则单内逃脱字符类设置类似 [\\\\]

• Vista only: Backslash in a regex must be either double escaped like \\\\, or else single escaped within a character class set like [\\]

XP和Windows 7：psented为 的正则表达式反斜杠总是可以重新$ P $ [\\\\] 。它通常可以重新psented为 $ P $ \\\\ 。但是，如果反斜线precedes一个转义引用这永远不会奏效。

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.

转义报价之前的一个或多个反斜杠必须要么被双逃脱，否则codeD为 [\\\\]

One or more backslashes before an escaped quote must either be double escaped, or else coded as [\\]

• \\可能是codeD为 \\\\\\\\\\或 [\\\\] \\


• \\\\可能是codeD为 \\\\\\\\\\\\\\\\\\或 [\\\\] [\\\\] \\或 \\\\ [\\\\] \\

• \" may be coded as \\\\\" or [\\]\"
• \\" may be coded as \\\\\\\\\" or [\\][\\]\" or \\[\\]\"

摆脱报价和反斜杠/ G中：文件的文字搜索字符串

由/ G指定的文字搜索字符串文件中独立引号和反斜杠：文件不需要逃过一劫，但也可以是

Escaping Quote and Backslash within /G:FILE literal search strings
Standalone quotes and backslashes within a literal search string file specified by /G:file need not be escaped, but they can be.

和 \\是等价的。

\\ 和 \\\\ 是等价的。

如果目的是要找到\\\\的话，至少领先的反斜线必须被转义。无论 \\\\\\ 和 \\\\\\\\ 工作

If the intent is to find \\, then at least the leading backslash must be escaped. Both \\\ and \\\\ work.

如果目的是要找到\\，那么至少领先的反斜线必须被转义。这两个 \\\\和 \\\\\\ 工作

If the intent is to find \", then at least the leading backslash must be escaped. Both \\" and \\\" work.

摆脱报价和反斜杠/ G中：文件正则表达式搜索字符串

这是一个情况下转义序列的工作基于文档预期。报价是不是一个正则表达式元字符，因此不必进行转义（但可以）。反斜杠是一个正则表达式元字符，所以它必须被转义。

Escaping Quote and Backslash within /G:FILE regex search strings
This is the one case where the escape sequences work as expected based on the documentation. Quote is not a regex metacharacter, so it need not be escaped (but can be). Backslash is a regex metacharacter, so it must be escaped.

字符数限制的命令行参数 - 扩展ASCII改造

空字符（0×00）不能出现在命令行上的任何字符串。任何其他的单字节字符可以出现在字符串（0×01 - 0xFF的）英寸然而，FINDSTR转换中的命令行参数转换成其他字符发现许多扩展ASCII字符。这具有在两方面产生重大影响：

Character limits for command line parameters - Extended ASCII transformation
The null character (0x00) cannot appear in any string on the command line. Any other single byte character can appear in the string (0x01 - 0xFF). However, FINDSTR converts many extended ASCII characters it finds within command line parameters into other characters. This has a major impact in two ways:

1），如果作为命令行中搜索字符串许多扩展ASCII字符将不匹配自己。这种限制是文字，正则表达式搜索相同。如果搜索字符串必须包含扩展ASCII，那么 / G：文件选项应改为使用

1) 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.

2）FINDSTR可能无法找到一个文件，如果名称包含扩展ASCII字符，文件名是在命令行上指定。如果要搜索的文件包含扩展ASCII的名义，那么 / F：。文件选项应改为使用

2) 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字符转换的完整列表。每个字符重新psented作为小数字节code值$ P $。第一code再presents在命令行上提供的字符，第二个code再presents它转化为字符。 注 - 这个名单是编制了中美机器上。我不知道其他语言可能有这个名单上有什么影响。的

Here is a complete list of extended ASCII character transformations that FINDSTR performs on command line strings. Each character is represented as the decimal byte code value. The first code represents the character as supplied on the command line, and the second code represents the character it is transformed into. Note - this list was compiled on a U.S machine. I do not know what impact other languages may have on this list.

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未在列表上方被视为本身，包括＆LT; CR＆GT; 和＆lt; LF＆GT; 。最简单的方法，包括奇怪的字符如＆LT; CR＆GT; 和＆LT; LF＆GT; 是让他们到一个环境变量和使用延迟命令行参数范围内的扩张。

Any character >0 not in the list above is treated as itself, including <CR> and <LF>. The easiest way to include odd characters like <CR> and <LF> is to get them into an environment variable and use delayed expansion within the command line argument.

这是/ G指定的文件中找到字符串字符数限制：文件和/ F：文件选项

该NUL（0×00）字符可以出现在文件中，但它的功能类似于C字符串结束。一个空字符之后的任何字符都被视为一个不同的字符串，如果他们在另一条线路。

Character limits for strings found in files specified by /G:FILE and /F:FILE options
The nul (0x00) character can appear in the file, but it functions like the C string terminator. Any characters after a nul character are treated as a different string as if they were on another line.

的＆LT; CR＆GT; 和＆LT; LF＆GT; 字符被视为行结束了终止字符串，并且不包括字符串中

The <CR> and <LF> characters are treated as line terminators that terminate a string, and are not included in the string.

所有其它单字节字符完全包含在字符串中。

All other single byte characters are included perfectly within a string.

的Uni code文本不能被搜索直接的

的 FINDSTR无法正常搜索的Uni code文件，因为它无法搜索NUL字节，统一code通常包含许多NUL字节。然而，TYPE命令统一code转换为单字节字符集，所以类似下面的命令将UNI code工作。的

type unicode.txt|findstr "search"

行尾

FINDSTR打破后，立即与每一个LT线; LF>。在presence与否的LT＆; CR>对换行没有任何影响

End Of Line
FINDSTR breaks lines immediately after every <LF>. The presence or absence of <CR> has no impact on line breaks.

跨线搜索突破

正如所料，在 正则表达式元字符将不匹配＆LT; CR>或LT; LF>。但它有可能在整个使用命令行搜索字符串换行符进行搜索。无论在＆lt; CR>和＆lt; LF>字符必须被明确匹配。如果多行匹配，只有在比赛的第1行打印。 FINDSTR然后折返到源2号线和遍布重新开始搜索 - 排序是向前看类型的功能

Searching across line breaks
As expected, the . regex metacharacter will not match <CR> or <LF>. But it is possible to search across a line break using a command line search string. Both the <CR> and <LF> characters must be matched explicitly. If a multi-line match is found, only the 1st line of the match is printed. FINDSTR then doubles back to the 2nd line in the source and begins the search all over again - sort of a "look ahead" type feature.

假设TEXT.TXT具有以下内容（可以是UNIX或Windows风格）

Assume TEXT.TXT has these contents (could be Unix or Windows style)

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

给出了这些结果。

gives these results

1:A
2:A
5:A

跨线搜索使用/ G游：FILE选项是IM precise，因为只有这样，才能匹配＆LT; CR>或LT; LF>是通过正则表达式字符类范围的前pression的三明治EOL字符。

Searching across line breaks using the /G:FILE option is imprecise because the only way to match <CR> or <LF> is via a regex character class range expression that sandwiches the EOL characters.

• [＆LT;标签＆gt; - ＆LT; 0x0B中＆GT;] 匹配＆LT; LF>，但它也LT匹配＆; TAB>和＆lt; 0x0B中>

• [<TAB>-<0x0B>] matches <LF>, but it also matches <TAB> and <0x0B>

[＆LT;的0x0C＆GT; - ！]！匹配＆LT; CR>，但它也符合＆LT;的0x0C>和

[<0x0C>-!] matches <CR>, but it also matches <0x0C> and !

的注 - 上面是正则表达式的字节流的象征重新presentations因为我不能再图形present字符的

有限的经常防爆pressions（正则表达式）支持

定期EX pressions FINDSTR的支持是极其有限的。如果不是在帮助文档中，它不支持。

Limited Regular Expressions (regex) Support
FINDSTR support for regular expressions is extremely limited. If it is not in the HELP documentation, it is not supported.

除此之外，能够支持在一个完全非标准的方式实施的正则表达式前pressions，这样的结果可能不同，那么将有望从类似的grep或Perl来了。

Beyond that, the regex expressions that are supported are implemented in a completely non-standard manner, such that results can be different then would be expected coming from something like grep or perl.

正则表达式线位置锚^和$

^ 比赛开始输入流以及任何位置，紧跟在＆LT; LF>。由于FINDSTR也打破后线与LT; LF>，一个简单的正则表达式^会一直匹配所有行的文件中，即使是一个二进制文件

Regex Line Position anchors ^ and $
^ matches beginning of input stream as well as any position immediately following a <LF>. Since FINDSTR also breaks lines after <LF>, a simple regex of "^" will always match all lines within a file, even a binary file.

$ 匹配的任何位置立即preceding A＆LT; CR>。这意味着包含一个正则表达式搜索字符串 $ 永远不会匹配一个Unix风格的文本文件中的任何行，也不会对如果它缺少一个Windows的文本文件的最后一行匹配的＆LT的EOL标记; CR>＆LT; LF>

$ matches any position immediately preceding a <CR>. This means that a regex search string containing $ will never match any lines within a Unix style text file, nor will it match the last line of a Windows text file if it is missing the EOL marker of <CR><LF>.

的注 - previously讨论，管道重定向输入FINDSTR可能有＆LT; CR＆GT;＆LT; LF＆GT; 追加不在的资源。显然，这会影响使用正则表达式搜索 $ 。的

Note - As previously discussed, piped and redirected input to FINDSTR may have <CR><LF> appended that is not in the source. Obviously this can impact a regex search that uses $.

与字符的任意搜索字符串之前 ^ 或之后 $ 将永远无法找到一个匹配。

Any search string with characters before ^ or after $ will always fail to find a match.

阵地选项/ B / E / X

位置选择的工作方式相同 ^ 和 $ ，除非他们也工作了文字搜索字符串。

Positional Options /B /E /X
The positional options work the same as ^ and $, except they also work for literal search strings.

/ B功能相同的 ^ 在正则表达式搜索字符串的开始。

/B functions the same as ^ at the start of a regex search string.

/ E功能在正则表达式搜索字符串的结尾一样 $ 。

/E functions the same as $ at the end of a regex search string.

/ X功能一样在正则表达式搜索结束兼具 ^ 开头和 $ 字符串。

/X functions the same as having both ^ at the beginning and $ at the end of a regex search string.

正则表达式字边界

\\＆LT; 必须在正则表达式的第一项。如果任何其他字符precede它的正则表达式不会匹配任何东西。 \\＆LT; 对应要么输入的开​​始，一行的开头（位置紧跟在＆LT; LF>），或紧随位置的任何非字的字符。下一个字符不一定是一个字字。

Regex word boundary
\< must be the very first term in the regex. The regex will not match anything if any other characters precede it. \< corresponds to either the very beginning of the input, the beginning of a line (the position immediately following a <LF>), or the position immediately following any "non-word" character. The next character need not be a "word" character.

\\＆GT; 必须在正则表达式的最后期限。如果任何其他字符其后的正则表达式不会匹配任何东西。 \\＆GT; 对应于输入的，位置前立即与＆lt任一端; CR>或立即preceding任何非字字符的位置。在preceding性格不一定是字的字符。

\> must be the very last term in the regex. The regex will not match anything if any other characters follow it. \> corresponds to either the end of input, the position immediately prior to a <CR>, or the position immediately preceding any "non-word" character. The preceding character need not be a "word" character.

下面是无字字，再presented作为小数字节code的完整列表。 注 - 这个名单是编制了中美机器上。我不知道其他语言可能有这个名单上有什么影响。的

Here is a complete list of "non-word" characters, represented as the decimal byte code. Note - this list was compiled on a U.S machine. I do not know what impact other languages may have on this list.

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]

如预期字符类范围不工作。看到这个问题：<一href=\"http://stackoverflow.com/questions/2635740/why-does-findstr-not-handle-case-properly-in-some-circumstances\">Why不FINDSTR不能正确处理的情况下（在某些情况下），这个答案一起：<？一href=\"http://stackoverflow.com/a/8767815/1012053\">http://stackoverflow.com/a/8767815/1012053.

问题是FINDSTR不其字节code值整理字符（通常认为是ASCII code，但ASCII仅从定义为0x00 - 0x7F的）。大多数regex实现将治疗[A-Z]所有大写英文大写字母。但是FINDSTR使用大致对应排序是如何工作的排列顺序。所以，[A-Z]包括完整的英文字母，大写和小写字母（除A），以及非英文字母字符与发音符号。

The problem is FINDSTR does not collate the characters by their byte code value (commonly thought of as the ASCII code, but ASCII is only defined from 0x00 - 0x7F). Most regex implementations would treat [A-Z] as all upper case English capital letters. But FINDSTR uses a collation sequence that roughly corresponds to how SORT works. So [A-Z] includes the complete English alphabet, both upper and lower case (except for "a"), as well as non-English alpha characters with diacriticals.

下面是FINDSTR支持的所有字符，在使用FINDSTR建立正则表达式字符类范围内的排序顺序排列的完整列表。这些字符重新psented为十进制字节code值$ P $。我相信，如果字符使用code页437查看的排列顺序是很有道理的注 - 这个名单是一个中美机器上编译。我不知道其他语言可能有这个名单上有什么影响。的

Below is a complete list of all characters supported by FINDSTR, sorted in the collation sequence used by FINDSTR to establish regex character class ranges. The characters are represented as their decimal byte code value. I believe the collation sequence makes the most sense if the characters are viewed using code page 437. Note - this list was compiled on a U.S machine. I do not know what impact other languages may have on this list.

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

Answer continued below...

这篇关于什么是Windows FINDSTR命令的无证功能和限制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！