x 바이트 수를 찾아서 아무것도 바꾸지 않는 notepad++의 정규 표현식을 찾는 데 어려움을 겪고 있습니다. 캐리지 리턴(0D) 카운트, 라인 피드 카운트(0A).
이것은 내가 시도하는 정규식입니다. (0C가 시작이고 0C와 함께 0C 이후 318바이트를 제거합니다.)
\x0C(.{318})
이 정규식은 아무것도 찾지 못하고 일치 항목을 찾을 수 없다고 표시됩니다. 찾을 수 \x0C있고 찾을 수 있지만 .찾을 수 없습니다. .{318}또한 .0x0A 및 0x0D를 건너뜁니다.
-랩 어라운드가 확인되었습니다.
-정규식을 검사합니다.
다음은 ASCII가 포함된 16진수 파일의 일부입니다.
0C 30 31 32 27 34 35 36 0D 0A 30 61 32 0D 33 34 0A [snip] 0C 32 0A 0D 35 [etc..]
<ff>0 1 2 ' 4 5 6<cr><lf>0 a 2<cr> 3 4<lf>[snip]<ff> 2<lf><cr>5 [etc..]
답변1
인코딩이 us-ascii라고 언급했으므로 각 문자가 1바이트라고 가정할 수 있습니다. 정규식에서는 '.' 줄 바꿈을 제외한 모든 문자와 일치하며 CR/LF 줄 바꿈의 각 개별 부분이 2바이트이므로 별도로 일치되기를 원합니다.
또한 us-ascii 문자 매핑 외부의 바이트를 포함할 수 있는 바이너리 파일이 아니라 실제 텍스트 데이터를 처리하고 있다고 가정하겠습니다.
위의 사항이 모두 해당되면 다음 정규식을 사용할 수 있습니다.
\x0C[^\xFF]{318}
이유는 '.' 귀하의 시도가 작동하지 않았습니다. '.' 개행 문자와 일치하지 않습니다. 또한 \x0C[.\r\n]{318}'.' 때문에 사용할 수 없습니다 . 문자 클래스(대괄호 그룹) 내에서는 와일드카드를 사용할 수 없습니다. 16진수 값 FF는 us-ascii 문자 집합 내의 유효한 코드 포인트에 매핑되지 않으므로 "FF 문자가 아닌 모든 문자"를 찾을 때바이트생각 해 보겠다.
이 방법은 windows/mac 줄 바꿈을 요청에 따라 2문자/바이트로 계산한다는 점을 명심하세요.
이것이 당신이 찾고 있던 것이기를 바랍니다 ...
편집 - 정규식 설명
완전한 표현
\x0C[^\xFF]{318}
이것을 분석해보자.
\x0C
이는 단일 유니코드 문자소와 일치합니다. 이에 대한 자세한 정보를 찾을 수 있습니다.여기. 요약하면, \x를 점의 유니코드 버전으로 간주할 수 있습니다.줄 바꿈과도 일치할 수 있습니다.(이것은 중요합니다. 이에 대해서는 나중에 자세히 설명합니다.)
하지만 이것도 사용해 보셨으니 이미 어느 정도 익숙하실 거라 생각됩니다.
[^\xFF]
[] 사이의 모든 것을문자 세트(문자 인코딩의 동일한 개념과 혼동하지 마십시오). 이에 대한 자세한 내용은 Regexp Tutorial에서 읽을 수 있지만 요약하면 "OR" 문 역할을 합니다. [ab]는 단순히 "a 또는 b"를 의미합니다. ^가 문자 집합 내에서 사용되면 부정 역할을 합니다. 따라서 [^a]는 "a가 아님"을 의미합니다. 사용 사례에서는 HEX 값 FF가 아닌 문자를 찾습니다.
{318}
그리고 우리는 이런 인물을 318번이나 찾습니다. {} 구문은 항상 바로 앞에 있는 Regex 요소에 적용됩니다. 따라서 이 경우에는 [^\xFF] 문자 세트입니다.
왜 \xFF인가?
16진수 표기법에서 us-ascii 문자 집합은 다음과 같습니다.00에서 7E까지. 더 높은 값은 us-ascii 코드 포인트에 매핑될 수 없습니다. 즉, us-ascii로 (올바르게) 인코딩된 모든 파일에는 00에서 7E 사이의 HEX 값만 포함될 수 있습니다. 결과적으로 FF를 포함할 수 없습니다.
따라서 \x..도 \x0A 및 \x0C와 같은 줄바꿈과 일치하므로 이를 교묘하게 활용하여 개행 문자를 포함한 모든 문자를 검색할 수 있습니다. 어떤 문자를 검색하면~ 아니다FF, 우리는 결국 찾게 된다모든성격.
이 솔루션은 파일이 UTF-8이 아닌 us-ascii로 인코딩되어 있다는 사실에 따라 달라집니다.