2016-07-01 10 views
0

사양을 쓰고 있는데 EBNF를 모르겠습니다. 나는 다음과 같은 PCRE 있습니다PCRE를 EBNF로 변환하려면 어떻게해야합니까?

  • $$ 이스케이프 $입니다 : 입력에,

    ^(?:\$(?:\$|{\d+})|[^$])*$ 
    

    .

  • ${num}은 인수 번호입니다.
  • 다른 모든 것은 (즉, $이 아닙니다.) 리터럴입니다.
  • $ 다음에 $ 또는 {num}이 오지 않는 것은 오류입니다.

그리고 EBNF로 변환해야합니다. 이 PCRE를 EBNF로 어떻게 변환합니까?

은 (내가 PCRE에 EBNF에서 예정에 대해 많은 질문이 발견,하지만 난 다른 방법으로 주위가는 대해 어떤을 보지 못했다)

+0

정규 표현식에서'.'를'$ '와 일치 시키려고합니까? (그렇다면'$ a $ 42' 문자열이 받아 들여질 수 있겠습니까?) (그렇다면 어휘 적으로'. *'와 동등합니다.) – rici

+0

@rici 그럴 수도 있고 오류가 될 수도 있습니다. 이 특정 유스 케이스의 경우,'.'는'[^ $]'이 아니라'.'이어야합니다. – SoniEx2

+0

'.'을 실제로 의미하는 경우, 의미 구조가 아닌 문법은'. *'에 의해 정확하게 기술됩니다. EBNF에서는'{임의의 문자}'와 같을 것입니다. 하지만 실제로는 의미 구문 분석을 설명하기를 원할 것입니다.이 경우 명백한 문법을 ​​만들기 위해 일부 농구를 뛰어 넘을 필요가 있습니다. 아니면 그냥 느슨한 달러 기호를 오류로 거부 할 수 있습니다 :) – rici

답변

1

두 가지가 복잡이 명백하게 간단한 질문에 대답합니다

  1. "EBNF"라는 용어는 다양한 형태로 나타납니다. "Extended BNF"에 대해서는 ISO 표준 ISO/IEC 14977:1996이 있지만, 아는 한 실제로는 거의 사용되지 않습니다. (참고 : 해당 페이지에서 무료 다운로드 링크가 제공되며 은 필요하지 않음이 필요합니다.) 많은 인터넷 프로토콜은 RFC 5234에 정의 된대로 "Augmented BNF"를 사용합니다. 이는 아마도 특정 문제에 더 잘 맞을 것입니다. 그리고 BNF를 여러 가지 방식으로 확장하는 파서 생성기가 많이 있습니다. 일반적으로 정규 표현식과 같은 반복 및 옵션 연산자를 추가하여 표준화하지는 않습니다. 실제로 ISO가 표준을 만들도록 동기를 부여한 것은 가능한 정의의 혼돈 이었지만 ISO 표준의 경우처럼 자유 텍스트 액세스가 부족한 경우 (릴리스 이후 10 년까지) 및 자유롭게 사용할 수있는 경우 도구는 채택을 방해.)

  2. 정규 표현식은 반드시 명확한 문법을 ​​생성하지 않으며, $는 일반 문자로 사용이 허용되어 있기 때문에 사용자가 제공하는 정규 표현식이 모호합니다. 이 의미는 ($) 다른 문자가 $이거나 중괄호로 묶인 숫자 인 경우 일반 문자로 처리 할 수는 없지만 정규 표현식 자체는 정규 문자로 취급되지 않을 수도 있음을 의미합니다. (그럴 필요도 없다). 여기에, 어쨌든

    ${42 looks like an error to me but it would be accepted by the regex. 
    

언어 비슷한에 대한 ISO EBNF입니다 : 덜 명백한 의도가 같은 문자열이 될 수있는 것입니다. 이 아님을 유의하십시오.은 위의 문자열을 허용합니다. 전체에

(* EBNF does not have wildcard characters and there is no way to 
    enumerate all possible characters, so I use the exception mechanism 
    to describe the set 
*) 
any character 
    = ? Any character representable by the source character encoding ? ; 
decimal digit 
    = '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'; 
literal sequence 
    = {any character} - 
     ({any character}, ('$$' | '${'), {any character}) ; 
escaped dollar 
    = '$$' ; 
parameter 
    = '${', decimal digit, {decimal digit}, '}'; 
thingamajig 
    = {literal sequence | escaped dollar | parameter} 

, 당신은 달러 기호를 탈출하는 메커니즘을 제공하기 때문에, 아마 느슨한 달러 기호의 사용을 금지하는 것이 더 간단 할 것이다. 이는 명세와 파서를 더 단순하게 만들고, 비표준적인 표현의 문제를 피한다.(비표준적인 표현은 보안상의 문제가 될 수 있습니다. 왜냐하면 문자열을 내부 표현으로 다시 왕복하면 지문 유효성 검사가 실패 할 수 있고 정보 유출을 허용하기 때문입니다.이 경우 중요한 것은 아니지만 일반적으로 모범 사례에서 그렇습니다 데이터 교환 프로토콜은 가능한 경우 비표준 표현을 피하는 것입니다.)