서문
이 답변의 많은 정보는 Vista 시스템에서 실행 된 실험을 기반으로 수집되었습니다. 명시 적으로 달리 명시하지 않는 한, 정보가 다른 Windows 버전에 적용되는지 확인하지 않았습니다.
FINDSTR 출력
이 문서는 FINDSTR의 출력을 설명 할 필요가 없습니다. 일치하는 줄이 인쇄된다는 사실을 암시하지만 더 이상은 없습니다.
일치하는 라인 출력 형식은 다음과 같습니다.
filename : lineNumber : lineOffset : 텍스트
어디
fileName : = 일치하는 줄을 포함하는 파일 이름. 요청이 단일 파일에 대한 명시 적이거나 파이프 입력 또는 경로 재 지정된 입력을 검색하는 경우 파일 이름이 인쇄되지 않습니다. 인쇄 될 때, fileName은 항상 제공된 경로 정보를 포함합니다. /S옵션을 사용하면 추가 경로 정보가 추가됩니다. 인쇄 된 경로는 항상 제공된 경로를 기준으로하거나 제공된 디렉토리가없는 경우 현재 디렉토리를 기준으로합니다.
주 - 사용하여 여러 파일을 검색 할 때 파일 이름 접두어가 피할 수 비표준 (그리고 제대로 문서화) 와일드 카드 < 와 >. 이러한 와일드 카드 작동 방식에 대한 정확한 규칙은 여기에서 확인할 수 있습니다 . 마지막으로 비표준 와일드 카드가 FINDSTR과 함께 작동하는 방법에 대한 이 예제를 볼 수 있습니다 .
lineNumber : = 입력의 첫 번째 행을 나타내는 1과 함께 10 진수 값으로 표시되는 일치하는 행의 행 번호입니다. /N옵션이 지정된경우에만 인쇄됩니다.
lineOffset : = 일치하는 줄 시작 부분의 10 진수 바이트 오프셋. 0은 첫 번째 줄의 첫 번째 문자를 나타냅니다. /O옵션이 지정된경우에만 인쇄됩니다. 이것은라인 내에서 일치하는 오프셋이 아닙니다 . 파일의 시작부터 행의 시작까지의 바이트 수입니다.
text = <CR> 및 / 또는 <LF>를 포함하여 일치하는 줄의 이진 표현입니다. 모든 행과 일치하는이 예제는 원본 파일의 정확한 이진 사본을 생성하도록 이진 출력에서 제외되는 것은 없습니다.
FINDSTR "^" FILE >FILE_COPY
/ A 옵션은 fileName :, lineNumber : 및 lineOffset : 출력의 색상 만 설정합니다. 일치하는 줄의 텍스트는 항상 현재 콘솔 색상으로 출력됩니다. / A 옵션은 출력이 콘솔에 직접 표시 될 때만 적용됩니다. 출력이 파일로 경로 재 지정되거나 파이프 된 경우 / A 옵션은 적용되지 않습니다. 출력이 CON으로 리디렉션 될 때 버기 동작에 대한 설명은 Aacini의 답변에서 2018-08-18 편집을 참조하십시오 .
XP에서 대부분의 제어 문자 및 많은 확장 ASCII 문자가 도트로 표시 XP의
FINDSTR은 화면에서 일치하는 행의 대부분의 인쇄 불가능 제어 문자를 도트 (마침표)로 표시합니다. 다음 제어 문자는 예외입니다. 0x09 탭, 0x0A LineFeed, 0x0B 세로 탭, 0x0C 용지 공급, 0x0D 캐리지 리턴으로 표시됩니다.
XP FINDSTR은 또한 다수의 확장 ASCII 문자를 도트로 변환합니다. XP에서 점으로 표시되는 확장 ASCII 문자는 명령 행에서 제공 될 때 변환 된 것과 동일합니다. 참고 항목 "명령 줄 매개 변수에 대한 문자 제한을 - 확장 ASCII 변환" 나중에 섹션을,이 게시물에
출력이 파이프되거나 파일로 경로 재 지정되거나 FOR IN () 절 내에서 제어 문자 및 확장 ASCII는 XP에서 도트로 변환되지 않습니다.
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옵션을 사용하여 지정된 파일 이름 .
리디렉션을 통한 표준 입력 findstr "searchString" <file
파이프에서 데이터 스트림 type file | findstr "searchString"
인수 / 옵션은 리디렉션보다 우선하며 파이프 된 데이터보다 우선합니다.
파일 이름 인수와 /F:file결합 될 수 있습니다. 여러 파일 이름 인수를 사용할 수 있습니다. 여러 /F:file옵션을 지정하면 마지막 옵션 만 사용됩니다. 와일드 카드는 파일 이름 인수에 사용할 수 있지만로 가리키는 파일에는 사용할 수 없습니다 /F:file.
검색 문자열의 소스는 (Windows 7과 테스트를 기반으로 업데이트) 및 옵션이 결합 될 수있다. 여러 옵션을 지정할 수 있습니다. 여러 옵션을 지정하면 마지막 옵션 만 사용됩니다. 또는 중 하나 를 사용하는 경우 모든 비 옵션 인수는 검색 할 파일로 간주됩니다. nor 도 사용 하지 않으면 첫 번째 비 옵션 인수는 공백으로 구분 된 검색어 목록으로 처리됩니다.
/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올바르게 찾을 수 있습니다.
짧은 이름이 모두 버그를 유발하는 것은 아닙니다. 내가 본 버그가있는 동작의 모든 인스턴스에는 8.3 이름이 필요하지 않은 일반 이름과 동일하게 시작되는 짧은 8.3 이름을 가진 3 자보다 긴 확장명이 포함됩니다.
XP, Vista 및 Windows 7에서 버그가 확인되었습니다.
인쇄 할 수없는 문자 및 /P옵션
이 /P옵션을 사용하면 FINDSTR이 다음 10 진수 바이트 코드 (
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에서 중단됨 XP 및 Windows 7<LF>
에서 불쾌한 "기능"입니다. 리디렉션 된 입력으로 사용 된 파일의 마지막 문자가로 끝나지 않으면 <LF>FINDSTR은 한 번 무한정 중단됩니다. 리디렉션 된 파일의 끝에 도달합니다.
파이프 된 데이터의 마지막 행이 단일 문자로 구성된 경우 무시 될 수 있습니다
. 입력이 파이프되고 마지막 행이 뒤에 오지 않는 단일 문자로 구성된 <LF>경우 FINDSTR은 마지막 행을 완전히 무시합니다.
예-단일 문자가없고 첫 번째 명령이 <LF>일치 하지 않지만 두 문자가있는 두 번째 명령은 줄 바꿈으로 끝나는 문자가 하나 인 세 번째 명령과 마찬가지로 제대로 작동합니다.
> set /p "=x" <nul | findstr "^"
> set /p "=xx" <nul | findstr "^"
xx
> echo x| findstr "^"
x
새로운 findstr 버그 에서 DosTips 사용자 Sponge Belly가보고했습니다 . XP, Windows 7 및 Windows 8에서 확인되었습니다. 아직 Vista에 대해 들어 보지 못했습니다. 더 이상 Vista를 테스트 할 필요가 없습니다.
옵션 구문
옵션 중 하나를 접두사로 할 수 /또는 -
옵션은 단일 후 연결될 수 있습니다 /또는 -. 그러나 연결된 옵션 목록에는 OFF 또는 F :와 같은 하나 이상의 다중 문자 옵션이 포함될 수 있으며 다중 문자 옵션은 목록의 마지막 옵션이어야합니다.
다음은 순서대로 "hello"와 "bybye"를 모두 포함하는 라인에 대해 대소 문자를 구분하지 않는 정규식 검색을 표현하는 동등한 방법입니다.
/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.ERRORLEVEL 2에 오류가 발생합니다.
정규식 검색을 수행 할 때 최대 검색 문자열 길이는 254입니다. 길이가 255에서 511 사이 인 정규식 FINDSTR: Out of memory은 ERRORLEVEL 2에서 FINDSTR: Search string too long.오류를 발생시킵니다. 정규식 길이가> 511이면 오류가 발생합니다.
Windows XP에서는 검색 문자열 길이가 훨씬 짧습니다. Findstr 오류 : "검색 문자열이 너무 깁니다": "for"루프에서 하위 문자열을 추출하고 일치시키는 방법은 무엇입니까?
리터럴 검색과 정규식 검색 모두에서 XP 제한은 127 바이트입니다.
줄 길이 제한
명령 줄 인수 또는 / F : FILE 옵션을 통해 지정된 파일에는 알려진 줄 길이 제한이 없습니다. 단일 <LF>를 포함하지 않은 128MB 파일에 대해 검색이 성공적으로 실행되었습니다.
파이프 데이터 및 경로 재 지정 입력은 라인 당 8191 바이트로 제한됩니다. 이 한계는 FINDSTR의 "기능"입니다. 파이프 나 리디렉션에는 고유하지 않습니다. 경로 재 지정된 stdin 또는 파이프 입력을 사용하는 FINDSTR은> = 8k 바이트 인 라인과 절대 일치하지 않습니다. 행> = 8k는 stderr에 오류 메시지를 생성하지만, 검색 문자열이 하나 이상의 파일의 하나 이상의 행에있는 경우 ERRORLEVEL은 여전히 0입니다.
기본 검색 유형 : 리터럴 대 정규 표현식
/C:"string" -기본값은 / L 리터럴입니다. / L 옵션과 / C : "string"을 명시 적으로 결합하면 확실히 작동하지만 중복됩니다.
"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옵션 없음 ).
내가 본 모든 실패에서, 그것은 항상 실패하는 더 짧은 검색 문자열 중 하나입니다.
자세한 내용은 리터럴 검색 문자열이 여러 개인이 FINDSTR 예제가 일치하지 않는 이유는 무엇입니까?를 참조하십시오 .
명령 줄 인수 내 따옴표 및 백 슬래시
참고 -User MC ND의 의견은이 섹션에 대한 실제 끔찍한 규칙을 반영합니다. 다음과 같은 세 가지 고유 한 구문 분석 단계가 있습니다.
- 첫 번째 cmd.exe는 ^ "로 이스케이프되기 위해 따옴표가 필요할 수 있습니다 (실제로 FINDSTR과는 관련이 없음)
- 다음 FINDSTR은 2008 년 이전 MS C / C ++ 인수 구문 분석기 를 사용하며 "및 \
- 인수 구문 분석기가 완료된 후 FINDSTR은 추가로 \ 다음에 영숫자 문자를 리터럴로 취급하지만 \ 뒤에 영숫자가 아닌 문자가 이스케이프 문자로 취급합니다.
강조 표시된 섹션의 나머지 부분이 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 : file에 지정된 리터럴 검색 문자열 파일 내의 독립 따옴표 및 백 슬래시는 이스케이프 할 필요는 없지만 사용할 수는 있습니다.
"와 \"동일합니다.
\와 \\동일합니다.
의도가 \\를 찾으려면 적어도 선행 백 슬래시를 이스케이프해야합니다. 모두 \\\와 \\\\작동합니다.
의도 "\ 찾을 경우, 적어도 선두 백 슬래시 이스케이프해야합니다. 모두 \\"와 \\\"일을.
/ G : FILE 정규식 검색 문자열 내 이스케이프 따옴표 및 백 슬래시
이스케이프 시퀀스는 설명서에 따라 예상대로 작동하는 경우입니다. 인용 부호는 정규식 메타 문자가 아니므로 이스케이프 할 필요는 없습니다 (그러나 가능할 수는 있음). 백 슬래시는 정규식 메타 문자이므로 이스케이프해야합니다.
명령 행 매개 변수의 문자 한계-확장 ASCII 변환
널 문자 (0x00)는 명령 행의 문자열에 나타날 수 없습니다. 다른 단일 바이트 문자는 문자열 (0x01-0xFF)에 나타날 수 있습니다. 그러나 FINDSTR은 명령 행 매개 변수에서 찾은 많은 확장 ASCII 문자를 다른 문자로 변환합니다. 이것은 두 가지 방식으로 큰 영향을 미칩니다.
1) 많은 확장 ASCII 문자는 명령 행에서 검색 문자열로 사용될 경우 서로 일치하지 않습니다. 이 제한은 리터럴 검색과 정규식 검색에서 동일합니다. 검색 문자열에 확장 ASCII가 포함되어야하는 경우 /G:FILE옵션을 대신 사용해야합니다.
2) 이름에 확장 ASCII 문자가 포함되어 있고 파일 이름이 명령 행에 지정된 경우 FINDSTR이 파일을 찾지 못할 수 있습니다. 검색 할 파일에 이름에 확장 ASCII가 포함 된 경우 /F:FILE옵션을 대신 사용해야합니다.
다음은 FINDSTR이 명령 행 문자열에서 수행하는 확장 ASCII 문자 변환의 전체 목록입니다. 각 문자는 10 진수 바이트 코드 값으로 표시됩니다. 첫 번째 코드는 명령 줄에 제공된 문자를 나타내고 두 번째 코드는 변환 된 문자를 나타냅니다. 참고 –이 목록은 미국 컴퓨터에서 컴파일되었습니다. 다른 언어가이 목록에 어떤 영향을 줄지 모르겠습니다.
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>및 <를 포함하여 자체로 처리됩니다 LF>. 가장 쉬운 방법은 같은 이상한 문자를 포함 할 수 <CR>및 <LF>환경 변수로를 얻고 명령 행 인수 내에서 지연 확장을 사용하는 것입니다.
/ G : FILE 및 / F : FILE 옵션으로 지정된 파일에서 찾은 문자열의 문자 제한
nul (0x00) 문자는 파일에 나타날 수 있지만 C 문자열 종결 자처럼 작동합니다. 널 문자 뒤의 모든 문자는 마치 다른 행에있는 것처럼 다른 문자열로 처리됩니다.
<CR>와 <LF>문자는 문자열을 종료하고, 문자열에 포함되지 않은 라인 종결로 처리됩니다.
다른 모든 단일 바이트 문자는 문자열 내에 완벽하게 포함됩니다.
유니 코드 파일 검색
FINDSTR은 대부분의 유니 코드 (UTF-16, UTF-16LE, UTF-16BE, UTF-32)를 제대로 검색 할 수 없습니다. 유니 코드는 nul 바이트를 검색 할 수없고 일반적으로 많은 nul 바이트를 포함하기 때문입니다.
그러나 TYPE 명령은 BOM이있는 UTF-16LE을 단일 바이트 문자 세트로 변환하므로 다음과 같은 명령은 BOM이있는 UTF-16LE에서 작동합니다.
type unicode.txt|findstr "search"
활성 코드 페이지에서 지원하지 않는 유니 코드 코드 포인트는 ?문자 로 변환됩니다 .
검색 문자열에 ASCII 만 포함되어 있으면 UTF-8을 검색 할 수 있습니다. 그러나 멀티 바이트 UTF-8 문자의 콘솔 출력은 올바르지 않습니다. 그러나 출력을 파일로 리디렉션하면 결과가 UTF-8로 올바르게 인코딩됩니다. UTF-8 파일에 BOM이 포함되어 있으면 BOM이 첫 번째 행의 일부로 간주되어 행의 시작과 일치하는 검색을 중단 할 수 있습니다.
검색 문자열을 UTF-8 인코딩 검색 파일 (BOM없이)에 넣고 / G 옵션을 사용하면 멀티 바이트 UTF-8 문자를 검색 할 수 있습니다.
줄 끝
FINDSTR은 <LF>마다 줄을 즉시 끊습니다. <CR>의 유무는 줄 바꿈에 영향을 미치지 않습니다.
줄 바꿈 검색 검색
예상대로 .정규식 메타 문자는 <CR> 또는 <LF>와 일치하지 않습니다. 그러나 명령 줄 검색 문자열을 사용하여 줄 바꿈을 검색 할 수 있습니다. <CR> 및 <LF> 문자는 모두 명시 적으로 일치해야합니다. 여러 줄 일치가 발견되면 일치하는 첫 번째 줄만 인쇄됩니다. 그런 다음 FINDSTR은 소스의 두 번째 줄로 두 배로 돌아가서 "앞으로보기"유형 기능의 일종으로 검색을 다시 시작합니다.
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
<CR> 또는 <LF>와 일치하는 유일한 방법은 EOL 문자를 포함하는 정규식 문자 클래스 범위 표현식을 사용하는 것이므로 / G : FILE 옵션을 사용하여 줄 바꿈을 검색하는 것은 정확하지 않습니다.
[<TAB>-<0x0B>] <LF>와 일치하지만 <TAB> 및 <0x0B> 와도 일치
[<0x0C>-!] <CR>과 일치하지만 <0x0C>와!
참고-위의 문자는 그래픽으로 표현할 수 없기 때문에 정규식 바이트 스트림을 상징적으로 표현한 것입니다.
아래 2 부에서 답변이 계속되었습니다 ...
grep