정규식을 사용하여 HTML / XML을 구문 분석 할 수없는 이유 : 평신도 용어의 공식적인 설명

117

정규 표현식을 요청하는 (X) HTML 또는 XML 구문 분석에 대한 질문없이 지나가는 SO의 날은 없습니다.

이 작업에 대한 정규식의 실행 불가능 성을 보여주는 예제 또는 개념을 나타내는 표현 모음을 사용하는 것은 비교적 쉽지만 평신도에서 이것이 가능하지 않은 이유에 대한 공식적인 설명은 여전히 찾을 수 없습니다. 자귀.

내가 지금까지이 사이트에서 찾을 수있는 유일한 공식적인 설명은 아마도 매우 정확할 것입니다.

여기서 결함은 HTML이 Chomsky Type 2 문법 (문맥 자유 문법)이고 RegEx가 Chomsky Type 3 문법 (정규식)이라는 것입니다.

또는:

정규 표현식은 정규 언어와 만 일치 할 수 있지만 HTML은 컨텍스트가없는 언어입니다.

또는:

유한 오토 마톤 (정규 표현식의 기본이되는 데이터 구조)은 상태와 별도로 메모리를 갖지 않으며, 임의로 깊은 중첩이있는 경우 유한 오토 마톤의 개념과 충돌하는 임의의 큰 오토 마톤이 필요합니다.

또는:

정규 언어에 대한 펌핑 기본형은 그렇게 할 수없는 이유입니다.

[공평하게 말하면 : 위의 설명의 대부분은 위키피디아 페이지로 연결되지만 답변 자체보다 이해하기가 쉽지 않습니다.]

그래서 내 질문은 : 누군가가 (X) HTML / XML을 구문 분석하기 위해 정규식을 사용할 수없는 이유에 대한 위에 주어진 공식적인 설명에 대한 평신도의 용어로 번역을 제공 할 수 있습니까?

편집 : 첫 번째 답변을 읽은 후 명확히해야한다고 생각했습니다. 번역 하려는 개념을 간략하게 설명 하는 "번역"을 찾고 있습니다 . 답변이 끝나면 독자는 대략적인 아이디어를 가지고 있어야합니다. - "일반 언어"와 "문맥없는 문법"의 의미 ...

regex  language-agnostic 
— 맥
소스
19
컴퓨터 과학 용어에서 "정규식"은 현대의 "정규식 구현"(프로그래밍 언어에서 사용하는 도구 / API)과 크게 다르다는 사실에 유의하십시오. 후자는 그들이 만난 것을 "기억"할 수 있고 심지어 재귀 적으로 정의 된 (하위) 패턴과 일치시킬 수있어 이론적 인 "정규식"보다 훨씬 더 많이 일치 / 분석 / 인식 할 수 있습니다.
— Bart Kiers 2011
1
@Bart : 이건 정말에만 용어 "정규 표현식을 남용 언어에 적용 POSIX ERE 순전히 일반입니다..
— R ... GitHub의 STOP 돕기 ICE
2
@R .., 그래서 POSIX를 "현대 구현"이라고 부릅니다. : P. 진지하지만 : 예, 당신은 그 진정으로 옳은 것 입니다 일반. "... 현대의 많은 정규식 구현 ..." 또는 "... PCRE 정규식 구현 ..." 이라고 말 했어야합니다 .
— 바트 Kiers
4
나는 심각하게 복용 프로그래밍 언어 힘든 시간을 그 무지 프로그래머 ... 자신을 마케팅의 이익을 위해 근본적으로 잘못된 엄격한 언어
— R .. GitHub의 STOP 돕기 ICE
3
@R .., PCRE 구현이 "정규식"이라고 불리는 것은 안타깝지만 언어를 진지하게 받아들이지 않는 것은 IMO입니다. 내 말은, 당신은 Perl, Java, Python, Ruby, JavaScript, .NET 등을 진지하게 받아들이지 않습니까?
— Bart Kiers 2011

답변:

117

이것에 집중하십시오 :

유한 오토 마톤 (정규 표현식의 기본이되는 데이터 구조)은 상태와 별도로 메모리를 갖지 않으며, 임의로 깊은 중첩이있는 경우 유한 오토 마톤의 개념과 충돌하는 임의의 큰 오토 마톤이 필요합니다.

정규식 의 정의 는 문자열이 패턴과 일치하는지 여부에 대한 테스트가 유한 오토 마톤 (각 패턴에 대해 하나의 다른 오토 마톤)에 의해 수행 될 수 있다는 사실과 동일합니다. 유한 오토 마톤에는 메모리가 없습니다. 스택, 힙, 낙서 할 무한 테이프가 없습니다. 그것이 가진 것은 한정된 수의 내부 상태 뿐이며, 각각은 테스트중인 문자열에서 입력 단위를 읽고이를 사용하여 다음으로 이동할 상태를 결정할 수 있습니다. 특수한 경우에는 "예, 일치 함"및 "아니오, 일치하지 않음"의 두 가지 종료 상태가 있습니다.

반면 HTML은 임의로 깊이 중첩 될 수있는 구조를 가지고 있습니다. 파일이 유효한 HTML인지 확인하려면 모든 닫는 태그가 이전 여는 태그와 일치하는지 확인해야합니다. 이를 이해하려면 어떤 요소가 닫혀 있는지 알아야합니다. 당신이 본 여는 태그를 "기억"할 수단이 없으면 기회가 없습니다.

그러나 대부분의 "정규식"라이브러리는 실제로 정규식의 엄격한 정의 이상의 것을 허용합니다. 역 참조와 일치 할 수 있다면 일반 언어를 넘어선 것입니다. 따라서 HTML에서 정규식 라이브러리를 사용하지 않아야하는 이유는 HTML이 규칙적이지 않다는 단순한 사실보다 조금 더 복잡합니다.

— 스티브 제솝
소스
유한 상태 자동 장치에 대한 설명도 여기에 있습니다. youtube.com/watch?v=vhiiia1_hC4
— GDP2
55

HTML이 일반 언어를 나타내지 않는다는 사실은 붉은 청어입니다. 정규 표현과 정규 언어 는 비슷하게 들리지만 그렇지는 않습니다. 동일한 기원을 공유하지만 학문적 "정규 언어"와 현재 엔진의 일치 능력 사이에는 눈에 띄는 거리가 있습니다. 사실, 거의 모든 최신 정규식 엔진은 비정규 기능을 지원 (.*)\1합니다. 간단한 예는 . 역 참조를 사용하여 반복되는 문자 시퀀스 (예 123123: 또는) 를 일치 bonbon시킵니다. 재귀 / 균형 구조의 매칭은이를 더욱 재미있게 만듭니다.

Wikipedia는 Larry Wall 의 인용문에서 이것을 멋지게 표현했습니다 .

'정규식'[...]은 실제 정규식과 거의 관련이 없습니다. 그럼에도 불구하고이 용어는 패턴 매칭 엔진의 기능과 함께 성장했기 때문에 여기서는 언어 적 필요성에 맞서 싸우려고하지 않을 것입니다. 그러나 일반적으로 "정규식"(또는 앵글로색슨 분위기 일 때 "정규식")이라고 부를 것입니다.

보시다시피 "정규 표현식은 정규 언어와 만 일치 할 수 있습니다."는 일반적으로 언급되는 오류에 지나지 않습니다.

그럼 왜 안되죠?

HTML을 정규 표현식과 일치시키지 않는 좋은 이유는 "당신이 할 수 있다는 것을 의미하지는 않는다"는 것입니다. 가능할 수도 있지만 작업을위한 더 나은 도구가 있습니다. 고려하면:

  • 유효한 HTML은 생각보다 어렵거나 복잡합니다.
  • "유효한"HTML에는 여러 유형이 있습니다. 예를 들어, HTML에서 유효한 것은 XHTML에서는 유효하지 않습니다.
  • 인터넷에있는 대부분의 자유 형식 HTML은 어쨌든 유효하지 않습니다 . HTML 라이브러리는 이러한 문제를 잘 처리하고 이러한 일반적인 경우에 대해 테스트되었습니다.

  • 전체를 구문 분석하지 않고는 데이터의 일부를 일치시키는 것이 불가능한 경우가 많습니다. 예를 들어, 모든 제목을 찾고 주석 또는 문자열 리터럴 내에서 일치하게 될 수 있습니다. <h1>.*?</h1>주요 제목을 찾기위한 대담한 시도 일 수 있지만 다음을 찾을 수 있습니다.

    <!-- <h1>not the title!</h1> -->

    또는:

    <script>
var s = "Certainly <h1>not the title!</h1>";
</script>

마지막 요점이 가장 중요합니다.

  • 전용 HTML 파서를 사용하는 것이 당신이 생각할 수있는 어떤 정규식보다 낫습니다. 종종 XPath를 사용하면 필요한 데이터를 더 잘 표현할 수 있으며 HTML 파서를 사용하는 것이 대부분의 사람들이 생각하는 것보다 훨씬 쉽습니다 .

주제에 대한 좋은 요약과 Regex와 HTML을 혼합하는 것이 적절할 수있는 경우에 대한 중요한 의견은 Jeff Atwood의 블로그 인 Parsing Html The Cthulhu Way 에서 찾을 수 있습니다 .

HTML을 구문 분석하기 위해 정규 표현식을 사용하는 것이 더 좋은 때는 언제입니까?

대부분의 경우 라이브러리가 제공 할 수있는 DOM 구조에서 XPath를 사용하는 것이 좋습니다. 그럼에도 불구하고 대중의 의견에 반하여 파서 라이브러리가 아닌 정규식을 사용하도록 강력히 권장하는 몇 가지 경우가 있습니다.

다음과 같은 몇 가지 조건이 주어집니다.

  • HTML 파일의 일회성 업데이트가 필요하고 구조가 일관적임을 알고있는 경우.
  • 아주 작은 HTML 스 니펫이있을 때.
  • HTML 파일을 다루지 않지만 유사한 템플릿 엔진 (이 경우 파서를 찾기가 매우 어려울 수 있음)을 다룰 때.
  • HTML의 일부를 변경하고 싶지만 전부가 아닌 경우 -내가 아는 한 파서는이 요청에 응답 할 수 없습니다. 전체 문서를 구문 분석하고 전체 문서를 저장하여 변경하고 싶지 않은 부분을 변경합니다.
— Kobi
소스
4
이것은 HTML을 구문 분석하기 위해 정규식을 사용할 때 (사용하지 않을 때) 매우 명확하고 잘 작성된 부분이지만 내 질문에 대한 대답은 아닙니다. 대신 이 질문으로 옮기는 것이 좋습니다 . 나는 그것이 당신에게 더 많은 평판을 얻을 것이라고 생각하지만-무엇보다도-그것은 미래의 방문자가 더 관련성이 있다고 생각할 수있는 곳이 될 것이라고 생각합니다. 최신 정규식 엔진).
— mac
1
@mac-감사합니다. 사실, 나는 그것에 대해 약간의 생각을했다. 제가 귀하의 질문에 대답하지 않은 것을 알고 있지만 질문이 기본적으로 옳지 않다고 생각합니다. 잘못된 이유를 설명해달라고 요청합니다 ... 좋은 생각이 있습니다. 다른 질문이 더 적합 할 수도 있습니다 ...
— Kobi
19

HTML은 무제한 중첩을 가질 수 <tags><inside><tags and="<things><that><look></like></tags>"></inside></each></other>있고 정규식은 그것이 들어오고 나오는 것에 대한 기록을 추적 할 수 없기 때문에 실제로 대처할 수 없기 때문입니다.

난이도를 보여주는 간단한 구조 :

<body><div id="foo">Hi there!  <div id="bar">Bye!</div></div></body>

일반화 된 정규식 기반 추출 루틴의 99.9 %는 div의 닫는 태그에서 해당 div의 닫는 태그를 알 수 없기 때문에 divID가있는 내부의 모든 것을 올바르게 제공 foo할 수 없습니다 bar. 왜냐하면 그들은 "좋아, 나는 이제 두 div 중 두 번째 div로 내려 갔기 때문에 내가 본 다음 div 닫기는 나를 다시 가져오고 그 다음 div는 첫 번째 div에 대한 닫기 태그입니다"라고 말할 방법이 없기 때문입니다. . 프로그래머는 일반적으로 특정 상황에 대해 특수한 경우의 정규식을 고안하여 대응합니다. 그런 다음 내부에 더 많은 태그가 도입 되 자마자 중단되고 foo엄청난 비용과 시간과 좌절감으로 풀려야합니다. 이것이 사람들이 모든 것에 대해 화를내는 이유입니다.

— Ianus Chiaroscuro
소스
1
대답을 고맙게 생각하지만 내 질문은 "정규식을 사용할 수없는 이유 ..."가 아닙니다. 제 질문은 제가 제공 한 공식적인 설명을 "번역"하는 것입니다! :)
— mac
5
이것은 어떤 의미에서 이들 모두를 번역 한 것입니다. 가장 근사하게 "정규 표현식은 정규 언어와 일치 할 수 있지만 HTML은 컨텍스트가없는 언어입니다"와 유한 자동에 관한 것입니다. 정말 모두 같은 이유입니다.
— Ianus Chiaroscuro
죄송합니다. 질문이 명확하지 않을 수 있습니다 (개선을위한 제안을 환영합니다!). 그러나 "번역"을 설명하는 답변을 찾고 있습니다. 귀하의 답변은 '일반 언어'또는 '문맥없는 언어'개념을 명확하게하지 않습니다 ...
— mac
5
이러한 용어를 설명하는 것은 전문 용어 자체만큼이나 기술적이며, 모든 정밀 언어가 내포하는 실제 의미에서 산만해질 것입니다.
— Ianus Chiaroscuro
4
<(\w+)(?:\s+\w+="[^"]*")*>(?R)*</\1>|[\w\s!']+코드 샘플과 일치합니다.
— Kobi
9

정규 언어는 유한 상태 머신과 일치시킬 수있는 언어입니다.

(유한 상태 머신, 푸시 다운 머신 및 튜링 머신을 이해하는 것은 기본적으로 대학 4 년차 CS 과정의 커리큘럼입니다.)

문자열 "hi"를 인식하는 다음 기계를 고려하십시오. 

(Start) --Read h-->(A)--Read i-->(Succeed)
  \                  \
   \                  -- read any other value-->(Fail) 
    -- read any other value-->(Fail)

이것은 일반 언어를 인식하는 간단한 기계입니다. 괄호 안의 각 표현식은 상태이고 각 화살표는 전환입니다. 이와 같은 기계를 구축하면 입력 문자열을 정규 언어 (따라서 정규 표현식)에 대해 테스트 할 수 있습니다.

HTML을 사용하려면 현재 상태 이상의 것을 알아야합니다. 태그 중첩과 일치하려면 이전에 본 내용의 기록이 필요합니다. 머신에 스택을 추가하면이 작업을 수행 할 수 있지만 더 이상 "일반"이 아닙니다. 이것을 푸시 다운 기계라고하며 문법을 인식합니다.

— 션 맥밀런
소스
2
"유한 상태 머신, 푸시 다운 머신 및 튜링 머신을 이해하는 것은 기본적으로 300 레벨 CS 과정의 커리큘럼입니다." 나는 이것이 주제가 얼마나 어려운지 / 진보 된 것인지를 밝히기위한 시도라는 것을 이해합니다. 그러나 귀하가 언급하고있는 학교 시스템에 익숙하지 않습니다. 국가별로 구체적으로 설명해 주시겠습니까? 감사합니다! :)
— mac
1
업데이트했습니다. 이해하기가 너무 어렵다는 것을 모르겠습니다. 스택 오버플로 게시물에서 설명하기 만하면됩니다.
— Sean McMillan 2011
6

정규식은 한정된 (일반적으로 다소 작은) 수의 이산 상태를 가진 기계입니다.

임의의 언어 요소 중첩을 사용하여 XML, C 또는 기타 언어를 구문 분석하려면 얼마나 깊이 있는지 기억해야합니다. 즉, 중괄호 / 대괄호 / 태그를 셀 수 있어야합니다.

유한 한 기억으로는 셀 수 없습니다. 상태보다 중괄호 수준이 더 많을 수 있습니다! 중첩 수준 수를 제한하는 언어의 하위 집합을 구문 분석 할 수 있지만 매우 지루할 것입니다.

— 엔. '대명사'm.
소스
6

문법은 단어가 어디로 갈 수 있는지에 대한 공식적인 정의입니다. 예를 들어, 형용사는 명사 앞에오고 명사 in English grammar뒤에옵니다 en la gramática española. 문맥이 없다는 것은 문법이 모든 문맥에서 보편적으로 사용된다는 것을 의미합니다. 상황에 맞는 것은 특정 상황에 추가 규칙이 있음을 의미합니다.

C #에서, 예를 들어, using에서 뭔가 다른 의미 using System;보다는 파일의 상단에를 using (var sw = new StringWriter (...)). 더 관련성이 높은 예는 코드 내의 다음 코드입니다.

void Start ()
{
    string myCode = @"
    void Start()
    {
       Console.WriteLine (""x"");
    }
    ";
}
— 에이전트 -j
소스
이 이해할 수있는 대답이다
— 사람
그러나 컨텍스트 프리는 규칙적인 것을 의미하지 않습니다. 일치하는 paranthesis의 언어는 문맥이 없지만 규칙적이지 않습니다.
— Taemyr
추가해야 할 것은 정규 표현식 (Perl에있는 확장을 추가하지 않는 한)이 정규 문법 과 동일 하다는 것입니다. 즉, 임의적으로 깊이 균형이 잡힌 괄호 나 HTML 요소 열기 및 닫기 태그와 같이 임의로 깊이 중첩 된 구조를 설명 할 수 없습니다.
— reinierpost
4

컴퓨터 과학 이론과 전혀 관련이없는 XML 및 HTML을 구문 분석하는 데 정규식을 사용하지 않는 또 다른 실용적인 이유가 있습니다. 정규식이 끔찍하게 복잡하거나 잘못 될 것입니다.

예를 들어, 모두 일치하는 정규 표현식을 작성하는 것이 좋습니다.

<price>10.65</price>

그러나 코드가 정확하다면 :

  • 시작 및 끝 태그 모두에서 요소 이름 뒤에 공백을 허용해야합니다.

  • 문서가 네임 스페이스에있는 경우 모든 네임 스페이스 접두사를 사용할 수 있어야합니다.

  • 시작 태그에 나타나는 알 수없는 속성을 허용하고 무시해야합니다 (특정 어휘의 의미에 따라 다름).

  • 10 진수 값 앞뒤에 공백을 허용해야 할 수도 있습니다 (다시 말하지만 특정 XML 어휘의 세부 규칙에 따라 다름).

  • 요소처럼 보이지만 실제로는 주석 또는 CDATA 섹션에있는 것과 일치해서는 안됩니다 (악성 데이터가 파서를 속이려고 할 가능성이있는 경우 특히 중요합니다).

  • 입력이 유효하지 않은 경우 진단을 제공해야 할 수 있습니다.

물론이 중 일부는 적용하는 품질 표준에 따라 다릅니다. 특정 방식으로 작성해야하는 응용 프로그램에서 XML을 읽고 있기 때문에 특정 방식 (예 : 태그에 공백 없음)으로 XML을 생성해야하는 사람들과 함께 StackOverflow에서 많은 문제가 발생합니다. 코드의 수명이 긴 경우 코드를 테스트하는 하나의 샘플 입력 문서가 아니라 XML 표준이 허용하는 방식으로 작성된 들어오는 XML을 처리 할 수 ​​있어야합니다.

— 마이클 케이
소스
2

순전히 이론적 인 의미에서 정규식이 XML을 구문 분석하는 것은 불가능합니다. 이들은 이전 상태의 메모리를 허용하지 않는 방식으로 정의되어 임의 태그의 올바른 일치를 방지하며 중첩이 정규 표현식에 빌드되어야하므로 임의의 중첩 깊이까지 침투 할 수 없습니다.

그러나 최신 정규식 파서는 정확한 정의를 고수하는 것이 아니라 개발자에게 유용하도록 구축되었습니다. 따라서 이전 상태에 대한 지식을 활용하는 역 참조 및 재귀와 같은 것이 있습니다. 이를 사용하면 XML을 탐색, 유효성 검사 또는 구문 분석 할 수있는 정규식을 만드는 것이 매우 간단합니다.

예를 들어,

(?:
    <!\-\-[\S\s]*?\-\->
    |
    <([\w\-\.]+)[^>]*?
    (?:
        \/>
        |
        >
        (?:
            [^<]
            |
            (?R)
        )*
        <\/\1>
    )
)

그러면 적절하게 구성된 다음 XML 태그 또는 주석을 찾을 수 있으며 전체 내용이 적절하게 구성된 경우에만 찾을 수 있습니다. (이 표현식은 PCRE에 근접한 Boost C ++의 정규식 라이브러리를 사용하는 Notepad ++를 사용하여 테스트되었습니다.)

작동 방식은 다음과 같습니다.

  1. 첫 번째 청크는 주석과 일치합니다. 그렇지 않으면 중단을 유발할 수있는 주석 처리 된 코드를 처리 할 수 ​​있도록이 작업이 먼저 수행되어야합니다.
  2. 일치하지 않으면 태그의 시작 부분을 찾습니다. 이름을 캡처하기 위해 괄호를 사용합니다.
  3. 이 태그는으로 끝나서 태그 />를 완성하거나으로 끝납니다 >.이 경우 태그의 내용을 검사하여 계속됩니다.
  4. 그것은이 도달 할 때까지 구문 분석을 계속 <하는 것이 코멘트 나 새 태그 중 하나를 처리 할 수는 식의 시작으로 다시 재귀 가리 킵니다.
  5. 텍스트의 끝에 도달하거나 <구문 분석 할 수없는에 도달 할 때까지 루프를 통해 계속됩니다 . 물론 일치하지 않으면 프로세스가 다시 시작됩니다. 그렇지 않으면 <이 반복에 대한 닫는 태그의 시작일 가능성이 높습니다. 닫는 태그 내부의 역 참조를 사용하면 <\/\1>현재 반복 (깊이)의 여는 태그와 일치합니다. 캡처 그룹이 하나뿐이므로이 경기는 간단합니다. 이렇게하면 필요한 경우 특정 태그 만 캡처하도록 캡처 그룹을 수정할 수 있지만 사용 된 태그의 이름과는 독립적입니다.
  6. 이 시점에서 현재 재귀에서 다음 레벨까지 킥 아웃하거나 매치로 끝납니다.

이 예제는 단순히 <또는을 부정하는 문자 그룹을 사용 하거나 >주석의 경우 한 [\S\s]줄에서도 캐리지 리턴 및 새 줄을 포함한 모든 항목과 일치하는 을 사용하여 공백을 처리하거나 관련 콘텐츠를 식별하는 문제를 해결 합니다. 모드에 도달 할 때까지 계속 -->됩니다. 따라서 의미있는 것에 도달 할 때까지 모든 것을 유효한 것으로 취급합니다.

대부분의 경우 이와 같은 정규식은 특별히 유용하지 않습니다. XML이 적절하게 형성되었는지 확인하지만 이것이 실제로 수행 할 전부이며 속성을 고려하지 않습니다 (쉽게 추가 할 수 있음). 태그 이름의 정의뿐만 아니라 이와 같은 실제 문제를 배제하기 때문에 이렇게 간단합니다. 실제 사용에 적합하면 훨씬 더 짐승이 될 것입니다. 일반적으로 진정한 XML 파서는 훨씬 우수합니다. 이것은 아마도 재귀가 어떻게 작동하는지 가르치는 데 가장 적합 할 것입니다.

간단히 말해서, 실제 작업에는 XML 파서를 사용하고 정규식을 가지고 놀려면 이것을 사용하십시오.

— buchWyrm
소스
3
이 정규식은 입력이 올바른 형식 인 경우에만 일치한다는 설명이 올바르지 않습니다. 이름이 유효한 XML 이름인지 확인하지 않고 속성을 확인하지 않으며 엔티티 및 문자 참조를 확인하지 않으며 CDATA 또는 처리 명령을 처리하지 않습니다. 당신이 그것이 테스트되었다고 말할 때, 나는 그것이 XML 적합성 테스트 스위트와 유사한 모든 것에 대해 테스트되었음을 ​​매우 의심합니다. 그것이 내가 본 정규식을 사용하여 XML을 처리하려는 모든 시도의 문제입니다. 이들은 적은 수의 입력으로 작동하지만 합법적으로 애플리케이션에 전달할 수있는 XML에서는 작동하지 않습니다.
— Michael Kay
2
또한 정규식이 일치하지 않는 올바른 형식의 입력이 있습니다. 예를 들어 끝 태그의 이름 뒤에 공백을 허용하지 않습니다. 이러한 결함의 대부분은 쉽게 수정되지만 모든 결함을 수정하면 완전히 사용할 수없는 문제가 발생합니다. 그리고 물론 진짜 문제는 파서가 예 / 아니오 대답을 제공하는 것이 아니라 유용한 정보를 제공하는 응용 프로그램에 정보를 전달하기를 원한다는 것입니다.
— Michael Kay
0

정규식으로 XML / HTML을 구문 분석하지 말고 적절한 XML / HTML 구문 분석기를 사용하고 강력한 xpath 질문.

이론 :

컴파일 이론에 따르면 XML / HTML은 유한 상태 머신을 기반으로하는 정규식을 사용하여 구문 분석 할 수 없습니다 . XML / HTML의 계층 적 구성으로 인해 푸시 다운 자동화 를 사용하고 YACC 와 같은 도구를 사용하여 LALR 문법을 조작 해야합니다 .

realLife © ® ™ 일상적인 도구 껍질 :

다음 중 하나를 사용할 수 있습니다.

xmllint는 종종 libxml2, xpath1 과 함께 기본적으로 설치됩니다 (줄 바꿈으로 구분 된 출력이 있는지 내 래퍼 를 확인하십시오.

xmlstarlet 은 편집, 선택, 변환 가능 ... 기본적으로 설치되지 않음, xpath1

perl의 모듈 XML :: XPath, xpath1을 통해 설치된 xpath

xidel xpath3

saxon-lint 내 프로젝트, @Michael Kay의 Saxon-HE Java 라이브러리 xpath3에 대한 래퍼

또는 높은 수준의 언어와 적절한 라이브러리를 사용할 수 있습니다.

파이썬의 lxml( from lxml import etree)

펄의 XML::LibXML, XML::XPath, XML::Twig::XPath,HTML::TreeBuilder::XPath

루비 노코 기리, 이 예를 확인하십시오.

PHP DOMXpath, 이 예를 확인하십시오.

확인 : HTML 태그에 정규식 사용

— Gilles Quenot
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.