etc./StackOverFlow

RegEx는 XHTML 자체 포함 태그를 제외한 열린 태그와 일치합니다.

청렴결백한 만능 재주꾼 2021. 12. 31. 03:32
반응형

질문자 :Community Wiki


이 시작 태그를 모두 일치시켜야 합니다.

 <p> <a href="foo">

그러나 다음은 아닙니다.

 <br /> <hr class="foo" />

나는 이것을 생각해 냈고 내가 올바르게 이해하고 있는지 확인하고 싶었습니다. az 만 캡처하고 있습니다.

 <([az]+) *[^/]*?>

나는 그것이 말한다 :

  • 다음보다 작은 것을 찾으십시오.
  • az를 한 번 이상 찾아서 캡처한 다음
  • 0개 이상의 공백을 찾은 다음
  • / 제외하고 탐욕스러운 문자를 0번 이상 찾은 다음
  • 보다 큰 찾기

나에게 그런 권리가 있습니까? 그리고 더 중요한 것은 어떻게 생각하세요?



정규식으로 [X]HTML을 구문 분석할 수 없습니다. HTML은 정규식으로 구문 분석할 수 없기 때문입니다. Regex는 HTML을 올바르게 구문 분석하는 데 사용할 수 있는 도구가 아닙니다. 이전에 HTML 및 정규식 질문에서 여러 번 답변한 것처럼 정규식을 사용하면 HTML을 사용할 수 없습니다. 정규식은 HTML에서 사용하는 구성을 이해하기에는 충분히 정교하지 않은 도구입니다. HTML은 정규 언어가 아니므로 정규 표현식으로 구문 분석할 수 없습니다. 정규식 쿼리는 HTML을 의미 있는 부분으로 분해할 수 없습니다. 여러 번하지만 그것은 나에게 도달하지 않습니다. Perl에서 사용하는 향상된 불규칙 정규식조차도 HTML 구문 분석 작업에 해당하지 않습니다. 당신은 절대 날 깨게 만들지 않을 것입니다. HTML은 정규 표현식으로 구문 분석할 수 없을 정도로 복잡한 언어입니다. Jon Skeet조차도 정규식을 사용하여 HTML을 구문 분석할 수 없습니다. 정규 표현식으로 HTML을 구문 분석하려고 할 때마다 부정한 아이는 처녀의 피를 흘리고 러시아 해커는 웹 앱을 pwn합니다. 정규식으로 HTML을 구문 분석하면 오염된 영혼을 살아있는 영역으로 소환합니다. HTML과 정규식은 사랑, 결혼, 영아 살해 의식처럼 함께 갑니다. <center>는(는) 너무 늦으면 안 됩니다. 동일한 개념 공간에서 정규식과 HTML을 함께 사용하면 너무 많은 물 같은 퍼티처럼 당신의 마음을 파괴할 것입니다. HTML을 정규식으로 구문 분석하면 기본 다국어 평면에서 이름을 표현할 수 없는 분을 위해 우리 모두를 비인간적인 수고로 파멸시키는 그들의 신성모독적인 방식에 굴복하고 있습니다. HTML-plus-regexp는 당신이 관찰하는 동안 지각 있는 신경을 액화시킬 것입니다. 당신의 정신은 공포의 맹공격에 시들어갑니다. 정규식 기반의 HTML 파서는 너무 늦게 너무 늦게 우리 아이 보장하지만 정규식 (이 같은 이전에 예언 할 수없는 HTML 제외) 모든 살아있는 조직을 소모합니다 사랑하는 주님의 죄를 저장할 수 없습니다입니다 StackOverflow의를 죽이고 암입니다 캔 사람이 구문 분석 HTML에 정규식을 사용하여이 재앙에서 살아남을 방법 도움이 우리가 프로세스 HTML을 도구로 REGE의 X를 사용 공포 고문 및 보안 구멍의 영원에 인류를 파멸 한 같은이 세상과 부패한 기관의 공포 영역 (사이 브리의 채널을 설정 HTML에 대한 등록 전 파서의 세계 그 자체 glimp 단순한) SGML 엔티티하지만, 더 손상된 것 인 tantly 전송 AP 통신 rogrammer의 의식 내가 NTO 아 ORL D 끊임없는 비명, 그가 온다의 간악한 SL ithy 정규식 감염 줘야 Visual Basic에서 같은 모든 시간에 대한 HT ML 파서, 응용 프로그램과 존재 바우어 난 더 악화 그가 닷컴 ES하지 Fi를 GHT의 시간 전자 제공, HI의 부정 래디언스 드의 모든 깨달음을 stro҉ying, HTML 태그 누수가 온다 ING에서 요 우르 눈처럼 LIQ UID P는 아인이는 SP에서 탈 사람 MOR의 목소리를 nguish exti합니다 ssion 구문 분석 다시 일반 특급의 노래가 여기에 나는 그것이 당신이 아름다운 t은 그것을 볼 수 있습니다 볼 수 있습니다 그 F inal snuf 닐렌 O F 거짓의 사람 ALL이다 잃은 LL I SL OST 일 전자 그 S 올 포니 그는 S t 공동 ES를 COM ICH 또는 permeat ES 알 L MY FAC E MY FACE의 ᵒh 신, n은 O O NO NOO ON Θ 정지 t *가 그 ̶͑̾̾ GL ES ͎a̧͈͖r̽̾̈́͒͑e N OT 실제 ZA̡͊͠͝LGΌ ISͮ҉̯͈͕̹̘ T O͇̹̺Ɲ̴ȳ̳ 번째 E PO 뉴욕 올 HE들


대신 XML 파서를 사용해 보셨습니까?


진행자 메모

이 게시물은 콘텐츠에 대한 부적절한 편집을 방지하기 위해 잠겨 있습니다. 게시물은 보이는 대로 정확하게 보입니다. 내용에는 문제가 없습니다. 우리의 주의를 위해 플래그를 지정하지 마십시오.


Community Wiki

정규식만 있는 임의의 HTML은 불가능하지만 제한된 알려진 HTML 집합을 구문 분석하는 데 사용하는 것이 적절할 때도 있습니다.

데이터를 스크랩한 다음 데이터베이스에 채우려는 작은 HTML 페이지 세트가 있는 경우 정규 표현식이 제대로 작동할 수 있습니다. 예를 들어, 나는 최근에 의회 웹사이트에서 가져온 호주 연방 하원의원의 이름, 정당, 선거구를 얻고 싶었습니다. 이것은 제한된 일회성 작업이었습니다.

Regexes는 저에게 잘 작동했으며 설정이 매우 빨랐습니다.


Community Wiki

HTML은 촘스키 유형 2 문법(문맥 자유 문법) 이고 정규 표현식은 촘스키 유형 3 문법(정규 문법) 이라는 단점이 있습니다. Type 2 문법은 Type 3 문법보다 근본적으로 더 복잡하기 때문에( Chomsky 계층 참조) 정규 표현식으로 XML을 구문 분석하는 것은 수학적으로 불가능합니다.

그러나 많은 사람들이 시도하고 일부는 성공을 주장하기도 합니다. 그러나 다른 사람들이 잘못을 찾아 완전히 엉망이 될 때까지.


Community Wiki

이 녀석들의 말을 듣지 마세요. 작업을 더 작은 조각으로 나누면 정규식으로 컨텍스트 없는 문법을 완전히 구문 분석할 수 있습니다. 다음을 순서대로 수행하는 스크립트를 사용하여 올바른 패턴을 생성할 수 있습니다.

  1. 정지 문제를 해결합니다.
  2. 원을 사각형으로 만듭니다.
  3. O(log n) 이하로 여행하는 세일즈맨 문제를 해결하십시오. 그 이상이면 RAM이 부족하고 엔진이 정지됩니다.
  4. 패턴이 꽤 크므로 임의의 데이터를 무손실 압축하는 알고리즘이 있는지 확인하십시오.
  5. 거의 다 왔습니다. 전체를 0으로 나누면 됩니다. 쉬워요.

나 자신이 마지막 부분을 완전히 끝내지 못했지만, 나는 내가 가까이 가고 있다는 것을 압니다. CthulhuRlyehWgahnaglFhtagnException 계속 던지므로 VB 6으로 이식하고 On Error Resume Next 입니다. 방금 벽에서 열린 이 이상한 문을 조사하면 코드로 업데이트하겠습니다. 흠.

PS Pierre de Fermat도 방법을 알아냈지만 그가 작성하는 여백이 코드에 비해 충분하지 않았습니다.


Community Wiki

면책 조항 : 옵션이 있는 경우 파서를 사용하십시오. 그 말은...

이것은 HTML 태그와 일치시키기 위해 (!) 사용하는 정규식입니다.

 <(?:"[^"]*"['"]*|'[^']*'['"]*|[^'">])+>

완벽하지는 않지만 많은 HTML을 통해 이 코드를 실행했습니다. 웹에 표시되는 <a name="badgenerator""> 와 같은 이상한 것도 포착합니다.

자체 포함 태그와 일치하지 않게 하려면 Kobi 의 부정적인 뒤돌아보기를 사용하고 싶을 것입니다.

 <(?:"[^"]*"['"]*|'[^']*'['"]*|[^'">])+(?<!/\s*)>

또는 그렇지 않은 경우 결합하십시오.

반대 투표자에게: 이것은 실제 제품의 작업 코드입니다. 이 페이지를 읽는 사람이 HTML에서 정규식을 사용하는 것이 사회적으로 용인된다는 인상을 받을지 의심됩니다.

주의 사항 : 이 정규식은 CDATA 블록, 주석, 스크립트 및 스타일 요소가 있는 경우 여전히 중단된다는 점에 유의해야 합니다. 좋은 소식은 정규식을 사용하는 사람들을 제거할 수 있다는 것입니다...


Community Wiki

당신에게 지구가 둥글다고 말할 사람들이 있습니다. 그들은 거짓말을 하고 있다.

정규식은 재귀적이어서는 안 된다고 말하는 사람들이 있습니다. 그들은 당신을 제한하고 있습니다. 그들은 당신을 복종시킬 필요가 있으며, 당신을 무지하게 함으로써 그것을 합니다.

당신은 그들의 현실에 살거나 빨간 약을 먹을 수 있습니다.

Lord Marshal처럼(그는 Marshal .NET 클래스의 친척입니까?) 저는 Underverse Stack Based Regex-Verse를 보고 상상할 수 없는 강력한 지식을 가지고 돌아왔습니다. 네, 올드 한 두 명이 그들을 보호하고 있었던 것 같은데, 그들은 TV로 축구를 보고 있었기 때문에 어렵지 않았습니다.

XML의 경우는 매우 간단하다고 생각합니다. RegEx(.NET 구문에서)는 수축되고 약한 마음이 더 쉽게 이해할 수 있도록 base64로 코딩되어 다음과 같아야 합니다.

 7L0HYBxJliUmL23Ke39K9UrX4HShCIBgEyTYkEAQ7MGIzeaS7B1pRyMpqyqBymVWZV1mFkDM7Z28 995777333nvvvfe6O51OJ/ff/z9cZmQBbPbOStrJniGAqsgfP358Hz8itn6Po9/3eIue3+Px7/3F 86enJ8+/fHn64ujx7/t7vFuUd/Dx65fHJ6dHW9/7fd/t7fy+73Ye0v+f0v+Pv//JnTvureM3b169 OP7i9Ogyr5uiWt746u+BBqc/8dXx86PP7tzU9mfQ9tWrL18d3UGnW/z7nZ9htH/y9NXrsy9fvPjq i5/46ss3p4z+x3e8b452f9/x93a2HxIkH44PpgeFyPD6lMAEHUdbcn8ffTP9fdTrz/8rBPCe05Iv p9WsWF788Obl9MXJl0/PXnwONLozY747+t7x9k9l2z/4vv4kqo1//993+/vf2kC5HtwNcxXH4aOf LRw2z9/v8WEz2LTZcpaV1TL/4c3h66ex2Xv95vjF0+PnX744PbrOm59ZVhso5UHYME/dfj768H7e Yy5uQUydDAH9+/4eR11wHbqdfPnFF6cv3ogq/V23t++4z4620A13cSzd7O1s/77rpw+ePft916c7 O/jj2bNnT7e/t/397//M9+ibA/7s6ZNnz76PP0/kT2rz/Ts/s/0NArvziYxVEZWxbm93xsrUfnlm rASN7Hf93u/97vvf+2Lx/e89L7+/FSXiz4Bkd/hF5mVq9Yik7fcncft9350QCu+efkr/P6BfntEv z+iX9c4eBrFz7wEwpB9P+d9n9MfuM3yzt7Nzss0/nuJfbra3e4BvZFR7z07pj3s7O7uWJM8eCkme nuCPp88MfW6kDeH7+26PSTX8vu+ePAAiO4LVp4zIPWC1t7O/8/+pMX3rzo2KhL7+8s23T1/RhP0e vyvm8HbsdmPXYDVhtpdnAzJ1k1jeufOtUAM8ffP06Zcnb36fl6dPXh2f/F6nRvruyHfMd9rgJp0Y gvsRx/6/ZUzfCtX4e5hTndGzp5jQo9e/z+s3p1/czAUMlts+P3tz+uo4tISd745uJxvb3/v4ZlWs mrjfd9SG/swGPD/6+nh+9MF4brTBRmh1Tl5+9eT52ckt5oR0xldPzp7GR8pfuXf5PWJv4nJIwvbH W3c+GY3vPvrs9zj8Xb/147/n7/b7/+52DD2gsSH8zGDvH9+i9/fu/PftTfTXYf5hB+9H7P1BeG52 MTtu4S2cTAjDizevv3ry+vSNb8N+3+/1po2anj4/hZsGt3TY4GmjYbEKDJ62/pHB+3/LmL62wdsU 1J18+eINzTJr3dMvXr75fX7m+MXvY9XxF2e/9+nTgPu2bgwh5U0f7u/74y9Pnh6/OX4PlA2UlwTn xenJG8L996VhbP3++PCrV68QkrjveITxr2TIt+lL+f3k22fPn/6I6f/fMqZvqXN/K4Xps6sazUGZ GeQlar49xEvajzI35VRevDl78/sc/b7f6jkG8Va/x52N4L9lBe/kZSh1hr9fPj19+ebbR4AifyuY 12efv5CgGh9TroR6Pj2l748iYxYgN8Z7pr0HzRLg66FnRvcjUft/45i+pRP08vTV6TOe2N/9jv37 R9P0/5YxbXQDeK5E9R12XdDA/4zop+/9Ht/65PtsDVlBBUqko986WsDoWqvbPD2gH/T01DAC1NVn 3/uZ0feZ+T77fd/GVMkA4KjeMcg6RcvQLRl8HyPaWVStdv17PwHV0bOB9xUh7rfMp5Zu3icBJp25 D6f0NhayHyfI3HXHY6YYCw7Pz17fEFhQKzS6ZWChrX+kUf7fMqavHViEPPKjCf1/y5hukcyPTvjP mHQCppRDN4nbVFPaT8+ekpV5/TP8g/79mVPo77PT1/LL7/MzL7548+XvdfritflFY00fxIsvSQPS mvctdYZpbt7vxKRfj3018OvC/hEf/79lTBvM3debWj+b8KO0wP+3OeM2aYHumuCAGonmCrxw9cVX X1C2d4P+uSU7eoBUMzI3/f9udjbYl/el04dI7s8fan8dWRjm6gFx+NrKeFP+WX0CxBdPT58df/X8 DaWLX53+xFdnr06f/szv++NnX7x8fnb6NAhIwsbPkPS7iSUQAFETvP2Tx8+/Og0Xt/yBvDn9vd/c etno8S+81QKXptq/ffzKZFZ+4e/743e8zxino+8RX37/k595h5/H28+y7fPv490hQdJ349E+txB3 zPZ5J/jsR8bs/y1j2hh/2fkayOqEmYcej0cXUWMN7QrqBwjDrVZRfyQM3xjj/EgYvo4wfLTZrnVS ebdKq0XSZJvzajKQDUv1/P3NwbEP7cN5+Odivv9/ysPfhHfkOP6b9Fl+91v7LD9aCvp/+Zi+7lLQ j0zwNzYFP+/Y6r1NcFeDbfBIo8rug3zS3/3WPumPlN3/y8f0I2X3cz4FP+/Y6htSdr2I42fEuSPX /ewpL4e9/n1evzn94hb+Plpw2+dnbyh79zx0CsPvbq0lb+UQ/h7xvqPq/Gc24PnR18fzVrp8I57d mehj7ebk5VdPnp+d3GJOSP189eTsaXyk/JV7l98j4SAZgRxtf7x155PR+O6jz36Pw9/1Wz/+e/5u v//vbsfQAxobws8M9v7xLXp/785/395ED4nO1wx5fsTeH4LnRva+eYY8rpZUBFb/j/jfm8XAvfEj 4/b/ljF1F9B/jx5PhAkp1nu/+y3n+kdZp/93jWmjJ/M11TG++VEG6puZn593PPejoOyHMQU/79jq GwrKfpSB+tmcwZ93XPkjZffDmIKfd2z1DSm7bmCoPPmjBNT74XkrVf71I/Sf6wTU7XJA4RB+lIC6 mW1+xN5GWw1/683C5rnj/m364cmr45Pf6/SN9H4Us4LISn355vjN2ZcvtDGT6fHvapJcMISmxc0K MAD4IyP6/5Yx/SwkP360FvD1VTH191mURr/HUY+2P3I9boPnz7Ju/pHrcWPnP3I9/r/L3sN0v52z 0fEgNrgbL8/Evfh9fw/q5Xf93u/97vvf+2Lx/e89L7+/Fe3iZ37f34P5h178kTfx/5YxfUs8vY26 7/d4/OWbb5++ogn7PX5XzOHtOP3GrsHmqobOVO/8Hh1Gk/TPl198QS6w+rLb23fcZ0fMaTfjsv29 7Zul7me2v0FgRoYVURnf9nZEkDD+H2VDf8hjeq8xff1s6GbButNLacEtefHm9VdPXp++CRTw7/v9 r6vW8b9eJ0+/PIHzs1HHdyKE/x9L4Y+s2f+PJPX/1dbsJn3wrY6wiqv85vjVm9Pnp+DgN8efM5va j794+eb36Xz3mAf5+58+f3r68s230dRvJcxKn/l//oh3f+7H9K2O0r05PXf85s2rH83f/1vGdAvd w+qBFqsoWvzspozD77EpXYeZ7yzdfxy0ec+l+8e/8FbR84+Wd78xbvn/qQQMz/J7L++GPB7N0MQa 2vTMBwjDrVI0PxKGb4xxfiQMX0cYPuq/Fbx2C1sU8yEF+F34iNsx1xOGa9t6l/yX70uqmxu+qBGm AxlxWwVS11O97ULqlsFIUvUnT4/fHIuL//3f9/t9J39Y9m8W/Tuc296yUeX/b0PiHwUeP1801Y8C j/9vz9+PAo8f+Vq35Jb/n0rAz7Kv9aPA40fC8P+RMf3sC8PP08DjR1L3DXHoj6SuIz/CCghZNZb8 fb/Hf/2+37tjvuBY9vu3jmRvxNeGgQAuaAF6Pwj8/+e66M8/7rwpRNj6uVwXZRl52k0n3FVl95Q+ +fz0KSu73/dtkGDYdvZgSP5uskadrtViRKyal2IKAiQfiW+FI+tET/9/Txj9SFf8SFf8rOuKzagx +r/vD34mUADO1P4/AQAA//8=

설정할 옵션은 RegexOptions.ExplicitCapture 입니다. 찾고 있는 캡처 그룹은 ELEMENTNAME 입니다. 캡처 그룹 ERROR 가 비어 있지 않으면 구문 분석 오류가 있었고 Regex가 중지되었습니다.

사람이 읽을 수 있는 정규식으로 다시 변환하는 데 문제가 있는 경우 다음이 도움이 됩니다.

 static string FromBase64(string str) { byte[] byteArray = Convert.FromBase64String(str); using (var msIn = new MemoryStream(byteArray)) using (var msOut = new MemoryStream()) { using (var ds = new DeflateStream(msIn, CompressionMode.Decompress)) { ds.CopyTo(msOut); } return Encoding.UTF8.GetString(msOut.ToArray()); } }

확신이 서지 않는다면 농담이 아닙니다(하지만 아마도 거짓말일 것입니다). 그것은 작동합니다. 나는 그것을 테스트하기 위해 수많은 단위 테스트를 구축했으며 심지어 적합성 테스트 (일부)를 사용했습니다. 완전한 파서가 아닌 토크나이저이므로 XML을 구성 요소 토큰으로만 분할합니다. DTD를 구문 분석/통합하지 않습니다.

오... 정규식의 소스 코드를 원하는 경우 몇 가지 보조 방법이 있습니다.

xml 또는 전체 일반 정규식을 토큰화하는 정규식


Community Wiki

셸에서 sed를 사용하여 HTML 을 구문 분석할 수 있습니다.

  1. 튜링.sed
  2. HTML 파서 작성(숙제)
  3. ???
  4. 이익!

관련(정규식 일치를 사용하지 말아야 하는 이유):


Community Wiki

XML, 특히 HTML 을 구문 분석하는 올바른 도구는 정규식 엔진이 아니라 구문 분석기라는 데 동의합니다. 그러나 다른 사람들이 지적했듯이 때로는 정규식을 사용하는 것이 더 빠르고 쉬우며 데이터 형식을 알고 있으면 작업이 완료됩니다.

Microsoft는 실제로 .NET Framework의 정규식에 대한 모범 사례 섹션이 있으며 입력 소스 고려 에 대해 구체적으로 설명합니다.

정규 표현식에는 제한이 있지만 다음 사항을 고려한 적이 있습니까?

.NET 프레임워크는 균형 그룹 정의를 지원한다는 점에서 정규식과 관련하여 고유합니다.

이러한 이유로 정규식을 사용하여 XML을 구문 분석할 수 있다고 생각합니다. 그러나 유효한 XML이어야 합니다 ( 브라우저는 HTML을 매우 관대하고 HTML 내부에 잘못된 XML 구문을 허용합니다 ). 이는 "밸런싱 그룹 정의"가 정규식 엔진이 PDA로 작동하도록 허용하기 때문에 가능합니다.

위에 인용된 기사 1에서 인용:

.NET 정규식 엔진

위에서 설명한 대로 적절하게 균형이 잡힌 구성은 정규식으로 설명할 수 없습니다. 그러나 .NET 정규식 엔진은 균형 잡힌 구문을 인식할 수 있도록 하는 몇 가지 구문을 제공합니다.

  • (?<group>) - 캡처된 결과를 그룹이라는 이름으로 캡처 스택에 푸시합니다.
  • (?<-group>) - 캡처 스택에서 이름 그룹과 함께 맨 위 캡처를 팝합니다.
  • (?(group)yes|no) - group이라는 이름의 그룹이 있으면 yes 부분과 일치하고 그렇지 않으면 부분과 일치하지 않습니다.

이러한 구성을 사용하면 기본적으로 푸시, 팝 및 비어 있는 스택 작업의 간단한 버전을 허용하여 .NET 정규식이 제한된 PDA를 에뮬레이트할 수 있습니다. 간단한 연산은 각각 0에 대한 증가, 감소 및 비교와 거의 동일합니다. 이를 통해 .NET 정규식 엔진은 컨텍스트가 없는 언어, 특히 간단한 카운터만 필요한 언어의 하위 집합을 인식할 수 있습니다. 이것은 차례로 비전통적인 .NET 정규식이 개별 적절하게 균형 잡힌 구성을 인식할 수 있도록 합니다.

다음 정규식을 고려하십시오.

 (?=<ul\s+id="matchMe"\s+type="square"\s*>) (?> <!-- .*? --> | <[^>]*/> | (?<opentag><(?!/)[^>]*[^/]>) | (?<-opentag></[^>]*[^/]>) | [^<>]* )* (?(opentag)(?!))

플래그 사용:

  • 하나의 선
  • IgnorePatternWhitespace(정규식을 축소하고 모든 공백을 제거하는 경우 필요하지 않음)
  • IgnoreCase(필요하지 않음)

정규 표현식 설명(인라인)

 (?=<ul\s+id="matchMe"\s+type="square"\s*>) # match start with <ul id="matchMe"... (?> # atomic group / don't backtrack (faster) <!-- .*? --> | # match xml / html comment <[^>]*/> | # self closing tag (?<opentag><(?!/)[^>]*[^/]>) | # push opening xml tag (?<-opentag></[^>]*[^/]>) | # pop closing xml tag [^<>]* # something between tags )* # match as many xml tags as possible (?(opentag)(?!)) # ensure no 'opentag' groups are on stack

A Better .NET Regular Expression Tester 에서 이것을 시도할 수 있습니다.

다음의 샘플 소스를 사용했습니다.

 <html> <body> <div> <br /> <ul id="matchMe" type="square"> <li>stuff...</li> <li>more stuff</li> <li> <div> <span>still more</span> <ul> <li>Another &gt;ul&lt;, oh my!</li> <li>...</li> </ul> </div> </li> </ul> </div> </body> </html>

일치하는 항목을 찾았습니다.

 <ul id="matchMe" type="square"> <li>stuff...</li> <li>more stuff</li> <li> <div> <span>still more</span> <ul> <li>Another &gt;ul&lt;, oh my!</li> <li>...</li> </ul> </div> </li> </ul>

실제로 다음과 같이 나왔지만

 <ul id="matchMe" type="square"> <li>stuff...</li> <li>more stuff</li> <li> <div> <span>still more</span> <ul> <li>Another &gt;ul&lt;, oh my!</li> <li>...</li> </ul> </div> </li> </ul>

마지막으로 Jeff Atwood의 기사인 Parsing Html The Cthulhu Way가 정말 마음에 들었습니다. 흥미롭게도, 현재 4,000표가 넘는 이 질문에 대한 답변을 인용합니다.


Sam

PHP에서 XML 및 HTML을 구문 분석하기 위해 QueryPath 를 사용하는 것이 좋습니다. 기본적으로 jQuery와 거의 동일한 구문이지만 서버 측에 있을 뿐입니다.


Community Wiki

정규식으로 HTML을 구문 분석할 수 없다는 대답은 정확하지만 여기에는 적용되지 않습니다. OP는 정규식으로 하나의 HTML 태그를 구문 분석하기를 원하며 이는 정규식으로 수행할 수 있는 것입니다.

그러나 제안된 정규식은 잘못되었습니다.

 <([az]+) *[^/]*?>

정규식에 무언가를 추가하면 역추적하여 <a >> , [^/] 가 너무 관대합니다. 또한 <space>*[^/]* 는 중복됩니다. [^/]* 도 공백과 일치할 수 있기 때문입니다.

내 제안은

 <([az]+)[^>]*(?<!/)>

어디 (?<! ... ) 는 (Perl 정규식에서) 부정적인 look-behind입니다. "<, 그 다음 단어, >가 아닌 모든 것, 마지막에 /가 아닐 수 있으며, 그 다음에 >"로 읽힙니다.

<a/ > 와 같은 것을 허용합니다(원래 정규식과 동일). 따라서 더 제한적인 것을 원한다면 공백으로 구분된 속성 쌍과 일치하도록 정규식을 빌드해야 합니다.


Community Wiki

노력하다:

 <([^\s]+)(\s[^>]*?)?(?<!/)>

당신의 것과 비슷하지만 마지막 > 은 슬래시 뒤에 있으면 안 되며 h1 도 허용합니다.


Community Wiki

고대 중국의 전략가이자 장군이자 철학자인 손자는 이렇게 말했습니다.

적을 알고 나를 알면 백 번 싸워도 한 번도 패하지 않는다는 말이 있다. 자신만 알고 상대는 모른다면 이기기도 하고 질 수도 있다. 자신과 적을 알지 못하면 항상 자신을 위험에 빠뜨릴 것입니다.

이 경우 당신의 적은 HTML이고 당신은 자신이거나 정규식입니다. 불규칙한 정규식을 사용하는 Perl일 수도 있습니다. HTML을 알고 있습니다. 너 자신을 알라.

HTML의 본질을 설명하는 하이쿠를 작성했습니다.

 HTML has complexity exceeding regular language.

또한 Perl에서 정규식의 특성을 설명하는 하이쿠를 작성했습니다.

 The regex you seek is defined within the phrase <([a-zA-Z]+)(?:[^>]*[^/]*)?>

Community Wiki

<?php $selfClosing = explode(',', 'area,base,basefont,br,col,frame,hr,img,input,isindex,link,meta,param,embed'); $html = ' <p><a href="#">foo</a></p> <hr/> <br/> <div>name</div>'; $dom = new DOMDocument(); $dom->loadHTML($html); $els = $dom->getElementsByTagName('*'); foreach ( $els as $el ) { $nodeName = strtolower($el->nodeName); if ( !in_array( $nodeName, $selfClosing ) ) { var_dump( $nodeName ); } }

산출:

 string(4) "html" string(4) "body" string(1) "p" string(1) "a" string(3) "div"

기본적으로 자체 닫히는 요소 노드 이름을 정의하고, 전체 html 문자열을 DOM 라이브러리에 로드하고, 모든 요소를 잡고, 자체 닫히지 않는 요소를 반복하고 걸러내고 작동합니다.

이 목적을 위해 정규식을 사용하면 안 된다는 것을 이미 알고 계실 것입니다.


Community Wiki

이에 대한 정확한 필요성을 모르지만 .NET도 사용하고 있다면 Html Agility Pack 을 사용할 수 없습니까?

발췌:

"out of the web" HTML 파일을 구문 분석할 수 있는 .NET 코드 라이브러리입니다. 파서는 "실제" 형식이 잘못된 HTML에 대해 매우 관대합니다.


Community Wiki

/ 앞에 오지 않는 첫 번째 > 원합니다. 자세한 방법은 여기를 참조하세요. 부정적인 뒤돌아보기라고 합니다.

그러나 이것의 순진한 구현은 이 예제 문서에서 <bar/></foo>

 <foo><bar/></foo>

해결하려는 문제에 대한 정보를 조금 더 제공할 수 있습니까? 프로그래밍 방식으로 태그를 반복하고 있습니까?


Community Wiki

W3C는 의사 정규 표현식 형식으로 구문 분석을 설명합니다.
W3C 링크

더 명확한 그림을 얻으려면 QName , SAttribute 에 대한 var 링크를 따르십시오.
이를 기반으로 태그 제거와 같은 작업을 처리하는 꽤 좋은 정규 표현식을 만들 수 있습니다.


Community Wiki

PHP에 필요한 경우:

올바른 형식의 XML이 아니면 PHP DOM 기능이 제대로 작동하지 않습니다. 나머지 인류를 위해 사용하는 것이 얼마나 더 나은지 상관 없습니다.

simplehtmldom 은 좋지만 약간 버그가 있는 것으로 나타났으며 메모리가 상당히 무겁습니다. [큰 페이지에서 충돌합니다.]

나는 querypath를 사용한 적이 없으므로 그 유용성에 대해 언급할 수 없습니다.

또 다른 시도는 리소스에 매우 가벼운 DOMParser 이며 한동안 행복하게 사용하고 있습니다. 배우기 쉽고 강력합니다.

Python 및 Java의 경우 유사한 링크가 게시되었습니다.

downvoters를 위해 - XML 파서가 실제 사용을 견딜 수 없는 것으로 판명되었을 때만 클래스를 작성했습니다. 종교적인 반대 투표는 유용한 답변이 게시되는 것을 막습니다. 질문의 관점에서 일을 유지하십시오.


Community Wiki

해결책은 다음과 같습니다.

 <?php // here's the pattern: $pattern = '/<(\w+)(\s+(\w+)\s*\=\s*(\'|")(.*?)\\4\s*)*\s*(\/>|>)/'; // a string to parse: $string = 'Hello, try clicking <a href="#paragraph">here</a> <br/>and check out.<hr /> <h2>title</h2> <a name ="paragraph" rel= "I\'m an anchor"></a> Fine, <span title=\'highlight the "punch"\'>thanks<span>. <div class = "clear"></div> <br>'; // let's get the occurrences: preg_match_all($pattern, $string, $matches, PREG_PATTERN_ORDER); // print the result: print_r($matches[0]); ?>

깊이 테스트하기 위해 다음과 같은 자동 닫기 태그 문자열을 입력했습니다.

  1. <시간 />
  2. <br/>
  3. <br>

나는 또한 다음과 함께 태그를 입력했습니다.

  1. 하나의 속성
  2. 둘 이상의 속성
  3. 값이 작은 따옴표 또는 큰 따옴표로 묶인 속성
  4. 구분 기호가 큰따옴표이고 그 반대인 경우 작은따옴표를 포함하는 속성
  5. "unpretty" 속성은 "=" 기호 앞, 뒤, 앞뒤 모두 공백이 있습니다.

위의 개념 증명에서 작동하지 않는 것을 찾으면 코드를 분석하여 기술을 향상시킬 수 있습니다.

<EDIT> 사용자의 질문이 자동 닫힘 태그의 구문 분석을 피하는 것임을 잊었습니다. 이 경우 패턴은 다음과 같이 더 간단합니다.

 $pattern = '/<(\w+)(\s+(\w+)\s*\=\s*(\'|")(.*?)\\4\s*)*\s*>/';

사용자 @ridgerunner는 패턴이 인용되지 않은 속성 이나 값이 없는 속성을 허용하지 않는다는 것을 알아차렸습니다. 이 경우 미세 조정은 다음 패턴을 제공합니다.

 $pattern = '/<(\w+)(\s+(\w+)(\s*\=\s*(\'|"|)(.*?)\\5\s*)?)*\s*>/';

</편집>

패턴 이해하기

누군가가 패턴에 대해 더 자세히 알고 싶다면 몇 줄을 제공합니다.

  1. 첫 번째 하위 표현식(\w+)은 태그 이름과 일치합니다.
  2. 두 번째 하위 표현식은 속성의 패턴을 포함합니다. 구성:
    1. 하나 이상의 공백 \s+
    2. 속성의 이름(\w+)
    3. 0개 이상의 공백 \s*(가능 여부, 여기에 공백을 남겨둠)
    4. "=" 기호
    5. 다시, 0개 이상의 공백
    6. 속성 값의 구분 기호, 작은 따옴표 또는 큰 따옴표('|"). 패턴에서 작은 따옴표는 PHP 문자열 구분 기호와 일치하기 때문에 이스케이프됩니다. 이 하위 표현식은 참조할 수 있도록 괄호로 캡처됩니다. 속성의 클로저를 구문 분석하기 위해 다시 한 번, 이것이 매우 중요한 이유입니다.
    7. 거의 모든 것과 일치하는 속성 값: (.*?); 이 특정 구문에서 탐욕스러운 일치 (별표 뒤의 물음표)를 사용하여 RegExp 엔진은 "예측"과 유사한 연산자를 활성화합니다.
    8. 여기에 재미가 있습니다. \4 부분은 패턴에서 이전에 정의된 하위 표현식을 참조하는 역참조 연산자 입니다. 이 경우에는 발견된 첫 번째 속성 구분 기호인 네 번째 하위 표현식을 참조합니다.
    9. 0개 이상의 공백 \s*
    10. 속성 하위 표현식은 별표로 표시되는 0개 이상의 가능한 발생을 지정하여 여기서 끝납니다.
  3. 그러면 태그가 ">" 기호 앞의 공백으로 끝날 수 있으므로 0개 이상의 공백이 \s* 하위 패턴과 일치합니다.
  4. 일치시킬 태그는 간단한 ">" 기호로 끝나거나 그 앞에 슬래시를 사용하는 가능한 XHTML 클로저(/>|>)로 끝날 수 있습니다. 물론 슬래시는 정규식 구분 기호와 일치하므로 이스케이프 처리됩니다.

작은 팁: 이 코드를 더 잘 분석하려면 HTML 특수 문자 이스케이프를 제공하지 않았기 때문에 생성된 소스 코드를 살펴보아야 합니다.


Community Wiki

HTML 문서에서 무언가를 빠르게 추출해야 할 때마다 Tidy를 사용하여 XML로 변환한 다음 XPath 또는 XSLT를 사용하여 필요한 것을 얻습니다. 귀하의 경우 다음과 같습니다.

 //p/a[@href='foo']

Community Wiki

이전에 HTMLParser 라는 오픈 소스 도구를 사용했습니다. 다양한 방법으로 HTML을 구문 분석하도록 설계되었으며 목적을 잘 수행합니다. HTML을 다른 트리 노드로 구문 분석할 수 있으며 해당 API를 사용하여 노드에서 속성을 쉽게 가져올 수 있습니다. 확인하고 이것이 도움이 될 수 있는지 확인하십시오.


Community Wiki

정규 표현식으로 HTML을 구문 분석하는 것을 좋아합니다. 나는 고의적으로 깨진 바보 HTML을 구문 분석하려고 시도하지 않습니다. 이 코드는 내 주요 파서(Perl 에디션)입니다.

 $_ = join "",<STDIN>; tr/\n\r \t/ /s; s/</\n</g; s/>/>\n/g; s/\n ?\n/\n/g; s/^ ?\n//s; s/ $//s; print

htmlsplit 이라고 하며 각 줄에 하나의 태그 또는 텍스트 청크가 있는 HTML을 줄로 분할합니다. 그런 다음 grep , sed , Perl 등과 같은 다른 텍스트 도구 및 스크립트를 사용하여 해당 줄을 추가로 처리할 수 있습니다. 농담이 아닙니다. :) 즐기세요.

거대한 웹 페이지를 처리하려는 경우 모든 것을 우선적으로 처리하는 Perl 스크립트를 멋진 스트리밍 것으로 다시 지그하는 것은 충분히 간단합니다. 하지만 꼭 필요한 것은 아닙니다.

HTML 분할


더 나은 정규 표현식:

 /(<.*?>|[^<]+)\s*/g # Get tags and text /(\w+)="(.*?)"/g # Get attibutes

XML / XHTML에 좋습니다.

사소한 변형으로 지저분한 HTML에 대처하거나 HTML -> XHTML을 먼저 변환할 수 있습니다.


정규 표현식을 작성하는 가장 좋은 방법은 Lex / Yacc 스타일로, 불투명한 한 줄이나 주석이 달린 여러 줄의 괴물이 아닙니다. 나는 아직 여기에서 그것을 하지 않았다; 이것들은 거의 필요하지 않습니다.


Community Wiki

다음은 일부 불경건한 정규식을 사용하여 HTML을 구문 분석 하는 PHP 기반 파서 ( archived )입니다. 이 프로젝트의 저자로서 HTML을 정규식으로 구문 분석하는 것이 가능하지만 효율적이지 않다고 말할 수 있습니다. 내 wp-Typography WordPress 플러그인에 대해 했던 것처럼 서버 측 솔루션이 필요한 경우 이것이 작동합니다.


Community Wiki

HTML을 BBCode로 대체하기 위한 몇 가지 멋진 정규식이 여기에 있습니다 . 반대하는 모든 사람들을 위해 그가 HTML을 완전히 구문 분석하려고 하는 것이 아니라 단지 위생적으로 처리하려고 한다는 점에 유의하십시오. 그는 아마도 그의 단순한 "파서"가 이해할 수 없는 태그를 제거할 여유가 있을 것입니다.

예를 들어:

 $store =~ s/http:/http:\/\//gi; $store =~ s/https:/https:\/\//gi; $baseurl = $store; if (!$query->param("ascii")) { $html =~ s/\s\s+/\n/gi; $html =~ s/<pre(.*?)>(.*?)<\/pre>/\[code]$2\[\/code]/sgmi; } $html =~ s/\n//gi; $html =~ s/\r\r//gi; $html =~ s/$baseurl//gi; $html =~ s/<h[1-7](.*?)>(.*?)<\/h[1-7]>/\n\[b]$2\[\/b]\n/sgmi; $html =~ s/<p>/\n\n/gi; $html =~ s/<br(.*?)>/\n/gi; $html =~ s/<textarea(.*?)>(.*?)<\/textarea>/\[code]$2\[\/code]/sgmi; $html =~ s/<b>(.*?)<\/b>/\[b]$1\[\/b]/gi; $html =~ s/<i>(.*?)<\/i>/\[i]$1\[\/i]/gi; $html =~ s/<u>(.*?)<\/u>/\[u]$1\[\/u]/gi; $html =~ s/<em>(.*?)<\/em>/\[i]$1\[\/i]/gi; $html =~ s/<strong>(.*?)<\/strong>/\[b]$1\[\/b]/gi; $html =~ s/<cite>(.*?)<\/cite>/\[i]$1\[\/i]/gi; $html =~ s/<font color="(.*?)">(.*?)<\/font>/\[color=$1]$2\[\/color]/sgmi; $html =~ s/<font color=(.*?)>(.*?)<\/font>/\[color=$1]$2\[\/color]/sgmi; $html =~ s/<link(.*?)>//gi; $html =~ s/<li(.*?)>(.*?)<\/li>/\[\*]$2/gi; $html =~ s/<ul(.*?)>/\[list]/gi; $html =~ s/<\/ul>/\[\/list]/gi; $html =~ s/<div>/\n/gi; $html =~ s/<\/div>/\n/gi; $html =~ s/<td(.*?)>/ /gi; $html =~ s/<tr(.*?)>/\n/gi; $html =~ s/<img(.*?)src="(.*?)"(.*?)>/\[img]$baseurl\/$2\[\/img]/gi; $html =~ s/<a(.*?)href="(.*?)"(.*?)>(.*?)<\/a>/\[url=$baseurl\/$2]$4\[\/url]/gi; $html =~ s/\[url=$baseurl\/http:\/\/(.*?)](.*?)\[\/url]/\[url=http:\/\/$1]$2\[\/url]/gi; $html =~ s/\[img]$baseurl\/http:\/\/(.*?)\[\/img]/\[img]http:\/\/$1\[\/img]/gi; $html =~ s/<head>(.*?)<\/head>//sgmi; $html =~ s/<object>(.*?)<\/object>//sgmi; $html =~ s/<script(.*?)>(.*?)<\/script>//sgmi; $html =~ s/<style(.*?)>(.*?)<\/style>//sgmi; $html =~ s/<title>(.*?)<\/title>//sgmi; $html =~ s/<!--(.*?)-->/\n/sgmi; $html =~ s/\/\//\//gi; $html =~ s/http:\//http:\/\//gi; $html =~ s/https:\//https:\/\//gi; $html =~ s/<(?:[^>'"]*|(['"]).*?\1)*>//gsi; $html =~ s/\r\r//gi; $html =~ s/\[img]\//\[img]/gi; $html =~ s/\[url=\//\[url=/gi;

Community Wiki

(x)HTML을 구문 분석하는 정규식 메서드에 대한 질문에 대해 일부 제한에 대해 말한 모든 사람의 대답은 다음과 같습니다. 여기에서 아무도 재귀에 대해 이야기하지 않았기 때문에 이 강력한 무기의 힘을 지배할 만큼 충분히 훈련되지 않았습니다. .

정규식에 구애받지 않는 한 동료가 이 토론을 저에게 알렸습니다. 이 토론은 이 오래되고 뜨거운 주제에 대한 웹상의 첫 번째 것은 아닙니다.

일부 게시물을 읽은 후 가장 먼저 한 일은 이 스레드에서 "?R" 문자열을 찾는 것이었습니다. 두 번째는 "재귀"에 대한 검색이었습니다.

아니요, 성스러운 암소, 일치하는 항목을 찾을 수 없습니다. 아무도 파서가 구축된 기본 메커니즘에 대해 언급하지 않았기 때문에 아무도 요점을 이해하지 못했다는 것을 곧 깨달았습니다.

(x)HTML 파서에 재귀가 필요한 경우 재귀가 없는 정규식 파서로는 충분하지 않습니다. 간단한 구성입니다.

정규 표현식의 검은 예술은 마스터하기 어렵습니다 . 따라서 한 손으로 전체 웹을 캡처하기 위해 개인 솔루션을 시도하고 테스트하는 동안 우리가 놓친 가능성이 더 있을 수 있습니다... 글쎄, 나는 그것에 대해 확신합니다. :)

다음은 마법의 패턴입니다.

 $pattern = "/<([\w]+)([^>]*?)(([\s]*\/>)|(>((([^<]*?|<\!\-\-.*?\-\->)|(?R))*)<\/\\1[\s]*>))/s";

그냥 시도 해 봐. PHP 문자열로 작성되었으므로 "s" 수정자는 클래스에 개행 문자를 포함합니다.

여기에 수동 I 월에 쓴 PHP에 샘플 노트는 다음과 같습니다 참조

(조심하세요. 그 메모에서 "m" 수식어를 잘못 사용했습니다. ^ 또는 $ 앵커링이 사용되지 않았기 때문에 정규식 엔진에 의해 삭제되었음에도 불구하고 지워야 합니다.)

이제 정보에 입각한 관점에서 이 방법의 한계에 대해 이야기할 수 있습니다.

  1. 정규식 엔진의 특정 구현에 따라 재귀는 구문 분석되는 중첩 패턴 수에 제한이 있을 수 있지만 사용되는 언어에 따라 다릅니다.
  2. 손상되었지만 (x)HTML은 심각한 오류를 발생시키지 않습니다. 그것은 살균 되지 않습니다.

어쨌든 이것은 정규식 패턴일 뿐이지만 많은 강력한 구현을 개발할 가능성을 공개합니다.

이 패턴을 작성하여 프레임워크에 구축한 템플릿 엔진의 재귀 하강 파서 에 전원을 공급했으며 실행 시간이나 메모리 사용량 모두에서 성능이 정말 뛰어납니다(동일한 구문을 사용하는 다른 템플릿 엔진과 관련 없음).


Community Wiki

<\s*(\w+)[^/>]*>

부품 설명:

< : 시작 문자

\s* : 태그 이름 앞에 공백이 있을 수 있습니다(못생겼지만 가능).

(\w+) : 태그는 문자와 숫자(h1)를 포함할 수 있습니다. 글쎄, \w 는 '_'와도 일치하지만 아프지 않을 것 같습니다. 궁금하면 대신 ([a-zA-Z0-9]+)를 사용하세요.

[^/>]* >/ 제외한 모든 항목이 닫힐 때까지 >

> : 마감 >

관련 없음

그리고 정규 표현식을 과소평가하는 동료들에게, 정규 표현식은 정규 언어만큼 강력하다고 말합니다.

a n ban n ban n 은 규칙적이지 않고 컨텍스트가 없기도 하며 ^(a+)b\1b\1$

역참조 FTW !


Community Wiki

많은 사람들이 이미 지적했듯이 HTML은 구문 분석을 매우 어렵게 만들 수 있는 정규 언어가 아닙니다. 이에 대한 나의 해결책은 깔끔한 프로그램을 사용하여 정규 언어로 변환한 다음 XML 파서를 사용하여 결과를 소비하는 것입니다. 이를 위한 좋은 옵션이 많이 있습니다. 내 프로그램은 jtidy 라이브러리와 함께 Java를 사용하여 HTML을 XML로 변환한 다음 Jaxen에서 xpath를 결과로 변환하여 작성되었습니다.


Community Wiki

단순히 해당 태그를 찾으려는 경우(파싱에 대한 야망 없이) 다음 정규식을 사용해 보세요.

 /<[^/]*?>/g

30초 만에 작성하고 여기에서 테스트했습니다. http://gskinner.com/RegExr/

언급한 태그 유형과 일치하지만 무시하고 싶다고 말한 유형은 무시합니다.


Community Wiki

끝에 "/" 없이 태그를 일치시키려고 하는 것 같습니다. 이 시도:

 <([a-zA-Z][a-zA-Z0-9]*)[^>]*(?<!/)>

Community Wiki

프로그래밍할 때 HTML을 다룰 때, 특히 정확성이 가장 중요한 경우(예: 처리가 보안에 영향을 미칠 수 있는 경우) 일반적으로 정규식 대신 전용 파서와 API를 사용하는 것이 가장 좋습니다. 그러나 나는 XML 스타일 마크업이 정규 표현식으로 처리되어서는 안된다는 독단적인 견해를 갖고 있지 않습니다. 텍스트 편집기에서 일회성 편집을 수행하거나 손상된 XML 파일을 수정하거나 XML처럼 보이지만 완전히 XML이 아닌 파일 형식을 처리할 때와 같이 정규 표현식이 작업을 위한 훌륭한 도구인 경우가 있습니다. 알아야 할 몇 가지 문제가 있지만 극복할 수 없거나 반드시 관련이 있는 것은 아닙니다.

<([^>"']|"[^"]*"|'[^']*')*> 와 같은 간단한 정규식은 내가 방금 언급한 것과 같은 경우에 일반적으로 충분합니다. 모든 것을 고려한 순진한 솔루션이지만 속성 값에서 > 예를 들어, table 태그를 </?table\b([^>"']|"[^"]*"|'[^']*')*> .

좀 더 "고급" HTML 정규식이 어떻게 생겼는지 이해하기 위해 다음은 실제 브라우저 동작과 HTML5 구문 분석 알고리즘을 에뮬레이트하는 상당히 훌륭한 작업입니다.

 </?([A-Za-z][^\s>/]*)(?:=\s*(?:"[^"]*"|'[^']*'|[^\s>]+)|[^>])*(?:>|$)

다음은 XML 태그의 상당히 엄격한 정의와 일치합니다(XML 이름에 허용되는 전체 유니코드 문자 집합을 설명하지는 않음).

 <(?:([_:AZ][-.:\w]*)(?:\s+[_:AZ][-.:\w]*\s*=\s*(?:"[^"]*"|'[^']*'))*\s*/?|/([_:AZ][-.:\w]*)\s*)>

물론, 이것들은 주변 컨텍스트와 몇 가지 예외적인 경우를 설명하지 않지만, 정말로 원하는 경우(예: 다른 정규식의 일치 항목 사이를 검색하여) 처리할 수 있습니다.

하루가 끝나면 해당 도구가 정규식인 경우에도 작업에 가장 적합한 도구를 사용하십시오.


Community Wiki

그 목적을 위해 정규식을 사용하는 것이 적합하지 않고 효과적이지는 않지만 때때로 정규식은 간단한 일치 문제에 대한 빠른 솔루션을 제공하며 내 생각에는 사소한 작업에 정규식을 사용하는 것이 그렇게 끔찍하지는 않습니다.

Steven Levithan이 작성한 가장 안쪽의 HTML 요소 일치에 대한 확실한 블로그 게시물 이 있습니다.


Community Wiki

출처 : http:www.stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

반응형