2017-03-18 1 views
1

Markdown과 유사한 문법을 ​​사용하는 파서를 구축 중이며 현재 굵은 글꼴 및 기울임 꼴 텍스트 범위에 대한 강력한 지원을 구현하는 데 어려움을 겪고 있습니다.Markdown 형식의 구문에서 굵은 기울임 꼴 문자 범위를 렉싱하기위한 lookbehind 및 lookahead를 구현하는 방법은 무엇입니까?

(?<=^|[^\w\d\*])\*\*(?!$|\*|\s) 

긍정적 인 lookbehind 검사 : 나는 (표현이 아톰 편집기에 대한 강조 마크 다운 문법에서 가져온 것입니다)를 ANTLR4 렉서 구문에 대담한 범위의 시작을 위해 다음과 같은 정규 표현식을 "번역"싶습니다 "**"문자열이 문자열의 시작 부분에 있거나 단어, 숫자 또는 다른 별표가없는 경우. 네거티브 미리보기는 시퀀스가 ​​문자열의 끝 부분이 아니라 다른 별표 또는 공백 문자 뒤에 오는 지 확인합니다.

나는 이미 나는이 같은 일 (_input.LA (1) 사용) 예상 검색을 할 ANTLR4에 의미 술어를 사용한다는 것을 배웠다 있습니다

ASTERISK_BOLD_START 
     : { /*Lookbehind checks*/}? '**' {/*Lookahead checks with _input.LA(1)*/}? 
     ; 

을하지만이 lookbehind을 구현 어떻게 체크 무늬? 그리고 어떻게 파싱 된 전체 문자열의 시작이나 끝을 검사 할 수 있습니까?

답변

0

파서 문법을 만들 때 정규 표현식을 사용하지 마십시오. 두 기술 모두 다르게 작동하며 잘못된 방향으로 쉽게 이동할 수 있습니다. 뒤에 많은 모습을 보이고 앞을 내다 보는 당신의 생각은 잘못된 방향입니다. 일반 (복잡한) 정규 표현식에는 일반적이지만 일반 파서는 아닙니다. 대신 다른 문법 작성자가 작성한 것을 살펴보십시오. one grammar here at SO이 있고 Antmark over there at Github이 있습니다. EBNF for Markdown을 시작으로 문법을 만들 수도 있습니다.

그러나 몇 가지 문제가 발생하면 사전 처리하십시오. Markdown은 문맥 자유 문법이 아니므로 구문 분석하기가 어렵습니다. 블로그 게시 Why isn't there a formal grammar for Markdown?에서 몇 가지 세부 사항을 설명합니다.

+0

귀하의 조언에 감사드립니다. 나는 이미이 두 가지 구현을 알고 있었다. Stackoverflow에있는 것은 이탤릭체 범위 내의 Markdown을 무시합니다 (그리고 굵은 범위를 전혀 구현하지 않습니다). Github에있는 사람은 저자가 "사용할 수 없으며" "추한"이라고합니다. 구문 분석기에서 모든 문맥에 민감한 내용을 처리하여 구문 분석기를 느리고 복잡하게 만듭니다. 컨텍스트 감도로 인해 의미 론적 술어를 사용하는 방법이 없다고 생각합니다. 이것은 가장 우아한 방법은 아니지만, 느슨한 Markdown 문법에 적합하다고 생각합니다. –

관련 문제