Wat zijn de ongedocumenteerde functies en beperkingen van het Windows FINDSTR Commando?

Voorwoord
veel van de informatie in dit antwoord is verzameld op basis van experimenten uitgevoerd op een Vista-machine. Tenzij uitdrukkelijk anders vermeld, heb ik niet bevestigd of de informatie van toepassing is op andere Windows-versies.

FINDSTR uitvoer
de documentatie heeft nooit de moeite om de uitvoer van FINDSTR uit te leggen. Het verwijst naar het feit dat bijpassende lijnen worden afgedrukt, maar niets meer.,

het formaat van de overeenkomende regeluitvoer is als volgt:

bestandsnaam: regelnummer: lineOffset: tekst

waarbij

bestandsnaam: = de naam van het bestand dat de overeenkomende regel bevat. De bestandsnaam wordt niet afgedrukt als het verzoek expliciet voor een enkel bestand was, of als er wordt gezocht naar door pijpleidingen of omgeleide invoer. Wanneer de bestandsnaam wordt afgedrukt, bevat deze altijd de opgegeven padinformatie. Extra padinformatie zal worden toegevoegd als de optie /S wordt gebruikt. Het afgedrukte pad is altijd relatief ten opzichte van het opgegeven pad, of relatief ten opzichte van de huidige map als er geen is opgegeven.,

Note-Het bestandsnaamvoorvoegsel kan worden vermeden bij het zoeken van meerdere bestanden met behulp van de niet-standaard (en slecht gedocumenteerde) jokertekens < en >. De exacte regels voor hoe deze jokertekens werken kunt u hier vinden. Tot slot kunt u kijken naar dit voorbeeld van hoe de niet-standaard jokertekens werken met FINDSTR.

regelnummer: = het regelnummer van de overeenkomende regel weergegeven als een decimale waarde waarbij 1 de eerste regel van de invoer vertegenwoordigt. Alleen afgedrukt als /N optie is opgegeven.,

lineOffset: = de decimale byteverschuiving van het begin van de overeenkomende regel, waarbij 0 het 1e teken van de 1e regel vertegenwoordigt. Alleen afgedrukt als /O optie is opgegeven. Dit is niet de offset van de wedstrijd binnen de lijn. Het is het aantal bytes van het begin van het bestand tot het begin van de regel.

text = de binaire weergave van de overeenkomende regel, inclusief elke <CR> en/of <LF>., Er wordt niets uit de binaire uitvoer gelaten, zodat dit voorbeeld dat overeenkomt met alle regels een exacte binaire kopie van het originele bestand zal produceren.

FINDSTR "^" FILE >FILE_COPY

De Optie /A stelt de kleur in van de bestandsnaam:, regelnummer:, en regeloffset: alleen uitvoer. De tekst van de overeenkomende regel wordt altijd uitgevoerd met de huidige console kleur. De optie /A heeft alleen effect als de uitvoer direct op de console wordt weergegeven. De optie /A heeft geen effect als de uitvoer wordt omgeleid naar een bestand of doorsluipt., Zie de 2018-08-18 bewerken in Aacini ‘ s antwoord voor een beschrijving van het buggy gedrag wanneer uitvoer wordt omgeleid naar CON.

De meeste besturingskarakters en veel uitgebreide ASCII-tekens worden weergegeven als punten op XP
FINDSTR op XP toont de meeste niet-afdrukbare besturingskarakters van overeenkomende regels als punten (punten) op het scherm. De volgende besturingskarakters zijn uitzonderingen; ze worden weergegeven als zichzelf: 0x09 Tab, 0x0A LineFeed, 0x0b verticaal tabblad, 0x0C Form Feed, 0x0D Carriage Return.

XP FINDSTR converteert ook een aantal uitgebreide ASCII-tekens naar puntjes., De uitgebreide ASCII-tekens die als punten op XP worden weergegeven, zijn dezelfde als die welke worden getransformeerd wanneer ze op de opdrachtregel worden opgegeven. Zie de sectie “Character limits for command line parameters-Extended ASCII transformation”, later in dit bericht worden

Controlekarakters en extended ASCII niet geconverteerd naar puntjes op XP als de uitvoer wordt doorgesluisd, doorgestuurd naar een bestand, of binnen een for in() clausule.

Vista en Windows 7 tonen altijd alle tekens als zichzelf, nooit als puntjes.,

Return Codes (ERRORLEVEL)

• 0 (succes)
  • Match werd gevonden in ten minste één regel van ten minste één bestand.
• 1 (fout)
  • geen overeenkomst gevonden in een regel van een bestand.,iv id=”b01f5d4aef”>, /D: of /G:
  • Bestand gespecificeerd door /F:file of /G:file niet gevonden
• 255 (fout)
  • Te veel reguliere expressie karakter klasse voorwaarden
    zie Regex karakter klasse termijn te beperken en BUG in deel 2 van antwoord

Bron van gegevens voor het zoeken van (Bijgewerkt gebaseerd op tests met Windows 7)
Findstr kunt zoeken op gegevens van slechts één van de volgende bronnen:

• bestandsnamen opgegeven argumenten en/of met behulp van de /F:file optie.,

• stdin via omleiding findstr "searchString" <file

• gegevensstroom van een pijp type file | findstr "searchString"

argumenten/opties hebben voorrang op omleiding, die voorrang heeft op door pijpleidingen gegeven gegevens.

bestandsnaam argumenten en /F:file mogen worden gecombineerd. Meerdere bestandsnaam argumenten kunnen worden gebruikt. Als meerdere /F:file opties zijn opgegeven, dan wordt alleen de laatste gebruikt. Wild cards zijn toegestaan in bestandsnaamargumenten, maar niet in het bestand waarnaar wordt verwezen met /F:file.,

bron van zoekstrings (bijgewerkt op basis van tests met Windows 7)
de opties /G:file en /C:string kunnen worden gecombineerd. Er kunnen meerdere /C:string opties worden opgegeven. Als meerdere /G:file opties zijn opgegeven, dan wordt alleen de laatste gebruikt. Als ofwel /G:file of /C:string wordt gebruikt, dan worden alle niet-optieargumenten verondersteld bestanden te zijn om te zoeken., Als noch /G:file noch /C:string wordt gebruikt, dan wordt het eerste niet-optieargument behandeld als een door spaties gescheiden lijst van zoektermen.

bestandsnamen mogen niet worden geciteerd in het bestand bij gebruik van de optie/F:FILE.
bestandsnamen kunnen spaties en andere speciale tekens bevatten. De meeste commando ‘ s vereisen dat dergelijke bestandsnamen worden geciteerd. Maar de FINDSTR /F:files.txt optie vereist dat bestandsnamen binnen bestanden.txt mag niet worden geciteerd. Het bestand zal niet worden gevonden Als de naam wordt geciteerd.

BUG-Short 8.,3 bestandsnamen kunnen de /D en /S opties
zoals bij alle Windows commando ‘ s, zal FINDSTR proberen om zowel de lange naam als de korte 8.3 naam te matchen bij het zoeken naar bestanden om te zoeken. Stel dat de huidige map de volgende niet-lege bestanden bevat:

b1.txtb.txt2c.txt

het volgende commando zal met succes alle 3 bestanden vinden:

findstr /m "^" *.txt

b.txt2 komt overeen omdat de corresponderende Korte naam B9F64~1.TXT overeenkomt., Dit is consistent met het gedrag van alle andere Windows-opdrachten.

maar een bug met de opties /D en /S zorgt ervoor dat de volgende opdrachten alleen b1.txt

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

De bug voorkomt b.txt2 wordt gevonden, evenals alle bestandsnamen die Sorteren na b.txt2 in dezelfde map. Extra bestanden die eerder Sorteren, zoals a.txt, worden gevonden., Extra bestanden die later Sorteren, zoals d.txt, worden gemist zodra de bug is geactiveerd.

elke gezochte map wordt onafhankelijk behandeld. Bijvoorbeeld, de optie /S zou succesvol beginnen met zoeken in een dochtermap nadat er geen bestanden in de ouder zijn gevonden, maar zodra de bug ervoor zorgt dat een korte bestandsnaam wordt gemist in het kind, dan zullen alle volgende bestanden in die dochtermap ook worden gemist.

de commando ‘ s werken bug-vrij als dezelfde bestandsnamen worden aangemaakt op een machine die NTFS 8.3-naamgeneratie heeft uitgeschakeld., Natuurlijk zou b.txt2 niet gevonden worden, maar c.txt zou juist gevonden worden.

niet alle korte namen veroorzaken de bug. Alle gevallen van afgeluisterd gedrag die ik heb gezien hebben betrekking op een extensie die langer is dan 3 tekens met een korte 8.3 naam die hetzelfde begint als een normale naam die geen 8.3 naam vereist.

De bug is bevestigd op XP, Vista en Windows 7.,

niet-afdrukbare tekens en de/P optie
De/P optie zorgt ervoor dat FINDSTR elk bestand overslaat dat een van de volgende decimale bytecodes bevat:
0-7, 14-25, 27-31.

op een andere manier zal de optie /P alleen bestanden overslaan die niet-afdrukbare besturingskarakters bevatten. Controlekarakters zijn codes kleiner dan of gelijk aan 31 (0x1F)., FINDSTR behandelt de volgende besturingskarakters als afdrukbaar:

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

alle andere besturingskarakters worden behandeld als niet-afdrukbaar, waarvan de aanwezigheid de optie /P veroorzaakt om het bestand over te slaan.

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. Dit is bevestigd op XP, Vista en Windows 7., (Ik gebruikte om te denken dat de Windows pipe was verantwoordelijk voor het wijzigen van de input, maar ik heb sindsdien ontdekt dat FINDSTR is eigenlijk het doen van de wijziging.)

hetzelfde geldt voor omgeleide invoer in Vista. Als het laatste teken van een bestand dat wordt gebruikt als omgeleide invoer niet <LF> is, dan zal FINDSTR automatisch <CR><LF> aan de invoer toevoegen. Echter, XP en Windows 7 niet wijzigen omgeleide invoer.

FINDSTR hangt Op XP en Windows 7 als omgeleide invoer niet eindigt met <LF>
Dit is een vervelende” feature ” op XP en Windows 7., Als het laatste teken van een bestand dat gebruikt wordt als omgeleide invoer niet eindigt met <LF>, dan zal FINDSTR voor onbepaalde tijd blijven hangen zodra het einde van het omgeleide bestand bereikt is.

laatste regel met pijpleidingen mag worden genegeerd als deze bestaat uit een enkel teken
als de invoer wordt doorgesluisd en de laatste regel bestaat uit een enkel teken dat niet wordt gevolgd door <LF>, dan negeert FINDSTR de laatste regel volledig.,

voorbeeld-het eerste commando met een enkel teken en geen <LF> komt niet overeen, maar het tweede commando met 2 karakters werkt prima, net als het derde commando dat één teken heeft met terminating newline.

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

gerapporteerd door Dostips-gebruiker Sponge Belly bij nieuwe Findstr-bug. Bevestigd op XP, Windows 7 en Windows 8. Ik heb nog niets van Vista gehoord. (Ik heb geen Vista meer om te testen).

Optiesyntaxis
Optieletters zijn niet hoofdlettergevoelig, dus /i en /I zijn equivalent.,

opties kunnen worden voorafgegaan door / of -opties kunnen worden samengevoegd na een enkele / of -. De aaneengeschakelde optielijst kan echter maximaal één multicharacter-optie bevatten, zoals OFF of F:, en de optie met meerdere tekens moet de laatste optie in de lijst zijn.,

De volgende zijn allemaal gelijkwaardige manieren van het uiten van een hoofdlettergevoelig regex zoeken voor elke lijn bevat zowel ‘hallo’ en ‘tot ziens’ in willekeurige volgorde

• /i /r /c:"hello.*goodbye" /c:"goodbye.*hello"

• -i -r -c:"hello.*goodbye" /c:"goodbye.*hello"

• /irc:"hello.*goodbye" /c:"goodbye.*hello"

Als een zoek-string begint met een / of - letterlijke, daarna de /C of /G optie gebruikt moet worden. Met dank aan Stephan voor het melden van dit in een reactie (sinds verwijderd).,

lengte van de zoekstring
In Vista de maximaal toegestane lengte voor een enkele zoekstring is 511 bytes. Als een zoekstring groter is dan 511 dan is het resultaat een FINDSTR: Search string too long. fout met ERRORLEVEL 2.

bij het zoeken naar reguliere expressies is de maximale lengte van de zoekstring 254. Een reguliere expressie met een lengte tussen 255 en 511 zal resulteren in een FINDSTR: Out of memory fout met ERRORLEVEL 2. Een reguliere expressielengte >511 resulteert in de foutFINDSTR: Search string too long..,

Op Windows XP is de lengte van de zoekstring blijkbaar korter. Findstr error: “Search string too long” : hoe te extraheren en match substring in” for ” lus?De XP limiet is 127 bytes voor zowel letterlijke als regex zoekopdrachten.

limieten voor de regellengte
bestanden die zijn opgegeven als argument voor een opdrachtregel of via de optie / F: FILE hebben geen bekende limiet voor de regellengte. Zoekopdrachten zijn succesvol uitgevoerd met een 128MB bestand dat geen enkele <LF>bevatte.

doorgevoerde data en omgeleide invoer is beperkt tot 8191 bytes per regel., Deze limiet is een “feature” van FINDSTR. Het is niet inherent aan leidingen of omleiding. FINDSTR met behulp van omgeleide stdin of pijpleidingen zal nooit overeenkomen met een regel die >=8k bytes is. Regels >= 8k genereren een foutmelding naar stderr, maar ERRORLEVEL is nog steeds 0 als de zoekstring wordt gevonden in ten minste één regel van ten minste één bestand.

standaard type zoekopdracht: letterlijke vs Reguliere Expressie
/C:"string" – de standaard is / L letterlijk. Expliciet combineren van de / L optie met /C:” string ” werkt zeker maar is overbodig.,

"string argument" – de standaard hangt af van de inhoud van de allereerste zoekstring. (Onthoud dat <spatie> wordt gebruikt om zoekstrings af te bakenen.) Als de eerste zoekstring een geldige reguliere expressie is die ten minste één niet-escaped meta-teken bevat, dan worden alle zoekstrings behandeld als reguliere expressies. Anders worden alle zoekstrings behandeld als literalen., Bijvoorbeeld, "51.4 200" zal worden behandeld als twee reguliere expressies omdat de eerste tekenreeks een niet-escaped punt bevat, terwijl "200 51.4" zal worden behandeld als twee literalen omdat de eerste tekenreeks geen meta-tekens bevat.

/G:file – de standaard hangt af van de inhoud van de eerste niet-lege regel in het bestand. Als de eerste zoekstring een geldige reguliere expressie is die ten minste één niet-escaped meta-teken bevat, dan worden alle zoekstrings behandeld als reguliere expressies., Anders worden alle zoekstrings behandeld als literalen.

aanbeveling-geef altijd expliciet /L letterlijke optie of /R reguliere expressieoptie bij gebruik van "string argument" of /G:file.

BUG-het specificeren van meerdere letterlijke zoekstrings kan onbetrouwbare resultaten geven

het volgende eenvoudige FINDSTR voorbeeld kan geen overeenkomst vinden, ook al zou het moeten.

echo ffffaaa|findstr /l "ffffaaa faffaffddd"

deze bug is bevestigd op Windows Server 2003, Windows XP, Vista en Windows 7.,

op basis van experimenten kan FINDSTR mislukken als aan alle volgende voorwaarden is voldaan:

• De zoekopdracht gebruikt meerdere letterlijke zoekstrings
• de zoekstrings zijn van verschillende lengtes
• een korte zoekstring heeft enige overlap met een langere zoekstring
• de zoekopdracht is hoofdlettergevoelig (geen /I optie)

bij elke fout die ik heb gezien, is het altijd een van de kortere zoekstrings die faalt.

voor meer informatie zie waarom vindt dit FINDSTR-voorbeeld met meerdere letterlijke zoekstrings geen overeenkomst?,

citaten en backslahses binnen commandoregel argumenten
opmerking – gebruiker MC ND ‘ s opmerkingen weerspiegelen de werkelijke verschrikkelijk ingewikkelde regels voor deze sectie. Er zijn 3 verschillende parseerfasen betrokken:

• eerste cmd.,exe kan vereisen dat sommige aanhalingstekens als ^” (echt niets te maken met FINDSTR)
• volgende FINDSTR gebruikt de pre 2008 MS C/C++ argumentparser, die speciale regels heeft voor ” en \
• nadat de argumentparser is voltooid, behandelt FINDSTR bovendien \ gevolgd door een alfanumeriek teken als letterlijk, maar \ gevolgd door een niet-alfanumeriek teken als een escape-teken

de rest van deze gemarkeerde sectie is niet 100% correct. Het kan dienen als een leidraad voor veel situaties, maar de bovenstaande regels zijn vereist voor een volledig begrip.,

ontsnappende aanhalingstekens binnen opdrachtregelzoekstrings
aanhalingstekens binnen opdrachtregelzoekstrings moeten met backslash zoals\"worden escaped. Dit geldt voor zowel letterlijke als regex zoekstrings. Deze informatie is bevestigd op XP, Vista en Windows 7.

opmerking: het aanhalingsteken moet mogelijk ook worden weggelaten voor de CMD.EXE parser, maar dit heeft niets te maken met FINDSTR., Om bijvoorbeeld naar een enkel aanhalingsteken te zoeken kunt u het volgende gebruiken:

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

Backslash ontsnappen binnen opdrachtregel letterlijke zoekstrings
Backslash in een letterlijke zoekstring kan normaal gesproken worden weergegeven als\ of als \\. Ze zijn typisch gelijkwaardig. (Er kunnen ongebruikelijke gevallen in Vista waar de backslash moet altijd worden ontsnapt, maar ik heb geen Vista machine om te testen).

maar er zijn een aantal speciale gevallen:

bij het zoeken naar opeenvolgende backslashes moet alles behalve de laatste zichtbaar zijn., De laatste backslash kan eventueel worden ontsnapt.

• \\ kan worden gecodeerd als \\\ of \\\\
• \\\ kan worden gecodeerd als \\\\\ of \\\\\\

op Zoek naar een of meer backslashes voor een offerte is bizar. Logic zou suggereren dat het citaat moet worden ontsnapt, en elk van de leadingbackslashes zou moeten worden ontsnapt, maar dit werkt niet!, In plaats daarvan moet elk van de leidende backslashes dubbel escaped zijn,en het quoteis normaal escaped:

• \" moet worden gecodeerd als \\\\\"
• \\" moet worden gecodeerd als \\\\\\\\\"

zoals eerder opgemerkt, kan het ook nodig zijn om met ^ te ontsnappen voor de CMD-parser

de informatie in deze sectie is bevestigd op XP en Windows 7.,

Ontsnappen Backslash binnen commando lijn regex search strings

• Vista: Backslash in een regex, moet dubbel ontsnapte zoals \\\\, of anders enkele ontsnapte binnen een klasse set zoals

• XP en Windows 7: Backslash in een regex kan altijd worden weergegeven als . Het kan normaal gesproken worden weergegeven als \\. Maar dit werkt nooit als de backslash voorafgaat aan een ontsnapt citaat.,aped offerte moet bedouble ontsnapt, of anders gecodeerd als

  • \" kan worden gecodeerd als \\\\\" of \"
  • \\" kan worden gecodeerd als \\\\\\\\\" of \" of \\\"

Ontsnappen Offerte en een Backslash binnen /G:BESTAND zoeken op letterlijke tekenreeksen
Standalone aanhalingstekens en backslashes in een letterlijke tekenreeks zoeken bestand gespecificeerd door /G:bestand hoeft niet aan te ontkomen, maar ze kunnen worden.,

" en \" zijn gelijkwaardig.

\ en \\ zijn gelijkwaardig.

als de bedoeling is om \ \ te vinden, dan moet ten minste de leidende backslash worden escaped. Zowel \\\ als \\\\ werken.

als de bedoeling is om ” te vinden, dan moet tenminste de leidende backslash worden escaped. Zowel \\" als \\\" werken.,

Escaping Quote and Backslash within / G: FILE regex search strings
Dit is het enige geval waarin de escape sequences werken zoals verwacht op basis van de documentatie. Quote is geen regex metacharacter, dus het hoeft niet te worden ontsnapt (maar kan worden). Backslash is een regex metacharacter, dus het moet ontsnapt zijn.

tekenlimieten voor opdrachtregelparameters-uitgebreide ASCII-transformatie
Het null-teken (0x00) kan in geen enkele string op de opdrachtregel voorkomen. Elke andere enkele byte teken kan verschijnen in de string (0x01 – 0xFF)., FINDSTR converteert echter veel uitgebreide ASCII-tekens die het vindt binnen opdrachtregelparameters naar andere tekens. Dit heeft een grote impact op twee manieren:

1. veel uitgebreide ASCII-tekens komen niet overeen met zichzelf als ze worden gebruikt als een zoekstring op de opdrachtregel. Deze beperking is hetzelfde voor letterlijke en regex zoekopdrachten. Als een zoekstring uitgebreide ASCII moet bevatten, dan moet in plaats daarvan de optie /G:FILE worden gebruikt.

2. FINDSTR kan een bestand niet vinden als de naam uitgebreide ASCII-tekens bevat en de bestandsnaam is opgegeven op de opdrachtregel., Als een te doorzoeken bestand uitgebreide ASCII bevat in de naam, dan moet in plaats daarvan de optie /F:FILE worden gebruikt.

Hier is een complete lijst van uitgebreide ASCII-tekentransformaties die FINDSTR uitvoert op Command line strings. Elk teken wordt weergegeven als de waarde van de decimale bytecode. De eerste code vertegenwoordigt het teken zoals opgegeven op de opdrachtregel, en de tweede code vertegenwoordigt het teken waarin het wordt omgezet. Opmerking-deze lijst is samengesteld op een Amerikaanse machine. Ik weet niet welke impact andere talen op deze lijst kunnen hebben.,

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

elk teken >0 dat niet in de bovenstaande lijst voorkomt, wordt als zichzelf behandeld, inclusief <CR> en <LF>. De eenvoudigste manier om oneven tekens op te nemen zoals <CR> en <LF> is om ze in een omgevingsvariabele te krijgen en vertraagde expansie te gebruiken binnen het argument van de opdrachtregel.,

tekenlimieten voor tekenreeksen gevonden in bestanden gespecificeerd door / G: FILE en / F:FILE opties
Het nul (0x00) teken kan in het bestand verschijnen, maar het werkt als de c string terminator. Alle tekens na een nul-teken worden behandeld als een andere string alsof ze op een andere regel staan.

De<CR> en<LF> tekens worden behandeld als regelafbrekers die een tekenreeks beëindigen, en zijn niet opgenomen in de tekenreeks.

alle andere enkele byte tekens zijn perfect opgenomen in een string.,

zoeken in Unicode-bestanden
FINDSTR kan de meeste Unicode niet goed doorzoeken (UTF-16, UTF-16LE, UTF-16BE, UTF-32) omdat het niet kan zoeken naar nul bytes en Unicode bevat meestal veel nul bytes.

echter, het type Commando converteert UTF-16LE met BOM naar een enkele byte tekenset, dus een commando zoals het volgende zal werken met UTF-16LE met BOM.

type unicode.txt|findstr "search"

merk op dat Unicode-Codepunten die niet door uw actieve codepagina worden ondersteund, worden geconverteerd naar ? tekens.,

Het is mogelijk om UTF-8 te zoeken zolang uw zoekopdracht alleen ASCII bevat. Echter, de console uitvoer van elke multi-byte UTF-8 karakters zal niet correct zijn. Maar als u de uitvoer omleiden naar een bestand, dan zal het resultaat correct gecodeerd UTF-8. Merk op dat als het UTF-8 bestand een BOM bevat, dan wordt de BOM beschouwd als onderdeel van de eerste regel, wat een zoekopdracht die overeenkomt met het begin van een regel zou kunnen verstoren.

Het is mogelijk om multi-byte UTF-8 karakters te zoeken als u uw zoekstring in een UTF-8 gecodeerd zoekbestand plaatst (zonder BOM), en de optie /G gebruikt.,

einde van regel
FINDSTR breekt regels onmiddellijk na elke <LF>. De aanwezigheid of afwezigheid van <CR> heeft geen invloed op regelafbrekingen.

zoeken tussen regeleinden
zoals verwacht, zal de . regex metacharacter niet overeenkomen met <CR> or <LF>. Maar het is mogelijk om te zoeken over een regeleinde met behulp van een opdrachtregel zoekstring., Zowel de<CR> en<LF> moeten expliciet overeenkomen. Als een overeenkomst met meerdere regels wordt gevonden, wordt alleen de 1e regel van de overeenkomst afgedrukt. FINDSTR verdubbelt dan terug naar de 2e regel in de bron en begint de zoekopdracht helemaal opnieuw – soort van een “vooruit kijken” type functie.

neem tekst aan.,TXT heeft de volgende inhoud (kan een Unix of Windows-stijl)

AAABAA

Dan is dit script

geeft deze resultaten

1:A2:A5:A

Zoeken in lijn breekt met de /G:De optie BESTAND is onnauwkeurig omdat de enige manier om overeenkomen met <CR> of <LF> via een reguliere karakter class reeks expressie die broodjes de EOL-tekens.,

• 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.,

antwoord vervolg in deel 2 hieronder…