효율 적 인 정규 표현 식 기법 총 결 을 작성 하 다.

만약 에 순 전 히 자신의 정규 수준 에 도전 하기 위해 일부 효 과 를 실현 하 는 데 사용 된다(예 를 들 어 정규 표현 식 으로 질 수 를 계산 하고 선형 방정식 을 푸 는 것).효율 은 문제 가 되 지 않 는 다.만약 에 쓴 정규 표현 식 이 한두 번,몇 십 번 의 운행 을 만족 시 키 기 위해 서 라면 최적화 여부 의 차이 도 크 지 않다.그러나 정규 표현 식 이 백만 번,천만 번 실 행 될 경우 효율 이 큰 문제 다.
 행 문의 편 의 를 위해 먼저 두 개념 을 정의 하 다.
오류 일치:정규 표현 식 과 일치 하 는 내용 의 범 위 는 필요 한 범 위 를 넘 어 섰 습 니 다.일부 텍스트 는 요구 에 부합 되 지 않 지만 쓴 정규 식 에 맞 았 습 니 다.예 를 들 어\d{11}을 사용 하여 11 자리 핸드폰 번호 와 일치 하면\d{11}은 정확 한 핸드폰 번호 만 일치 하 는 것 이 아니 라 98765432100 과 같은 핸드폰 번호 가 아 닌 문자열 도 일치 합 니 다.우 리 는 이러한 매 칭 을 오 매 칭 이 라 고 부른다.
누락 일치:정규 표현 식 이 일치 하 는 내용 에 규정된 범위 가 너무 좁 고 일부 텍스트 는 확실히 필요 하지만 쓴 정규 표현 식 은 이러한 상황 을 포함 하지 않 았 습 니 다.예 를 들 어 18 자리 주민등록번호 와 일치 하 는\d{18}을 사용 하면 끝 이 알파벳 X 인 경우 가 빠 집 니 다.
정규 표현 식 을 쓰 면 오류 만 발생 할 수 있 습 니 다.예 를 들 어,\w+\.com 을 사용 하여.com 의 끝 에 있 는 도 메 인 이름 을 일치 시 키 면 abc 와 잘못 일치 할 수 있 습 니 다.com 과 같은 문자열(합 법 적 인 도 메 인 이름 에는 밑줄 이 포함 되 어 있 지 않 습 니 다.\w 는 밑줄 이 포함 되 어 있 습 니 다.)ab-c.com 과 같은 도 메 인 이름(합 법 적 인 도 메 인 이름 에는 밑줄 이 포함 되 어 있 지만\w 는 밑줄 이 일치 하지 않 습 니 다)을 빠 뜨 립 니 다.
정확 한 정규 표현 식 은 오류 없 이 일치 하고 누락 없 이 일치 하 는 것 을 의미 합 니 다.물론 현실 에 서 는 제 한 된 수량의 텍스트 만 볼 수 있 고 이 텍스트 에 따라 규칙 을 쓰 지만 이 규칙 들 은 대량의 텍스트 에 사 용 될 것 이다.이런 상황 에서 가능 한 한(완전히 그렇지 않 으 면)오 매 칭 과 누 출 매 칭 을 없 애고 운행 효율 을 높이 는 것 이 우리 의 목표 이다.본 논문 에서 제기 한 경험 은 주로 이런 상황 을 겨냥 한 것 이다.
문법의 세부 사항 을 파악 하 다.정규 표현 식 은 각종 언어 에서 문법 이 대체적으로 같 고 세부 적 인 부분 은 각각 천추 가 있다.사용 하 는 언어의 정규 문법 디 테 일 을 명 확 히 하 는 것 은 정확 하고 효율 적 인 정규 표현 식 을 쓰 는 기초 이다.예 를 들 어 perl 에서\w 와 같은 효 과 를 가 진 일치 범 위 는[a-zA-Z0-9]이다.perl 정규 식 은 긍정 적 인 역순 환시 에서 가 변 적 인 중복 을 사용 하 는 것 을 지원 하지 않 습 니 다(variable repetition inside lookbehind,예 를 들 어(?<=.*)abc),그러나.Net 문법 은 이러한 특성 을 지원 합 니 다.또,JavaScript 연속 역순 으로 둘 러 보기(Lookback,예 를 들 어(?<=)ab)c)는 지원 하지 않 습 니 다.perl 과 python 은 지원 합 니 다.정규 표현 식 에 정통 하 다 제3 장 에 서 는 각 파벌 정규 의 공통점 과 차이 점 을 명확 하 게 보 여 주 었 고 이 글 은 몇 가지 상용 언어,도구 중의 정규 비 교 를 간략하게 보 여 주 었 다.구체 적 인 사용자 에 게 는 적어도 사용 하고 있 는 업무 언어 에서 정규 적 인 문법 디 테 일 을 자세히 알 아야 한다.
먼저 굵게 한 다음 에 정교 하 게 하고,먼저 더 한 다음 에 줄이다.정규 표현 식 문법 을 사용 하여 목표 텍스트 에 대해 설명 하고 정 의 를 내 릴 수 있 습 니 다.스케치 처럼 먼저 프레임 워 크 를 대체적으로 그 려 낸 다음 에 국 보 에서 디 테 일 을 점차적으로 실현 할 수 있 습 니 다.아까 핸드폰 번호 의 예 를 들 어\d{11}을 먼저 정 하면 틀 리 지 않 습 니 다.다시 1[358]\d{9}로 세분 화하 면 큰 걸음 을 내 디 뎠 다.이렇게 하 는 목적 은 먼저 누락 된 매 칭 을 없 애 는 것 이다.이렇게 하면 먼저 있 고 나중에 생각 할 때 실수 하기 쉬 우 며'실수 하지 않 고 빠 뜨리 지 않 는 다'는 목 표를 향 해 매진 할 수 있다.
여 지 를 남기다.볼 수 있 는 텍스트 sample 은 제한 되 어 있 으 며,일치 하 는 검 사 를 기다 리 는 텍스트 는 대량의 것 으로 잠시 보이 지 않 습 니 다.이러한 상황 에 대해 정규 표현 식 을 쓸 때 볼 수 있 는 텍스트 의 범 위 를 벗 어 나 생각 을 개척 하고'전략 적 전망'을 해 야 한다.예 를 들 어 이런 스 팸 메 시 지 를 자주 받는다.'발*표','발\#표류'이다.이런 귀 찮 은 스 팸 메 시 지 를 차단 하 는 규칙 을 쓰 려 면 현재 텍스트 와 일치 하 는 정규 표현 식 을 쓸 수 있 을 뿐만 아니 라[*\#](?:표|표류),그리고 발송 도 생각 할 수 있 습 니 다.(?:표|표류|표류)와 같은 발생 할 수 있 는 변종.구체 적 인 분야 에 서 는 맞 춤 형 규칙 이 있 을 지도 모른다.이렇게 하 는 목적 은 누락 된 매 칭 을 없 애고 정규 표현 식 의 생명 주 기 를 연장 하 는 것 이다.
명확 하 다.구체 적 으로 말 하면 점 과 같은 원 문 자 를 신중하게 사용 하고 가능 한 한 별표 와 플러스 와 같은 임 의 양 어 를 사용 하지 않 는 다 는 것 이다.범 위 를 정할 수만 있다 면,예 를 들 어\w 는 점 호 를 사용 하지 마 세 요.중복 횟수 를 예측 할 수 있 는 한 임 의 양 어 를 쓰 지 마라.예 를 들 어 트 위 터 메 시 지 를 분석 하 는 스 크 립 트 를 작성 하고 메시지 의 xml 본문 부분 구 조 를볏짚 이 낙타 를 눌 러 죽 이지 못 하 게 해라.포획 형 괄호 가 아 닌 일반 괄호()를 사용 할 때마다(?:...),다시 접근 할 때 까지 메모리 의 일 부 를 남 겨 두 겠 습 니 다.이러한 정규 표현 식,무한 운행 횟수 는 볏짚 더미 와 다 름 없 이 낙타 를 눌 러 죽 일 수 있 습 니 다.육성 합 리 적 사용(?:...)괄호 넣 는 버릇.
간소화 할지언정 번잡 하지 마라.복잡 한 정규 표현 식 을 두 개 이상 의 간단 한 정규 표현 식 으로 나 누 면 프로 그래 밍 난이도 가 낮 아 지고 운행 효율 이 향상 된다.예 를 들 어 줄 의 첫머리 와 줄 끝의 공백 문 자 를 없 애 는 정규 표현 식 s/^\s+|\s+$/g;그 운행 효율 은 이론 적 으로 s/^\s+/g 보다 낮다.s/\s+$//g; 。이 예 는 제5 장 에서 나 온 것 으로 책 에서 그것 에 대한 평론 은'그것 은 거의 항상 가장 빠 르 고 이해 하기 쉽다'는 것 이다.빠 르 고 이해 하기 쉬 운 데,왜 기꺼이 하지 않 겠 는가?작업 중 에 우 리 는 C==(A|B)와 같은 정규 표현 식 을 A 와 B 두 표현 식 으로 나 누 어 각각 실행 해 야 하 는 다른 이유 가 있 습 니 다.예 를 들 어 A 와 B 라 는 두 가지 상황 이 필요 한 텍스트 모드 를 맞 출 수 있 으 면 성공 적 으로 일치 하지만 하나의 하위 표현 식(예 를 들 어 A)만 있 으 면 다른 하위 표현 식(예 를 들 어 B)의 효율 이 아무리 높 고 범위 가 아무리 정확 하 더 라 도 C 의 전체적인 정확도 도 A 로 인해 영향 을 받 을 수 있다.
교묘 하 게 포 지 셔 닝 하 다.때때로,우리 가 일치 해 야 하 는 the 는 단어의 the(양쪽 에 빈 칸 이 있 음)이지,단어의 일부분 인 t-h-e 의 질서정연 한 배열(예 를 들 어 together 의 the)이 아니다.적당 한 시기 에^,$,\b 등 포 지 셔 닝 닻 점 을 사용 하면 성공 적 인 매 칭,탈락 에 성공 하지 못 한 효율 을 효과적으로 향상 시 킬 수 있 습 니 다.
이상 은 정규 표현 식 의 운영 효율 을 향상 시 킨 경험(업무 에서 배 운 것,책 을 읽 고 배 운 것,자신의 경험)을 정리 한 것 입 니 다.만약 당신 이 다른 경험 이 있 는데 여기에 언급 되 지 않 았 다 면 토론 을 환영 합 니 다.