By : admin

Przedmowa
większość informacji zawartych w tej odpowiedzi została zebrana w oparciu o eksperymenty prowadzone na maszynie Vista. O ile wyraźnie nie zaznaczono inaczej, nie potwierdziłem, czy informacje dotyczą innych wersji systemu Windows.

wyjście FINDSTR
dokumentacja nigdy nie przeszkadza w wyjaśnieniu wyjścia FINDSTR. Nawiązuje to do faktu, że pasujące linie są drukowane, ale nic więcej.,

format dopasowanego wiersza wyjściowego jest następujący:

filename:lineNumber:lineOffset:text

where

fileName: = nazwa pliku zawierającego pasującą linię. Nazwa pliku nie jest drukowana, jeśli żądanie było jawnie dla pojedynczego pliku, lub jeśli szukano piped input lub przekierowanego input. Po wydrukowaniu nazwa pliku zawsze będzie zawierać informacje o podanej ścieżce. Dodatkowe informacje o ścieżce zostaną dodane, jeśli używana jest opcja /S. Drukowana ścieżka jest zawsze względem podanej ścieżki lub względem bieżącego katalogu, jeśli nie podano.,

Uwaga-prefiksu nazwy pliku można uniknąć podczas przeszukiwania wielu plików za pomocą 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, jak niestandardowe symbole wieloznaczne działają z FINDSTR.

lineNumber: = numer linii pasującego wiersza reprezentowany jako wartość dziesiętna z 1 reprezentującym 1.linię wejścia. Drukowane tylko wtedy, gdy podano opcję /N.,

lineOffset: = dziesiętne przesunięcie bajtów początku pasującego wiersza, z 0 reprezentującym 1. znak 1. wiersza. Drukowane tylko wtedy, gdy podano opcję /O. Nie jest to przesunięcie dopasowania w linii. Chodzi o ilość bajtów od początku pliku do początku linii.

text = binarna reprezentacja pasującej linii, w tym Dowolna<CR> I/lub<LF>., Nic nie zostanie pominięte z wyjścia binarnego, tak że ten przykład, który pasuje do wszystkich linii, wytworzy dokładną kopię binarną oryginalnego pliku.

FINDSTR "^" FILE >FILE_COPY

opcja / A ustawia tylko kolor nazwy pliku:, numeru linii: i lineoffset:. Tekst pasującej linii jest zawsze wyświetlany z bieżącym kolorem konsoli. Opcja /A działa tylko wtedy, gdy wyjście jest wyświetlane bezpośrednio na konsoli. Opcja /A nie działa, jeśli wyjście jest przekierowywane do pliku lub rurociągu., Zobacz edycję 2018-08-18 w odpowiedzi Aaciniego, aby znaleźć opis zachowania błędów podczas przekierowywania wyjścia na CON.

większość znaków sterujących i wiele rozszerzonych znaków ASCII wyświetla jako kropki na XP
FINDSTR na XP wyświetla większość niedrukowalnych znaków sterujących z pasujących linii jako kropki (kropki) na ekranie. Wyjątkami są następujące znaki sterujące: 0x09 Tab, 0x0A LineFeed, 0x0b Vertical Tab, 0x0c Form Feed, 0x0d Carriage Return.

XP FINDSTR konwertuje również wiele rozszerzonych znaków ASCII na kropki., Rozszerzone znaki ASCII, które wyświetlają się jako kropki na XP, są takie same jak te, które są przekształcane, gdy są dostarczane w wierszu poleceń. Zobacz sekcję „limity znaków dla parametrów wiersza poleceń – Rozszerzona transformacja ASCII”, później w tym poście

znaki sterujące i rozszerzone ASCII nie są konwertowane na kropki w XP, JEŚLI wyjście jest przekierowane do pliku lub w klauzuli FOR IN ().

Vista i Windows 7 zawsze wyświetlają wszystkie znaki jako siebie, nigdy jako kropki.,

kody zwrotne (ERRORLEVEL)

  • 0 (success)
    • dopasowanie zostało znalezione w co najmniej jednej linii co najmniej jednego pliku.
  • 1 (awaria)
    • nie znaleziono dopasowania w żadnej linii żadnego pliku.,iv id=”b01f5d4aef”>, /D: lub /G:
    • plik określony przez /F:file lub /G:file nie znaleziono
  • 255 (błąd)
    • zbyt wiele terminów klas znaków wyrażeń regularnych
      Zobacz limit terminów klas znaków regex i błąd w części 2 odpowiedzi

źródło danych do wyszukiwania (zaktualizowane na podstawie testów z 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 używając/F:fileopcja.,

  • stdin przez przekierowaniefindstr "searchString" <file

  • strumień danych z rurytype file | findstr "searchString"

argumenty / opcje mają pierwszeństwo przed przekierowaniem, które ma pierwszeństwo przed danymi rurociągowymi.

argumenty nazwy pliku i/F:file mogą być połączone. Można użyć wielu argumentów nazwy pliku. Jeśli podano wiele opcji /F:file, to używana jest tylko ostatnia. Dzikie karty są dozwolone w argumentach nazw plików, ale nie w pliku wskazywanym przez /F:file.,

źródło ciągów wyszukiwania (zaktualizowane na podstawie testów z Windows 7)
Opcje/G:file I/C:string mogą być połączone. Można podać wiele opcji /C:string. Jeśli podano wiele opcji /G:file, to używana jest tylko ostatnia. Jeśli użyto /G:filelub/C:string, to przyjmuje się, że wszystkie argumenty nie będące opcjami są plikami do przeszukiwania., Jeśli nie użyto ani /G:file ani /C:string, to pierwszy argument nie będący opcją jest traktowany jako oddzielona spacjami lista wyszukiwanych terminów.

nazwy plików nie mogą być cytowane w pliku podczas korzystania z opcji/F:FILE.
nazwy plików mogą zawierać spacje i inne znaki specjalne. Większość poleceń wymaga, aby takie nazwy plików były cytowane. Ale opcja FINDSTR /F:files.txt wymaga, aby nazwy plików w plikach.txt nie może być cytowany. Plik nie zostanie znaleziony, jeśli nazwa jest zacytowana.

BUG – Short 8.,3 nazwy plików mogą złamać /D I /S opcje
podobnie jak w przypadku wszystkich poleceń systemu Windows, FINDSTR spróbuje dopasować zarówno długą nazwę, jak i krótką nazwę 8.3 podczas wyszukiwania plików do wyszukiwania. Załóżmy, że bieżący folder zawiera następujące niepuste pliki:

b1.txtb.txt2c.txt

następujące polecenie z powodzeniem znajdzie wszystkie 3 pliki:

findstr /m "^" *.txt

b.txt2 pasuje, ponieważ odpowiednia krótka nazwa B9F64~1.TXT mecze., Jest to zgodne z zachowaniem wszystkich innych poleceń systemu Windows.

ale błąd z opcjami /D I /S powoduje, że następujące polecenia znajdują tylko b1.txt

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

błąd zapobiega b.txt2 od znalezienia, a także wszystkie nazwy plików, które sortują po b.txt2 w tym samym katalogu. Znajdują się dodatkowe pliki, które zostały wcześniej sortowane, takie jak a.txt., Dodatkowe pliki, które zostaną później sortowane, takie jak d.txt, są pomijane po wywołaniu błędu.

każdy przeszukiwany katalog jest traktowany niezależnie. Na przykład, opcja /S z powodzeniem rozpocznie wyszukiwanie w folderze potomnym po nieudanym znalezieniu plików w rodzicu, ale gdy błąd spowoduje pominięcie krótkiej nazwy pliku w folderze potomnym, wszystkie kolejne pliki w tym folderze potomnym również zostaną pominięte.

polecenia działają bez błędów, jeśli te same nazwy plików są tworzone na komputerze, który ma wyłączoną generację nazw NTFS 8.3., Oczywiście b.txt2 nie zostanie znaleziony, ale c.txt zostanie znaleziony poprawnie.

nie wszystkie krótkie nazwy wywołują błąd. Wszystkie przypadki podsłuchowego zachowania, które widziałem, obejmują rozszerzenie, które jest dłuższe niż 3 znaki z krótką nazwą 8.3, która zaczyna się tak samo jak normalna nazwa, która nie wymaga nazwy 8.3.

błąd został potwierdzony NA XP, Vista i Windows 7.,

Znaki niedrukowalne i opcja/P
opcja/P powoduje, że FINDSTR pomija dowolny plik zawierający dowolny z następujących bajtów dziesiętnych:
0-7, 14-25, 27-31.

mówiąc inaczej, opcja/P pomija tylko pliki zawierające niedrukowalne znaki sterujące. Znaki kontrolne to kody mniejsze lub równe 31 (0x1F)., FINDSTR traktuje następujące znaki sterujące jako drukowalne:

 8 0x08 backspace 9 0x09 horizontal tab10 0x0A line feed11 0x0B vertical tab12 0x0C form feed13 0x0D carriage return26 0x1A substitute (end of text)

wszystkie pozostałe znaki sterujące są traktowane jako niedrukowalne, których obecność powoduje, że /P opcja pominięcia pliku.

Piped i przekierowane wejście może mieć<CR><LF> dołączone
Jeśli wejście jest piped i ostatni znak strumienia nie jest<LF>, FINDSTR automatycznie doda<CR><LF> do wejścia. Zostało to potwierdzone na XP, Vista i Windows 7., (Kiedyś myślałem, że rura systemu Windows była odpowiedzialna za modyfikację wejścia, ale od tego czasu odkryłem, że FINDSTR faktycznie robi modyfikację.)

to samo dotyczy przekierowanego wejścia na Vistę. Jeśli ostatni znak pliku używanego jako przekierowane wejście nie jest <LF>, FINDSTR automatycznie doda <CR><LF> do wejścia. Jednak XP i Windows 7 nie zmieniają przekierowanego wejścia.

FINDSTR zawiesza się na XP i Windows 7, jeśli przekierowane wejście nie kończy się<LF>
Jest to paskudna „funkcja” Na XP i Windows 7., Jeśli ostatni znak pliku używanego jako przekierowane wejście nie kończy się <LF>, FINDSTR zawiesi się na czas nieokreślony, gdy dotrze do końca przekierowanego pliku.

ostatni wiersz Piped data może być ignorowany, jeśli składa się z pojedynczego znaku
Jeśli wejście jest piped in, a ostatni wiersz składa się z pojedynczego znaku, po którym nie następuje<LF>, FINDSTR całkowicie ignoruje ostatni wiersz.,

przykład – pierwsze polecenie z pojedynczym znakiem i bez <LF> nie pasuje, ale drugie polecenie z 2 Znakami działa dobrze, podobnie jak trzecie polecenie, które ma jeden znak z zakończeniem nowego wiersza.

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

zgłoszone przez użytkownika DosTips Sponge Belly przy Nowym błędzie findstr. Potwierdzone na XP, Windows 7 i Windows 8. Nie słyszałem jeszcze o Vistie. (Nie Mam już Visty do testowania).

składnia opcji
litery opcji nie uwzględniają wielkości liter, więc/i I /I są równoważne.,

opcje mogą być poprzedzone przez/ lub-opcje mogą być połączone po jednym/ lub-. Jednak skonkatenowana lista opcji może zawierać co najwyżej jedną opcję wieloznakową, taką jak OFF lub F:, A opcja wieloznakowa musi być ostatnią opcją na liście.,

poniżej przedstawiono wszystkie równoważne sposoby wyrażania przeszukiwania regex bez rozróżniania wielkości liter dla dowolnej linii, która zawiera zarówno „hello”, jak i „goodbye” 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"

jeśli szukany ciąg zaczyna się od /lub-literalnie, tolub. Dzięki Stephan za zgłoszenie tego w komentarzu (od usunięcia).,

Ograniczenia długości ciągu wyszukiwania
w systemie Vista maksymalna dozwolona długość pojedynczego ciągu Wyszukiwania wynosi 511 bajtów. Jeśli szukany ciąg przekracza 511, wynikiem jest błądFINDSTR: Search string too long. z błędem ERRORLEVEL 2.

podczas wyszukiwania wyrażeń regularnych maksymalna długość ciągu Wyszukiwania wynosi 254. Wyrażenie regularne o długości od 255 do 511 spowoduje błądFINDSTR: Out of memory z błędem ERRORLEVEL 2. Długość wyrażenia regularnego >511 powoduje błąd FINDSTR: Search string too long..,

w systemie Windows XP długość szukanego ciągu jest najwyraźniej krótsza. Błąd Findstr: „zbyt długi ciąg wyszukiwania” : Jak wyodrębnić i dopasować podłańcuch w pętli „for”?Limit XP wynosi 127 bajtów dla wyszukiwania dosłownego i regex.

Ograniczenia długości linii
pliki podane jako argument wiersza poleceń lub za pomocą opcji / f:FILE nie mają znanego limitu długości linii. Wyszukiwanie zostało pomyślnie przeprowadzone na pliku 128MB, który nie zawierał jednego <LF>.

przesyłane dane i przekierowane dane wejściowe są ograniczone do 8191 bajtów na linię., Ten limit jest „funkcją” FINDSTR. Nie jest to nieodłączne dla rur lub przekierowania. FINDSTR używając przekierowanego wejścia stdin lub piped, nigdy nie będzie pasował do linii > = 8k bajtów. Linie > = 8k generują komunikat o błędzie na stderr, ale poziom błędu jest nadal 0, jeśli szukany ciąg zostanie znaleziony w co najmniej jednej linii co najmniej jednego pliku.

domyślny typ wyszukiwania: Literal vs Wyrażenie regularne
/C:"string" – domyślnym typem jest /L literal. Jawne połączenie opcji /L z /C: „string” z pewnością działa, ale jest zbędne.,

"string argument" – wartość domyślna zależy od zawartości pierwszego szukanego ciągu. (Pamiętaj, że<spacja> jest używana do rozdzielania ciągów wyszukiwania.) Jeśli pierwszy wyszukiwany ciąg znaków jest poprawnym wyrażeniem regularnym, które zawiera co najmniej jeden meta-znak, który nie został zabezpieczony, to wszystkie wyszukiwane ciągi znaków są traktowane jako wyrażenia regularne. W przeciwnym razie wszystkie ciągi wyszukiwania są traktowane jako literały., Na przykład "51.4 200"będzie traktowane jako dwa wyrażenia regularne, ponieważ pierwszy łańcuch zawiera kropkę, której nie udało się uniknąć, natomiast"200 51.4" będzie traktowany jako dwa literały, ponieważ pierwszy łańcuch nie zawiera żadnych meta-znaków.

/G:file – wartość domyślna zależy od zawartości pierwszej niepustej linii w pliku. Jeśli pierwszy wyszukiwany ciąg znaków jest poprawnym wyrażeniem regularnym, które zawiera co najmniej jeden meta-znak, który nie został zabezpieczony, to wszystkie wyszukiwane ciągi znaków są traktowane jako wyrażenia regularne., W przeciwnym razie wszystkie ciągi wyszukiwania są traktowane jako literały.

rekomendacja – zawsze jawnie określaj /L literalną opcję lub /R opcję wyrażenia regularnego podczas używania "string argument" lub /G:file.

Bug – Specificing multiple literal search strings can give unreliable results

poniższy prosty przykład FINDSTR nie znajduje dopasowania, mimo że powinien.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

ten błąd został potwierdzony w systemach Windows Server 2003, Windows XP, Vista i Windows 7.,

w oparciu o eksperymenty, FINDSTR może się nie powieść, jeśli spełnione są wszystkie następujące warunki:

  • wyszukiwanie używa wielu literalnych ciągów wyszukiwania
  • ciągi wyszukiwania są różnej długości
  • krótki ciąg wyszukiwania ma pewną nakładkę na dłuższy ciąg wyszukiwania
  • Wyszukiwanie ma rozróżnianą wielkość liter (brak opcji /I)

w każdym niepowodzeniu, które widziałem, jest to zawsze jeden z krótszych ciągów wyszukiwania, który zawodzi.

aby uzyskać więcej informacji zobacz Dlaczego ten przykład FINDSTR z wieloma literalnymi ciągami wyszukiwania nie znajduje dopasowania?,

cudzysłowy i odwrotne ukośniki w argumentach wiersza poleceń
Uwaga – komentarze użytkownika MC ND odzwierciedlają rzeczywiste reguły tej sekcji. Istnieją 3 różne fazy parsowania:

  • pierwszy cmd.,exe może wymagać, aby niektóre cudzysłowy były przetwarzane jako ^ „(naprawdę nie ma to nic wspólnego z FINDSTR)
  • następny FINDSTR używa parsera 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 literalny, ale\, po którym następuje znak nie-alfanumeryczny jako znak escape

pozostała część tej podświetlonej sekcji nie jest w 100% poprawna. Może służyć jako przewodnik dla wielu sytuacji, ale powyższe zasady są wymagane do całkowitego zrozumienia.,

Cytaty w przeszukiwanych wierszach poleceń
Cytaty w przeszukiwanych wierszach poleceń muszą zawierać znaki z odwrotnym ukośnikiem, takie jak\". Dotyczy to zarówno ciągów wyszukiwania dosłownego, jak i regex. Informacja ta została potwierdzona w systemach XP, Vista i Windows 7.

Uwaga: cytat może być również wymagający klauzuli escape dla CMD.Parser EXE, ale to nie ma nic wspólnego z FINDSTR., Na przykład, aby wyszukać pojedynczy cudzysłów, możesz użyć:

FINDSTR \^" file && echo found || echo not found

Uciekające ukośniki w literalnych ciągach wyszukiwania wiersza poleceń
odwrotny ukośnik w literalnym ciągu wyszukiwania może być normalnie reprezentowany jako\ lub jako \\. Są one zazwyczaj równoważne. (Nie może być nietypowe w Vista gdzie ukośnik musi być zawsze ucieczki, ale ja nolonger mieć Vista maszyna do testowania).

ale są pewne szczególne przypadki:

podczas wyszukiwania kolejnych ukośników wstecznych, wszystkie oprócz ostatniego muszą być zaklejone., Ostatni ukośnik może być opcjonalnie unikany.

  • \\ można kodować jako \\\ lub \\\\

    • \\\można kodować jako\\\\\lub\\\\\\

wyszukiwanie jednego lub więcej ukośników przed cytatem jest dziwaczne. Logika sugerowałaby, że cytat musi być escape, a każdy z leadingbackslash musi być Escape, ale to nie działa!, Zamiast tego,każdy z wiodących ukośników wstecznych musi być podwójnie zabezpieczony, a cytat musi być normalnie zabezpieczony:

  • \" musi być zakodowany jako \\\\\"

    • \\"musi być zakodowany jako\\\\\" \\" musi być zakodowany jako \\\\\\\\\"

jak już wcześniej wspomniano, jeden lub więcej cudzysłowów unikalnych może również wymagać interpretacji z ^ dla parsera cmd

informacje w tej sekcji zostały potwierdzone w xp i Windows 7.,

Uciekające ukośniki w wierszu poleceń ciągi wyszukiwania regex

  • Vista only: ukośniki w regex muszą być albo podwójne, jak\\\\, albo pojedyncze znaki ucieczki w zestawie klas znaków, jak

  • XP i Windows 7: ukośniki w regex może być zawsze reprezentowany jako. Zwykle może być reprezentowany jako \\. Ale to nigdy nie działa, jeśli ukośnik poprzedza uciekający cytat.,aped cytat musi być albo bedouble Escape, albo kodowany jako

    • \" może być kodowany jako \\\\\" lub \"
    • \\" może być kodowany jako \\\\\\\\\" lub \" lub \\\"

unikające cudzysłowów i odwróconego ukośnika w /g:pliku literalne ciągi wyszukiwania
samodzielne cudzysłowy i odwrócone ukośniki w pliku literalnego ciągu wyszukiwania określonego przez /G:plik nie muszą być znakami ucieczki, ale mogą być.,

" I\" są równoważne.

\ I\\ są równoważne.

jeśli intencją jest znalezienie \\, to przynajmniej początkowy ukośnik musi być unikalny. Zarówno\\\, jak i\\\\ działają.

jeśli intencją jest find „, to przynajmniej początkowy ukośnik musi być unikalny. Zarówno\\" I\\\" działają.,

sekwencje escape Quote I Backslash w / G:FILE regex search strings
jest to jedyny przypadek, w którym sekwencje escape działają zgodnie z oczekiwaniami na podstawie dokumentacji. Quote nie jest metacharakterem regex, więc nie musi być unikany (ale może być). Backslash jest metacharakterem regex, więc musi być unikany.

limity znaków dla parametrów wiersza poleceń – Rozszerzona transformacja ASCII
znak null (0x00) nie może pojawić się w żadnym łańcuchu w wierszu poleceń. W łańcuchu może pojawić się dowolny inny znak jednobajtowy (0x01 – 0xff)., Jednak FINDSTR konwertuje wiele rozszerzonych znaków ASCII, które znajduje 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ć do siebie, jeśli zostaną użyte jako ciąg wyszukiwania w wierszu poleceń. To ograniczenie jest takie samo dla wyszukiwania dosłownego i regex. Jeśli szukany ciąg znaków musi zawierać rozszerzone ASCII, należy użyć opcji /G:FILE.

  2. FINDSTR może nie znaleźć pliku, jeśli nazwa zawiera rozszerzone znaki ASCII, a nazwa pliku jest podana w wierszu poleceń., Jeśli przeszukiwany plik zawiera rozszerzone ASCII w nazwie, należy użyć opcji /F:FILE.

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 wartość kodu bajtów dziesiętnych. Pierwszy kod reprezentuje znak podany w wierszu poleceń, a drugi kod reprezentuje znak, w który jest przekształcany. Uwaga-lista ta została sporządzona na maszynie amerykańskiej. Nie wiem, jaki wpływ na tę listę mogą mieć inne języki.,

158 treated as 080 199 treated as 221 226 treated as 071169 treated as 170 200 treated as 043 227 treated as 112176 treated as 221 201 treated as 043 228 treated as 083177 treated as 221 202 treated as 045 229 treated as 115178 treated as 221 203 treated as 045 231 treated as 116179 treated as 221 204 treated as 221 232 treated as 070180 treated as 221 205 treated as 045 233 treated as 084181 treated as 221 206 treated as 043 234 treated as 079182 treated as 221 207 treated as 045 235 treated as 100183 treated as 043 208 treated as 045 236 treated as 056184 treated as 043 209 treated as 045 237 treated as 102185 treated as 221 210 treated as 045 238 treated as 101186 treated as 221 211 treated as 043 239 treated as 110187 treated as 043 212 treated as 043 240 treated as 061188 treated as 043 213 treated as 043 242 treated as 061189 treated as 043 214 treated as 043 243 treated as 061190 treated as 043 215 treated as 043 244 treated as 040191 treated as 043 216 treated as 043 245 treated as 041192 treated as 043 217 treated as 043 247 treated as 126193 treated as 045 218 treated as 043 249 treated as 250194 treated as 045 219 treated as 221 251 treated as 118195 treated as 043 220 treated as 095 252 treated as 110196 treated as 045 222 treated as 221 254 treated as 221197 treated as 043 223 treated as 095198 treated as 221 224 treated as 097

każdy znak >0 nie znajdujący się na powyższej liście jest traktowany jako sam w sobie, w tym <CR> I <LF>. Najprostszym sposobem na dodanie nieparzystych znaków, takich jak <CR> I <LF> jest wprowadzenie ich do zmiennej środowiskowej i użycie opóźnionego rozszerzenia w argumencie wiersza poleceń.,

limity znaków dla łańcuchów znalezionych w plikach określonych opcjami /G:FILE i / F:FILE
znak nul (0x00) może pojawić się w pliku, ale działa jak Terminator łańcuchów C. Znaki po znaku nul są traktowane jako inny ciąg znaków tak, jakby znajdowały się w innej linii.

znaki<CR> I<LF> są traktowane jako terminatory linii kończące łańcuch i nie są zawarte w łańcuchu.

wszystkie pozostałe znaki jednobajtowe są zawarte idealnie w ciągu znaków.,

wyszukiwanie plików Unicode
FINDSTR nie może poprawnie przeszukiwać większości Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32), ponieważ nie może wyszukiwać bajtów nul, a Unicode zazwyczaj zawiera wiele bajtów nul.

jednak polecenie TYPE konwertuje UTF-16LE z BOM na pojedynczy bajtowy zestaw znaków, więc polecenie takie jak poniżej będzie działać z UTF-16LE z BOM.

type unicode.txt|findstr "search"

zauważ, że punkty kodu Unicode, które nie są obsługiwane przez aktywną stronę kodową, zostaną przekonwertowane na znaki?.,

możliwe jest wyszukiwanie UTF-8, o ile szukany ciąg zawiera tylko ASCII. Jednak wyjście konsoli dla wielobajtowych znaków UTF-8 nie będzie poprawne. Ale jeśli przekierujesz wyjście do pliku, wtedy wynik będzie poprawnie zakodowany UTF-8. Zauważ, że jeśli plik UTF-8 zawiera BOM, to BOM będzie uważany za część pierwszej linii, co może wyłączyć wyszukiwanie pasujące do początku linii.

możliwe jest przeszukiwanie wielobajtowych znaków UTF-8, Jeśli umieścisz szukany ciąg w zakodowanym pliku wyszukiwania UTF-8 (bez BOM) i użyjesz opcji /G.,

koniec wiersza
FINDSTR łamie wiersze natychmiast po każdym <LF>. Obecność lub brak <CR> nie ma wpływu na podziały linii.

wyszukiwanie w poprzek linii
zgodnie z oczekiwaniami, . metacharacter regex nie będzie pasował <CR> lub <LF>. Ale możliwe jest przeszukiwanie po podziale linii za pomocą ciągu wyszukiwania wiersza poleceń., Zarówno<CR> I<LF> znaki muszą być dopasowane jawnie. W przypadku znalezienia dopasowania wielowierszowego 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 typu „patrz w przyszłość”.

zakładaj tekst.,TXT ma taką zawartość (może być w stylu Unix lub Windows)

AAABAA

następnie ten skrypt

daje te wyniki

1:A2:A5:A

wyszukiwanie po przerwach linii przy użyciu opcji pliku /G:jest nieprecyzyjne, ponieważ jedynym sposobem na dopasowanie <CR> lub <LF> jest wyrażeniem klasy znaków regex, które Zastępuje znaki EOL.,

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

  • matches <CR>, but it also matches <0x0C> and !

Note – the above are symbolic representations of the regex byte stream since I can’t graphically represent the characters.,

odpowiedź ciąg dalszy w części 2 poniżej…

Articles

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *