Введение
Большая часть информации в этом ответе была собрана на основе экспериментов, проведенных на компьютере с Vista. Если прямо не указано иное, я не подтвердил, применима ли эта информация к другим версиям Windows.
Вывод FINDSTR
Документация никогда не объясняет вывод FINDSTR. Это намекает на то, что печатаются совпадающие строки, но не более того.
Формат вывода совпадающей строки следующий:
Имя файла: LINENUMBER: lineOffset: Текст
, где
fileName: = Имя файла, содержащего совпадающую строку. Имя файла не печатается, если запрос был явно для одного файла, или при поиске вводимых по трубопроводу или перенаправленных входных данных. При печати fileName всегда будет содержать любую предоставленную информацию о пути. Дополнительная информация о пути будет добавлена, если используется опция /S. Печатный путь всегда указывается относительно предоставленного пути или относительно текущего каталога, если он не указан.
Примечание. Префикса имени файла можно избежать при поиске в нескольких файлах с помощью нестандартных (и плохо документированных) подстановочных знаков < и >. Точные правила работы этих подстановочных знаков можно найти здесь . Наконец, вы можете посмотреть на этот пример того, как нестандартные символы подстановки работают с FINDSTR .
lineNumber: = Номер строки совпадающей строки, представленной в виде десятичного значения, где 1 представляет 1-ю строку ввода. Распечатывается, только если указан параметр /N.
lineOffset: = Десятичное байтовое смещение начала совпадающей строки, где 0 представляет 1-й символ 1-й строки. Печатается только если указана опция /O. Это , а не смещение совпадения в строке. Это число байтов от начала файла до начала строки.
text = Двоичное представление совпадающей строки, включая любые & LT; CR> и / или & LT; LF>. Ничего не осталось из двоичного вывода, так что этот пример, который соответствует всем строкам, даст точную двоичную копию исходного файла.
FINDSTR "^" FILE >FILE_COPY
Большинство управляющих символов и множество расширенных символов ASCII отображаются в XP в виде точек
FINDSTR на XP отображает большинство непечатаемых управляющих символов из соответствующих строк в виде точек (точек) на экране. Следующие управляющие символы являются исключениями; они отображаются как сами: вкладка 0x09, перевод строки 0x0A, вертикальная вкладка 0x0B, подача формы 0x0C, возврат каретки 0x0D.
XP FINDSTR также преобразует количество расширенных символов ASCII в точки. Символы расширенного ASCII, которые отображаются в XP как точки, такие же, как те, которые преобразуются при вводе в командной строке. См. «Ограничения символов для параметров командной строки - Расширенное преобразование ASCII» , далее в этом посте
Управляющие символы и расширенный ASCII не преобразуются в точки в XP, если выходные данные передаются по конвейеру, перенаправляются в файл или в предложении FOR IN ().
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.
STDIN через перенаправление findstr "searchString" <file
поток данных из канала type file | findstr "searchString"
Аргументы / опции имеют приоритет над перенаправлением, которое имеет приоритет надданные по конвейеру.
Аргументы имени файла и /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 при поиске файлов для поиска.Предположим, что текущая папка содержит следующие непустые файлы:
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.Дополнительные файлы, которые сортируются позже, такие как 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 будет зависать бесконечно, как только достигнет конца перенаправленного файла.
Последняя строка данных Piped может игнорироваться, если она состоит из одного символа
Если ввод передается по каналу и последняя строка состоит из одного символа, за которым не следует <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 для тестирования).
Дополнительный синтаксис
Опции могут иметь префикс / или -
Опции могут быть объединены после одного / или -. Однако объединенный список параметров может содержать не более одного параметра с несколькими символами, например OFF или F:, а параметр из нескольких символов должен быть последним параметром в списке.
Ниже приведены все эквивалентные способы выражения нечувствительного к регистру регулярного выражения для поиска любой строки, содержащей в любом порядке слова "привет" и "до свидания".
/i /r /c:"hello.*goodbye" /c:"goodbye.*hello"
-i -r -c:"hello.*goodbye" /c:"goodbye.*hello"
/irc:"hello.*goodbye" /c:"goodbye.*hello"
Ограничения длины строки поиска
В Vista максимально допустимая длина одной строки поиска составляет 511 байт. Если какая-либо строка поиска превышает 511, результатом будет ошибка FINDSTR: Search string too long. с ошибкой 2.
При выполнении поиска по регулярному выражению максимальная длина строки поиска составляет 254. Регулярное выражение с длиной от 255 до 511 приведет к ошибке FINDSTR: Out of memory с ошибкой 2. Длина регулярного выражения> 511 приведет к FINDSTR: Search string too long. ошибка.
В Windows XP длина строки поиска явно меньше. Ошибка Findstr: "Слишком длинная строка поиска": как извлечь и сопоставить подстроку в цикле "for"?
Ограничение XP составляет 127 байтов для литерального и регулярного поиска.
Пределы длины линии
Файлы, указанные в качестве аргумента командной строки или с помощью параметра / F: FILE, не имеют известного ограничения длины строки. Поиск был успешно выполнен для файла размером 128 МБ, который не содержал ни одного .
Данные по каналам и перенаправленный ввод ограничены 8191 байтами на строку. Этот лимит является «особенностью» FINDSTR. Это не присуще трубам или перенаправлению. FINDSTR, использующий перенаправленный ввод stdin или piped, никогда не будет соответствовать ни одной строке размером> = 8 Кбайт. Строки> = 8k генерируют сообщение об ошибке для stderr, но значение ERRORLEVEL равно 0, если строка поиска найдена хотя бы в одной строке хотя бы одного файла.
Тип поиска по умолчанию: буквальное или регулярное выражение
/C:"string" - По умолчанию используется значение / L.Явное объединение параметра / L с / C: «строка», безусловно, работает, но является избыточным.
"string argument" - значение по умолчанию зависит от содержимого самой первой строки поиска. (Помните, что используется для разделения строк поиска.) Если первая строка поиска является допустимым регулярным выражением, которое содержит хотя бы один неэкранированный метасимвол, то все строки поиска обрабатываются как регулярныевыражения.В противном случае все строки поиска рассматриваются как литералы.Например, "51.4 200" будет обрабатываться как два регулярных выражения, поскольку первая строка содержит неэкранированную точку, тогда как "200 51.4" будет обрабатываться как два литерала, поскольку первая строка не содержит метасимволов.
/G:file - значение по умолчанию зависит от содержимого первой непустой строки в файле.Если первая строка поиска является допустимым регулярным выражением, которое содержит хотя бы один неэкранированный метасимвол, все строки поиска обрабатываются как регулярные выражения.В противном случае все строки поиска обрабатываются как литералы.
Рекомендация - всегда явно указывайте /L литерал или /R параметр регулярного выражения при использовании "string argument" или /G:file.
BUG - Задание нескольких строк литерального поиска может дать ненадежные результаты
В следующем простом примере FINDSTR не удается найти совпадение, хотя оно и должно быть.
echo ffffaaa|findstr /l "ffffaaa faffaffddd"
Эта ошибка была подтверждена в Windows Server 2003, Windows XP, Vista и Windows 7.
Основываясь на экспериментах, FINDSTR может завершиться ошибкой, если выполнены все следующие условия:
- При поиске используется несколько литеральных строк поиска
- Строки поиска имеютразной длины
- Короткая строка поиска имеет некоторое перекрытие с более длинной строкой поиска
- Поиск выполняется с учетом регистра (без опции
/I)
Inпри каждом сбое, которое я видел, всегда происходит сбой одной из более коротких строк поиска.
Для получения дополнительной информации см. Почему этот пример FINDSTR с несколькими строковыми поисковыми строками не находит соответствия?
Кавычки и обратные слэши в аргументах командной строки
Примечание - Пользовательский MCКомментарии Н.Д. отражают реальный ужасСложные правила для этого раздела.Существует три этапа анализа:
- Первый cmd.exe может потребовать экранирования некоторых кавычек как ^ "(на самом деле ничего общего с FINDSTR)
- Далее FINDSTR использует до 2008 MS C / C ++ парсера аргументов , который имеет специальные правила для "и \
- после парсера аргументаВ конце FINDSTR дополнительно обрабатывает \, за которым следует буквенно-цифровой символ как литеральный, но \ сопровождается не буквенно-цифровым символом как escape-символ
Остальная часть этого выделенногораздел не на 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: файл не нужно экранировать, но они могут быть.
" и \" эквивалентны.
\ и \\ эквивалентны.
Если цель состоит в том, чтобы найти \\, то, по крайней мере, должен быть экранирован начальный обратный слеш.И \\\, и \\\\ работают.
Если цель состоит в том, чтобы найти \ ", то, по крайней мере, должен быть экранирован начальный обратный слеш. И \\", и \\\" работают.
Выход из кавычек и обратной косой черты в / G: FILE-строки поиска регулярных выражений Это единственный случай, когда escape-последовательности работают, как и ожидалось, основываясь на документации.Цитата не является метасимволом регулярных выражений, поэтому ее не нужно экранировать (но можно).Обратная косая черта является метасимволом регулярных выражений, поэтому ее необходимо экранировать.
Ограничения символов для параметров командной строки - Расширенное преобразование ASCII Нулевой символ (0x00) не может появляться ни в одной строке командной строки.Любой другой однобайтовый символ может появиться в строке (0x01 - 0xFF).Однако FINDSTR преобразует многие расширенные символы ASCII, которые он находит в параметрах командной строки, в другие символы.Это оказывает существенное влияние двумя способами:
1) Многие расширенные символы ASCII не будут совпадать, если используются в качестве строки поиска в командной строке.Это ограничение одинаково для литеральных и регулярных поисков.Если строка поиска должна содержать расширенный ASCII, вместо этого следует использовать параметр /G:FILE.
2) FINDSTR может не найти файл, если имя содержит расширенные символы ASCII и имя файла указано вкомандная строка.Если файл для поиска содержит расширенный ASCII в имени, тогда вместо него следует использовать параметр /F:FILE.
Вот полный список расширенных преобразований символов ASCII, которые FINDSTR выполняет в строках командной строки.Каждый символ представлен в виде десятичного значения байтового кода.Первый код представляет символ, указанный в командной строке, а второй код представляет символ, в который он преобразован. Примечание. Этот список был составлен на машине из США.Я не знаю, какое влияние на этот список могут оказать другие языки.
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> и <<code>LF>.Самый простой способ включить нечетные символы, такие как <CR> и <LF>, - получить их в переменную окружения и использовать отложенное расширение в аргументе командной строки.
Ограничения на символы для строк, найденных в указанных файлах/ G: ФАЙЛ и / F: ФАЙЛ Символ nul (0x00) может появиться в файле, но он действует как терминатор строки C.Любые символы после нулевого символа обрабатываются как другая строка, как если бы они были в другой строке.
Символы <CR> и <LF> обрабатываются как ограничители строки, которые заканчивают строку, и не включаются встрока.
Все остальные однобайтовые символы полностью включены в строку.
Поиск файлов Unicode FINDSTR не может правильно искать большинство Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32), потому что он не может искать нулевые байты, а Unicode обычно содержит много нулевых байтов.
Однако команда TYPE преобразует UTF-16LE с BOM в однобайтовый набор символов, поэтому такая команда будет работать с UTF-16LE с BOM.
type unicode.txt|findstr "search"
Обратите внимание, что кодовые точки Unicode, которые не поддерживаются вашей активной кодовой страницей, будут преобразованы в ? символов.
Можно выполнять поиск по UTF-8, пока ваша строка поискасодержит только ASCII.Однако вывод на консоль любых многобайтовых символов UTF-8 будет неправильным.Но если вы перенаправите вывод в файл, то результат будет правильно закодирован UTF-8.Обратите внимание, что если файл UTF-8 содержит спецификацию, то эта спецификация будет считаться частью первой строки, что может привести к сбою в поиске, соответствующем началу строки.
Можно искать многобайтовые символы UTF-8, если поместить строку поиска в файл поиска в кодировке UTF-8 (без спецификации) и использовать параметр / G.
Конец строки FINDSTR прерывает строки сразу после каждого .Наличие или отсутствие не влияет на разрывы строк.
Поиск по разрывам строк Как и ожидалось, метасимвол . regex не будет совпадать с или .Но можно искать через разрыв строки, используя строку поиска командной строки.Символы и должны совпадать явно.Если найдено многострочное совпадение, печатается только 1-я строка совпадения.Затем FINDSTR удваивается до 2-й строки в источнике и снова начинает поиск - что-то вроде функции «просмотра вперед».
Предположим, что 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 является неточным, поскольку единственный способ или соответствует выражению диапазона класса регулярных выражений, которое помещает символы EOL.
[<TAB>-<0x0B>] соответствует , но также соответствует и <0x0B>
[<0x0C>-!] соответствует , но также соответствует <0x0C> и!
Примечание. Выше приведены символические представленияпоток байтов регулярных выражений, поскольку я не могу графически представить символы.
Ответ продолжен в части 2 ниже ...