Przedmowa
Wiele informacji zawartych w tej odpowiedzi zostało zebranych na podstawie eksperymentów przeprowadzonych na komputerze z systemem Vista. O ile wyraźnie nie zaznaczono inaczej, nie potwierdziłem, czy informacje dotyczą innych wersji systemu Windows.
Dane wyjściowe FINDSTR
Dokumentacja nigdy nie zadaje sobie trudu, aby wyjaśnić dane wyjściowe FINDSTR. Wskazuje to na to, że drukowane są pasujące linie, ale nic więcej.
Format dopasowanego wyjścia liniowego jest następujący:
filename: lineNumber: lineOffset: text
gdzie
fileName: = nazwa pliku zawierającego pasującą linię. Nazwa pliku nie jest drukowana, jeśli żądanie dotyczyło jednoznacznie pojedynczego pliku lub podczas wyszukiwania danych wejściowych w trybie potokowym lub danych przekierowanych. Po wydrukowaniu nazwa pliku zawsze będzie zawierać wszelkie podane informacje o ścieżce. Dodatkowe informacje o ścieżce zostaną dodane, jeśli/Szostanie użyta opcja. Ścieżka drukowana jest zawsze względna do podanej ścieżki lub względna do bieżącego katalogu, jeśli nie została podana.
Uwaga - Podczas wyszukiwania wielu plików można uniknąć prefiksu nazwy pliku, używając niestandardowych (i słabo udokumentowanych) symboli wieloznacznych < i >. Dokładne zasady działania tych symboli wieloznacznych można znaleźć tutaj . Na koniec możesz spojrzeć na ten przykład, w jaki sposób niestandardowe symbole wieloznaczne działają z FINDSTR .
lineNumber: = Numer linii pasującego wiersza reprezentowany jako wartość dziesiętna, gdzie 1 oznacza pierwszy wiersz danych wejściowych. Drukowane tylko, jeśli/Npodano opcję.
lineOffset: = Przesunięcie dziesiętnego bajtu na początku pasującej linii, przy czym 0 oznacza 1. znak 1. linii. Drukowane tylko, jeśli/Opodano opcję. To nie jestprzesunięcie dopasowania w linii. Jest to liczba bajtów od początku pliku do początku linii.
text = Binarna reprezentacja pasującej linii, łącznie z dowolnymi <CR> i / lub <LF>. Nic nie pozostaje poza wyjściem binarnym, tak że ten przykład, który pasuje do wszystkich wierszy, utworzy dokładną kopię binarną oryginalnego pliku.
FINDSTR "^" FILE >FILE_COPY
Opcja / A ustawia kolor fileName :, lineNumber :, i lineOffset: tylko dane wyjściowe. Tekst pasującej linii jest zawsze wyprowadzany z bieżącym kolorem konsoli. Opcja / A działa tylko wtedy, gdy dane wyjściowe są wyświetlane bezpośrednio na konsoli. Opcja / A nie ma wpływu, jeśli dane wyjściowe zostaną przekierowane do pliku lub potoku. Zobacz edycję 2018-08-18 w odpowiedzi Aacini, aby uzyskać opis błędnego zachowania po przekierowaniu danych wyjściowych do CON.
Większość znaków kontrolnych i wiele rozszerzonych znaków ASCII jest wyświetlanych jako kropki na XP.
FINDSTR na XP wyświetla większość niedrukowalnych znaków kontrolnych z pasujących linii jako kropki (kropki) na ekranie. Następujące znaki kontrolne są wyjątkami; wyświetlają się one same: 0x09 Tab, 0x0A LineFeed, 0x0B Tab pionowy, 0x0C Form Feed, 0x0D Powóz powrotny.
XP FINDSTR przekształca również wiele rozszerzonych znaków ASCII w kropki. Rozszerzone znaki ASCII wyświetlane w XP jako kropki są takie same, jak znaki przekształcane po dostarczeniu z wiersza poleceń. Zobacz sekcję „Limity znaków dla parametrów wiersza poleceń - Rozszerzona transformacja ASCII” , w dalszej części tego postu
Znaki kontrolne i rozszerzone ASCII nie są konwertowane na kropki w XP, jeśli dane wyjściowe są przesyłane potokowo, przekierowywane do pliku lub w ramach klauzuli FOR IN ().
Vista i Windows 7 zawsze wyświetlają wszystkie znaki jako siebie, nigdy jako kropki.
Kody zwrotne (ERRORLEVEL)
- 0 (sukces)
- Znaleziono dopasowanie w co najmniej jednej linii co najmniej jednego pliku.
- 1 (awaria)
- Nie znaleziono dopasowania w żadnym wierszu żadnego pliku.
- Nieprawidłowy kolor określony przez
/A:xxopcję
- 2 (błąd)
- Niezgodne opcje
/Li /Roba określone
- Brakuje argumentu po
/A:, /F:, /C:, /D:, lub/G:
- Plik określony przez
/F:filelub /G:filenie został znaleziony
- 255 (błąd)
Źródło danych do wyszukiwania (zaktualizowane na podstawie testów w systemie Windows 7)
Findstr może wyszukiwać dane tylko z jednego z następujących źródeł:
nazwy plików określone jako argumenty i / lub za pomocą /F:fileopcji.
standardowe poprzez przekierowanie findstr "searchString" <file
strumień danych z potoku type file | findstr "searchString"
Argumenty / opcje mają pierwszeństwo przed przekierowaniem, które ma pierwszeństwo przed przesyłanymi danymi.
Argumenty nazwy pliku i /F:filemożna je łączyć. Można użyć wielu argumentów nazwy pliku. Jeśli /F:filepodano wiele opcji, używana jest tylko ostatnia. Symbole wieloznaczne są dozwolone w argumentach nazw plików, ale nie w obrębie pliku wskazywanego przez /F:file.
Źródło ciągów wyszukiwania (zaktualizowane na podstawie testów z Windows 7) i opcje mogą być łączone. Można podać wiele opcji. Jeśli podano wiele opcji, używana jest tylko ostatnia. Jeśli użyty jest albo lub, zakłada się, że wszystkie argumenty nie będące opcjami są plikami do przeszukania. Jeśli ani nie zostanie użyty, ani pierwszy argument nie będący opcją jest traktowany jako lista rozdzielonych spacjami haseł.
/G:file/C:string/C:string/G:file/G:file/C:string/G:file/C:string
Podczas korzystania z /F:FILEopcji nazwy plików nie mogą być cytowane w pliku .
Nazwy plików mogą zawierać spacje i inne znaki specjalne. Większość poleceń wymaga cytowania takich nazw plików. Ale /F:files.txtopcja FINDSTR wymaga, aby nazwy plików w plikach.txt NIE były cytowane. Plik nie zostanie znaleziony, jeśli nazwa zostanie podana.
BŁĄD - Krótkie nazwy plików 8.3 mogą/D/S
uszkodzić opcje i Podobnie jak w przypadku wszystkich poleceń systemu Windows, FINDSTR będzie próbował dopasować zarówno długą nazwę, jak i krótką nazwę 8.3, podczas wyszukiwania plików do przeszukania. Załóżmy, że bieżący folder zawiera następujące niepuste pliki:
b1.txt
b.txt2
c.txt
Następujące polecenie z powodzeniem znajdzie wszystkie 3 pliki:
findstr /m "^" *.txt
b.txt2pasuje, ponieważ odpowiada odpowiednia krótka nazwa B9F64~1.TXT. Jest to zgodne z zachowaniem wszystkich innych poleceń systemu Windows.
Ale błąd w opcjach /Di /Spowoduje, że następujące polecenia znajdują się tylkob1.txt
findstr /m /d:. "^" *.txt
findstr /m /s "^" *.txt
Błąd uniemożliwia b.txt2odnalezienie, a także wszystkich nazw plików posortowanych po b.txt2tym samym katalogu. a.txtZnaleziono dodatkowe pliki, które sortują się wcześniej . Dodatkowe pliki, które sortują później, na przykład d.txt, są pomijane po uruchomieniu błędu.
Każdy przeszukiwany katalog jest traktowany niezależnie. Na przykład /Sopcja z powodzeniem rozpocznie wyszukiwanie w folderze podrzędnym po nieudanym znalezieniu plików w elemencie nadrzędnym, ale gdy błąd spowoduje pominięcie krótkiej nazwy pliku w elemencie podrzędnym, wówczas wszystkie kolejne pliki w tym folderze podrzędnym również zostaną pominięte .
Polecenia działają bezbłędnie, jeśli te same nazwy plików są tworzone na komputerze z wyłączonym generowaniem nazw NTFS 8.3. Oczywiście b.txt2nie zostałby znaleziony, ale c.txtzostałby znaleziony poprawnie.
Nie wszystkie krótkie nazwy powodują błąd. Wszystkie zaobserwowane przeze mnie przypadki błędnego zachowania dotyczą rozszerzenia dłuższego niż 3 znaki o krótkiej nazwie 8.3, która zaczyna się tak samo jak normalna nazwa, która nie wymaga nazwy 8.3.
Błąd został potwierdzony w systemach XP, Vista i Windows 7.
Znaków Niedrukowalny oraz /Popcja opcja powoduje FINDSTR pominąć dowolny plik, który zawiera jeden z następujących kodów bajtowych dziesiętnych:
0-7, 14-25, 27-31.
/P
Innymi słowy, /Popcja pomija tylko pliki zawierające niedrukowalne znaki kontrolne. Znaki kontrolne to kody mniejsze lub równe 31 (0x1F). FINDSTR traktuje następujące znaki kontrolne jako drukowalne:
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)
Wszystkie pozostałe znaki sterujące są traktowane jako niedrukowalne, których obecność powoduje, że /Popcja pomija plik.
Dołączone dane wejściowe potokowe i przekierowane mogły zostać <CR><LF>dołączone.
Jeśli dane wejściowe są przesyłane strumieniowo <LF>, a ostatni znak strumienia nie jest , funkcja FINDSTR automatycznie dołącza <CR><LF>się do danych wejściowych. Zostało to potwierdzone w systemach XP, Vista i Windows 7. (Kiedyś myślałem, że potok Windows był odpowiedzialny za modyfikację danych wejściowych, ale od tego czasu odkryłem, że FINDSTR faktycznie dokonuje modyfikacji).
To samo dotyczy przekierowanych danych wejściowych w systemie Vista. Jeśli ostatnim znakiem pliku używanego jako przekierowane dane wejściowe nie jest <LF>, wówczas FINDSTR automatycznie dołącza <CR><LF>się do danych wejściowych. Jednak XP i Windows 7 nie zmieniają przekierowanych danych wejściowych.
Findstr wisi na XP i Windows 7, jeśli przekierowany wejście nie kończy<LF>
To jest paskudne „cecha” na XP i Windows 7. Jeśli ostatni znak pliku używany jako wejście przekierowanego nie kończy się <LF>, a następnie FINDSTR zawiśnie w nieskończoność po nim osiąga koniec przekierowanego pliku.
Ostatni wiersz danych przesyłanych strumieniowo można zignorować, jeśli składa się z pojedynczego znaku.
Jeśli wejście jest przesyłane <LF>strumieniowo, a ostatni wiersz składa się z pojedynczego znaku, po którym nie następuje , funkcja FINDSTR całkowicie ignoruje ostatni wiersz.
Przykład - Pierwsze polecenie z pojedynczym znakiem i bez niego <LF>nie pasuje, ale drugie polecenie z 2 znakami działa dobrze, podobnie jak trzecie polecenie, które ma jeden znak z zakończeniem nowej linii.
> set /p "=x" <nul | findstr "^"
> set /p "=xx" <nul | findstr "^"
xx
> echo x| findstr "^"
x
Zgłoszony przez użytkownika DosTips Sponge Belly przy nowym błędzie findstr . Potwierdzono w XP, Windows 7 i Windows 8. Nie słyszałem jeszcze o Vistie. (Nie mam już Visty do przetestowania).
Składnia opcji
Opcje mogą być poprzedzone jednym z nich /lub -
Opcje mogą być łączone po jednym /lub -. Jednak połączona lista opcji może zawierać co najwyżej jedną opcję wieloznakową, taką jak WYŁ. Lub F :, a opcja wieloznakowa musi być ostatnią opcją na liście.
Poniżej podano wszystkie równoważne sposoby wyrażenia wyrażenia regularnego bez rozróżniania wielkości liter dla dowolnego wiersza zawierającego zarówno „cześć”, jak i „do widzenia” w dowolnej kolejności
/i /r /c:"hello.*goodbye" /c:"goodbye.*hello"
-i -r -c:"hello.*goodbye" /c:"goodbye.*hello"
/irc:"hello.*goodbye" /c:"goodbye.*hello"
Limity długości ciągu wyszukiwania
W systemie Vista maksymalna dozwolona długość pojedynczego ciągu wyszukiwania wynosi 511 bajtów. Jeśli dowolny szukany ciąg przekracza 511, wynikiem jest FINDSTR: Search string too long.błąd z ERRORLEVEL 2.
Podczas wyszukiwania wyrażeń regularnych maksymalna długość szukanego ciągu wynosi 254. Wyrażenie regularne o długości od 255 do 511 spowoduje FINDSTR: Out of memorybłąd z ERRORLEVEL 2. Błąd wyrażenia regularnego> 511 spowoduje FINDSTR: Search string too long.błąd.
W systemie Windows XP długość ciągu wyszukiwania jest najwyraźniej krótsza. Błąd Findstr: „Ciąg wyszukiwania zbyt długi”: Jak wyodrębnić i dopasować podciąg w pętli „for”?
Limit XP wynosi 127 bajtów dla wyszukiwania dosłownego i wyrażenia regularnego.
Limity długości linii
Pliki określone jako argument wiersza poleceń lub za pomocą opcji / F: FILE nie mają znanego limitu długości linii. Pomyślnie uruchomiono wyszukiwanie dla pliku 128 MB, który nie zawierał ani jednego <LF>.
Dane przesyłane potokowo i przekierowane dane wejściowe są ograniczone do 8191 bajtów na linię. Ten limit jest „funkcją” FINDSTR. Nie jest związany z potokami ani przekierowaniami. FINDSTR przy użyciu przekierowanego wejścia stdin lub potokowego nigdy nie będzie pasował do żadnej linii, która ma> 8k bajtów. Linie> = 8k generują komunikat o błędzie do stderr, ale ERRORLEVEL wciąż wynosi 0, jeśli szukany ciąg znajduje się w co najmniej jednym wierszu co najmniej jednego pliku.
Domyślny typ wyszukiwania:
/C:"string" dosłowny vs. wyrażenie regularne - domyślnie jest to literał / L. Jawne połączenie opcji / L z / C: „string” z pewnością działa, ale jest redundantne.
"string argument"- Wartość domyślna zależy od zawartości pierwszego szukanego ciągu. (Pamiętaj, że <spacja> jest używana do rozdzielenia ciągów wyszukiwania.) Jeśli pierwszy ciąg wyszukiwania jest prawidłowym wyrażeniem regularnym zawierającym co najmniej jeden nieoznakowany metaznak, wówczas wszystkie ciągi wyszukiwania są traktowane jako wyrażenia regularne. W przeciwnym razie wszystkie ciągi wyszukiwania są traktowane jak literały. Na przykład "51.4 200"będą traktowane jako dwa wyrażenia regularne, ponieważ pierwszy ciąg zawiera kropkę bez znaku ucieczki, podczas gdy "200 51.4"będzie traktowany jako dwa literały, ponieważ pierwszy ciąg nie zawiera żadnych metaznaków.
/G:file- Wartość domyślna zależy od zawartości pierwszego niepustego wiersza w pliku. Jeśli pierwszy ciąg wyszukiwania jest prawidłowym wyrażeniem regularnym zawierającym co najmniej jeden nieoznakowany metaznak, wówczas wszystkie ciągi wyszukiwania są traktowane jako wyrażenia regularne. W przeciwnym razie wszystkie ciągi wyszukiwania są traktowane jak literały.
Zalecenie - Zawsze używaj /Lopcji dosłownie lub /Ropcji wyrażenia regularnego, gdy używasz "string argument"lub /G:file.
BŁĄD - Podanie wielu dosłownych ciągów wyszukiwania może dać nierzetelne wyniki
Poniższy prosty przykład FINDSTR nie może znaleźć dopasowania, chociaż powinno.
echo ffffaaa|findstr /l "ffffaaa faffaffddd"
Ten błąd został potwierdzony w systemach Windows Server 2003, Windows XP, Vista i Windows 7.
Na podstawie eksperymentów FINDSTR może się nie powieść, jeśli zostaną spełnione wszystkie następujące warunki:
- Wyszukiwanie wykorzystuje wiele literalnych ciągów wyszukiwania
- Ciągi wyszukiwania mają różne długości
- Krótki ciąg wyszukiwania ma pewne nakładanie się z dłuższym ciągiem wyszukiwania
- W wyszukiwaniu rozróżniana jest wielkość liter (brak
/Iopcji)
W każdej porażce, którą widziałem, zawsze zawodzi jeden z krótszych ciągów wyszukiwania.
Aby uzyskać więcej informacji, zobacz Dlaczego ten przykład FINDSTR z wieloma dosłownymi ciągami wyszukiwania nie znajduje dopasowania?
Cudzysłowy i odstępy w argumentach wiersza poleceń
Uwaga - Komentarze użytkownika MC ND odzwierciedlają naprawdę przerażająco skomplikowane reguły dla tej sekcji. W grę wchodzą 3 odrębne fazy analizy:
- Pierwszy cmd.exe może wymagać zmiany cudzysłowów na ^ ”(naprawdę nie ma to nic wspólnego z FINDSTR)
- Następnie FINDSTR używa analizatora składni argumentów MS C / C ++ sprzed 2008 roku , który ma specjalne reguły dla „i \
- Po zakończeniu parsera argumentów FINDSTR dodatkowo traktuje \, po którym następuje znak alfanumeryczny, jako dosłowny, ale \ po którym następuje znak inny niż alfanumeryczny, jako znak zmiany znaczenia
Pozostała część tej podświetlonej sekcji nie jest w 100% poprawna. Może służyć jako przewodnik w wielu sytuacjach, ale powyższe zasady są wymagane do pełnego zrozumienia.
Escaping Cytat w ciągach wyszukiwania wiersza poleceń
Cytaty w ciągach wyszukiwania wiersza poleceń muszą być poprzedzane odwrotnym ukośnikiem
\". Dotyczy to zarówno literalnych, jak i wyrażeń regularnych. Informacje te zostały potwierdzone w systemach XP, Vista i Windows 7.
Uwaga: cytat może również wymagać zmiany znaczenia dla analizatora składni CMD.EXE, ale nie ma to nic wspólnego z FINDSTR. Na przykład, aby wyszukać pojedynczy cytat, możesz użyć:
FINDSTR \^" file && echo found || echo not found
Cofanie ukośnika
odwrotnego w dosłownym ciągu wyszukiwania w wierszu poleceń Odwrotny ukośnik w dosłownym ciągu wyszukiwania można zwykle przedstawić jako
\lub jako \\. Zazwyczaj są one równoważne. (Mogą występować nietypowe przypadki w Vistie, w których odwrotny ukośnik zawsze musi być poprzedzony, ale nie mam już komputera z Vista do przetestowania) .
Ale są pewne szczególne przypadki:
Podczas wyszukiwania kolejnych ukośników odwrotnych wszystkie oprócz ostatniego muszą być poprzedzone znakiem ucieczki. Ostatniego ukośnika odwrotnego można opcjonalnie usunąć.
\\może być kodowany jako \\\lub\\\\\\\może być kodowany jako \\\\\lub\\\\\\
Wyszukiwanie jednego lub więcej ukośników odwrotnych przed wyceną jest dziwne. Logika sugerowałaby, że cytat musi zostać pominięty, a każdy z wiodących ukośników odwrotnych musiałby zostać usunięty, ale to nie działa! Zamiast tego każdy z wiodących odwrotnych ukośników musi być podwójnie zmieniony, a cytat jest normalnie zmieniany:
\" musi być zakodowany jako \\\\\"\\" musi być zakodowany jako \\\\\\\\\"
Jak wcześniej wspomniano, jeden lub więcej cytatów ze znakiem ucieczki może również wymagać zmiany znaczenia ^dla analizatora składni CMD
Informacje w tej sekcji zostały potwierdzone na XP i Windows 7.
Cofanie odwrotnego ukośnika w ciągach wyszukiwania wyrażeń regularnych w wierszu polecenia
Tylko Vista: ukośnik odwrotny w wyrażeniu regularnym musi być albo podwójnym klawiszem Esc \\\\, albo pojedynczym klawiszem Esc w zestawie klas znaków, takim jak
[\\]
XP i Windows 7: Ukośnik odwrotny w wyrażeniu regularnym zawsze można przedstawić jako [\\]. Zwykle może być reprezentowany jako \\. Ale to nigdy nie działa, jeśli odwrotny ukośnik poprzedza cytowany znak.
Jeden lub więcej odwrotnych ukośników przed cytowanym znakiem musi być albo podwójnym znakiem ucieczki, albo kodowany jako [\\]
\"mogą być kodowane jako \\\\\"lub[\\]\"\\"mogą być kodowane jako \\\\\\\\\"lub [\\][\\]\"lub\\[\\]\"
Cofanie
cudzysłowu i ukośnik odwrotny w / G: FILE dosłowne ciągi wyszukiwania Niezależne cytaty i odwrotne ukośniki w pliku dosłownego ciągu wyszukiwania określonego przez / G: plik nie muszą być poprzedzane, ale mogą być.
"i \"są równoważne.
\i \\są równoważne.
Jeśli celem jest znalezienie \\, to przynajmniej wiodący ukośnik odwrotny musi być poprzedzony znakiem ucieczki. Zarówno \\\i \\\\praca.
Jeśli intencją jest znalezienie \ ", to przynajmniej wiodący ukośnik odwrotny musi być poprzedzony. Oba \\"i \\\"działają.
Znak ucieczki cytatu i ukośnik odwrotny w ciągu / G: FILE ciągi wyszukiwania wyrażeń regularnych
Jest to jedyny przypadek, w którym sekwencje specjalne działają zgodnie z oczekiwaniami na podstawie dokumentacji. Cytat nie jest metaznakiem wyrażenia regularnego, więc nie trzeba go usuwać (ale może być). Ukośnik odwrotny jest metaznakiem wyrażenia regularnego, dlatego należy go usunąć.
Limity znaków dla parametrów wiersza poleceń - rozszerzona transformacja ASCII
Znak pusty (0x00) nie może pojawić się w żadnym ciągu w wierszu polecenia. W łańcuchu może pojawić się dowolny inny znak jednobajtowy (0x01 - 0xFF). Jednak FINDSTR konwertuje wiele rozszerzonych znaków ASCII, które znajdzie w parametrach wiersza poleceń, na inne znaki. Ma to duży wpływ na dwa sposoby:
1) Wiele rozszerzonych znaków ASCII nie będzie pasowało do siebie, jeśli zostanie użyty jako ciąg wyszukiwania w wierszu poleceń. To ograniczenie jest takie samo dla wyszukiwań literałowych i wyrażeń regularnych. Jeśli szukany ciąg musi zawierać rozszerzony ASCII, /G:FILEnależy zamiast tego użyć opcji
2) FINDSTR może nie znaleźć pliku, jeśli nazwa zawiera rozszerzone znaki ASCII, a nazwa pliku jest podana w wierszu poleceń. Jeśli plik do przeszukania zawiera rozszerzone ASCII w nazwie, /F:FILEnależy zamiast tego użyć opcji
Oto pełna lista rozszerzonych przekształceń znaków ASCII, które FINDSTR wykonuje na ciągach wiersza poleceń. Każdy znak jest reprezentowany jako dziesiętna wartość bajtu. Pierwszy kod reprezentuje znak podany w wierszu poleceń, a drugi kod reprezentuje znak, w który został przekształcony. Uwaga - ta lista została skompilowana na maszynie w USA. Nie wiem, jaki wpływ mogą mieć inne języki na tę 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
Każdy znak> 0 niewymieniony na powyższej liście jest traktowany jak sam, w tym <CR>i < LF>. Najprostszym sposobem na dołączenie nieparzystych znaków, takich jak <CR>i, <LF>jest umieszczenie ich w zmiennej środowiskowej i użycie opóźnionego rozwijania w argumencie wiersza poleceń.
Limity znaków dla ciągów znalezionych w plikach określonych przez opcje / G: FILE i / F: FILE
W pliku może pojawić się znak nul (0x00), ale działa on jak terminator ciągów C. Wszelkie znaki po znaku nul są traktowane jako inny ciąg znaków, jakby znajdowały się w innym wierszu.
<CR>I <LF>znaki są traktowane jako terminatory linii, które kończą ciąg, a nie uwzględnionych w ciąg.
Wszystkie pozostałe znaki jednobajtowe są doskonale zawarte w ciągu.
Wyszukiwanie plików Unicode
FINDSTR nie może poprawnie przeszukać większości Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32), ponieważ nie może wyszukiwać nul bajtów, a Unicode zwykle zawiera wiele nul bajtów.
Jednak polecenie TYPE konwertuje UTF-16LE z BOM na zestaw znaków jednobajtowych, więc takie polecenie jak poniższe będzie działać z UTF-16LE z BOM.
type unicode.txt|findstr "search"
Pamiętaj, że punkty kodu Unicode, które nie są obsługiwane przez twoją aktywną stronę kodową, zostaną przekonwertowane na ?znaki.
Możliwe jest wyszukiwanie UTF-8, o ile szukany ciąg zawiera tylko ASCII. Jednak dane wyjściowe konsoli wielobajtowych znaków UTF-8 nie będą prawidłowe. Ale jeśli przekierujesz dane wyjściowe do pliku, wynik zostanie poprawnie zakodowany UTF-8. Zauważ, że jeśli plik UTF-8 zawiera BOM, wówczas BOM będzie uważany za część pierwszego wiersza, co może uniemożliwić wyszukiwanie pasujące do początku wiersza.
Możliwe jest wyszukiwanie wielobajtowych znaków UTF-8, jeśli umieścisz szukany ciąg w pliku wyszukiwania zakodowanym w UTF-8 (bez BOM) i użyjesz opcji / G.
Koniec linii
FINDSTR przerywa linie natychmiast po każdym <LF>. Obecność lub brak <CR> nie ma wpływu na przerwy w linii.
Wyszukiwanie według podziałów linii
Zgodnie z oczekiwaniami, .metaznak wyrażenia regularnego nie będzie pasował do <CR> lub <LF>. Możliwe jest jednak przeszukiwanie podziału wiersza za pomocą ciągu wyszukiwania wiersza polecenia. Zarówno znaki <CR>, jak i <LF> muszą być wyraźnie dopasowane. W przypadku znalezienia dopasowania wieloliniowego drukowana jest tylko pierwsza linia dopasowania. FINDSTR następnie podwaja się do drugiej linii w źródle i rozpoczyna wyszukiwanie od nowa - coś w rodzaju funkcji „patrz przed siebie”.
Załóżmy, że TEXT.TXT ma te treści (może być w stylu Unix lub Windows)
A
A
A
B
A
A
Potem ten skrypt
@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
daje te wyniki
1:A
2:A
5:A
Przeszukiwanie podziałów wierszy za pomocą opcji / G: FILE jest niedokładne, ponieważ jedynym sposobem dopasowania <CR> lub <LF> jest wyrażenie wyrażenia zakresu klasy wyrażenia regularnego, które umieszcza znaki EOL.
[<TAB>-<0x0B>] pasuje do <LF>, ale pasuje również do <TAB> i <0x0B>
[<0x0C>-!] pasuje do <CR>, ale pasuje również do <0x0C> i!
Uwaga - powyższe są symbolicznymi reprezentacjami strumienia bajtów wyrażeń regularnych, ponieważ nie mogę graficznie przedstawić znaków.
Odpowiedź kontynuowana w części 2 poniżej ...
grepco jest bardzo dobrze zrozumiane i udokumentowane :-) Zobacz na przykład stackoverflow.com/questions/2635740/… .