Câu hỏi RegEx khớp các thẻ mở trừ các thẻ tự chứa XHTML


Tôi cần phải khớp tất cả các thẻ mở này:

<p>
<a href="foo">

Nhưng không phải như vậy:

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

Tôi đã nghĩ ra điều này và muốn chắc chắn rằng tôi đã đúng. Tôi chỉ đang chụp a-z.

<([a-z]+) *[^/]*?>

Tôi tin rằng nó nói:

  • Tìm ít hơn, sau đó
  • Tìm (và chụp) a-z một hoặc nhiều lần, sau đó
  • Tìm không hoặc nhiều không gian, sau đó
  • Tìm bất kỳ ký tự nào bằng 0 hoặc nhiều lần, tham lam, ngoại trừ /, sau đó
  • Tìm lớn hơn

Tôi có đúng không? Và quan trọng hơn, bạn nghĩ sao?


1324
2017-09-27 04:01


gốc




Các câu trả lời:


Bạn không thể phân tích cú pháp [X] HTML với regex. Bởi vì HTML không thể được phân tích cú pháp bằng regex. Regex không phải là một công cụ có thể được sử dụng để phân tích cú pháp HTML một cách chính xác. Như tôi đã trả lời trong câu hỏi HTML-và-regex ở đây rất nhiều lần trước đây, việc sử dụng regex sẽ không cho phép bạn sử dụng HTML. Cụm từ thông dụng là một công cụ không đủ tinh vi để hiểu các cấu trúc được sử dụng bởi HTML. HTML không phải là ngôn ngữ thông thường và do đó không thể được phân tích cú pháp bằng cụm từ thông dụng. Các truy vấn Regex không được trang bị để phân tách HTML thành các phần có ý nghĩa của nó. rất nhiều lần nhưng nó không đến với tôi. Thậm chí tăng cường các biểu thức chính quy bất thường như được sử dụng bởi Perl không phải là nhiệm vụ phân tích cú pháp HTML. Bạn sẽ không bao giờ làm cho tôi bị nứt. HTML là một ngôn ngữ đủ phức tạp mà nó không thể được phân tích bằng các biểu thức thông thường. Thậm chí Jon Skeet cũng không thể phân tích cú pháp HTML bằng các biểu thức chính quy. Mỗi khi bạn cố gắng phân tích cú pháp HTML với các biểu thức thông thường, đứa trẻ không biết gì đó khóc lóc máu của trinh nữ, và tin tặc Nga pwn webapp của bạn. Phân tích cú pháp HTML với regex triệu hồi các linh hồn bị nhiễm độc vào cõi sống. HTML và regex đi cùng nhau như tình yêu, hôn nhân và nghi thức infanticide. <Center> không thể giữ nó quá trễ. Lực lượng của regex và HTML cùng nhau trong cùng một không gian khái niệm sẽ phá hủy tâm trí của bạn giống như quá nhiều putty. Nếu bạn phân tích cú pháp HTML với regex bạn đang đưa ra cho Them và những cách phỉ báng của họ mà tất cả chúng ta đều vô nhân đạo đối với Người có Tên không thể được thể hiện trong Máy bay Đa ngôn ngữ Cơ bản, anh ta đến. HTML-cộng-regexp sẽ hóa lỏng n erves của người bệnh trong khi bạn quan sát, tâm lý của bạn héo trong sự tấn công dữ dội của kinh dị. Trình phân tích cú pháp HTML dựa trên Rege̿̔̉x là ung thư đang giết chết StackOverflow đã quá muộn rồi, chúng ta không thể cứu được quá muộn các trangession của một chi͡ld đảm bảo regex sẽ tiêu thụ tất cả các mô sống (trừ HTML mà nó không thể, như trước đây đã tiên tri) chúa yêu quý giúp chúng ta làm sao có ai có thể sống sót trong tai họa này sử dụng regex để phân tích HTML đã làm nhân loại phải chịu đựng sự tra tấn khủng khiếp và vĩnh viễn sử dụng regex như một công cụ để xử lý HTML thiết lập một breach giữa thế giới này và lĩnh vực đáng sợ của các thực thể ngắt kết nối (như các thực thể SGML, nhưng tham nhũng hơn) chỉ là một cái nhìn thoáng quase của thế giới của regcác trình phân tích cú pháp cũ cho HTML sẽTantly vận chuyển một pý thức của rogrammer tôivào một world của la hét không ngừng, anh ấy đến, ruồi giấmithy regex-infection will nuốt HT của bạnML phân tích cú pháp, ứng dụng và sự tồn tại cho tất cả các thời gian như Visual Basic chỉ tồi tệ hơn anh ấy đến anh ấy comes không fiGht he com̡e̶s, ̕h̵iS un̨ho͞ly radiańcé devuốt ve tất cả các thư, thẻ HTML lea͠ki̧n͘g fr̶ǫm ̡yo ͟ur eye͢s̸ ̛l̕ik͏e liqUid pain, bài hát của re regular exp rephân tích ssion sẽ extiNgu si tiếng nói của mortal người đàn ông từ spỞ đây tôi có thể thấy nó, bạn có thể thấy ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ nó đẹp tanh ấy final snufngón tay of lời nói dốis của Man ALL LÀ LOŚ͖̩͇̗̪̏̈́T ALL I S LOST thứe pon̷y anh ấy đếnanh ấy c̶̮omes he cotôis tanh ấy ichhoặc thấm vàoes all MY FACE MY FACE ᵒh thần no KHÔNG NOO̼O O NΘ dừng tanh ấy * ̶͑̾̾ ̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e nOt rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚ N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S


Bạn đã thử sử dụng một trình phân tích cú pháp XML chưa?


Ghi chú của người kiểm duyệt

Bài đăng này bị khóa để ngăn các chỉnh sửa không phù hợp đối với nội dung của nó. Bài đăng có vẻ chính xác như nó được cho là trông - không có vấn đề gì với nội dung của nó. Vui lòng không gắn cờ cho sự chú ý của chúng tôi.


4422



Kobi: Tôi nghĩ đã đến lúc tôi bỏ bài viết của Trợ lý không phân tích HTML với nhân viên Regex. Bất kể chúng ta nói bao nhiêu lần, chúng sẽ không dừng lại mỗi ngày ... mỗi giờ. Đó là một nguyên nhân bị mất, mà người khác có thể chiến đấu một chút. Vì vậy, đi vào, phân tích cú pháp HTML với regex, nếu bạn phải. Nó chỉ là mã bị hỏng, không phải là sự sống và cái chết. - bobince
Có thể sử dụng RegEx để phân tích câu trả lời này không? - Chris Porter
Nếu bạn không thể nhìn thấy bài đăng này, đây là một màn hình của nó trong tất cả vinh quang của nó: imgur.com/gOPS2.png - Andrew Keeton


Mặc dù đúng là yêu cầu regex để phân tích cú pháp tùy ý HTML giống như yêu cầu người mới bắt đầu viết một hệ điều hành, đôi khi nó thích hợp để phân tích cú pháp hạn chế, được biết đến tập hợp HTML.

Nếu bạn có một tập hợp nhỏ các trang HTML mà bạn muốn xóa dữ liệu và sau đó chèn vào cơ sở dữ liệu, các regex có thể hoạt động tốt. Ví dụ, gần đây tôi muốn lấy tên, các đảng, và các quận của các đại diện liên bang của Úc, mà tôi đã rời khỏi trang web của Quốc hội. Đây là một công việc hạn chế, một lần.

Regexes làm việc tốt cho tôi, và rất nhanh để thiết lập.


2921



Ngoài ra, cạo dữ liệu được định dạng khá thường xuyên từ các tài liệu lớn sẽ nhanh hơn với việc sử dụng quét & regex một cách thận trọng hơn bất kỳ trình phân tích cú pháp chung nào. Và nếu bạn cảm thấy thoải mái với các quy tắc mã hóa, cách nhanh hơn để mã hóa hơn là các xpath mã hóa. Và gần như chắc chắn ít mong manh hơn với những thay đổi trong những gì bạn đang cạo. Vì vậy, bleh. - Michael Johnston
@MichaelJohnston "Ít mong manh"? Hầu như chắc chắn là không. Regexes quan tâm đến chi tiết định dạng văn bản hơn một trình phân tích cú pháp XML có thể bỏ qua âm thầm. Chuyển đổi giữa &foo; mã hóa và CDATA phần? Sử dụng trình chỉnh sửa HTML để xóa tất cả khoảng trắng trong tài liệu của bạn mà trình duyệt không hiển thị? Một trình phân tích cú pháp XML sẽ không quan tâm và cũng không phải là một tuyên bố XPath được viết tốt. Mặt khác, "trình phân tích cú pháp" dựa trên regex ... - Charles Duffy
@CharlesDuffy cho một công việc một lần nó là ok, và cho không gian chúng tôi sử dụng \ s + - quantum
@xiaomao thực sự, nếu phải biết tất cả các gotchas và cách giải quyết để có được một giải pháp 80% mà không phần còn lại của thời gian "làm việc cho bạn", tôi không thể ngăn chặn bạn. Trong khi đó, tôi đã vượt qua hàng rào của mình bằng cách sử dụng các trình phân tích cú pháp hoạt động trên 100% XML hợp lệ về cú pháp. - Charles Duffy
Tôi đã từng phải kéo một số dữ liệu ra ~ 10 nghìn trang, tất cả đều có cùng một mẫu HTML. Chúng được rải rác với các lỗi HTML khiến các trình phân tích cú pháp bị sặc, và tất cả các kiểu dáng của chúng đều là nội dòng hoặc với <font> v.v.: không có lớp hoặc ID để giúp điều hướng DOM. Sau khi chiến đấu cả ngày với cách tiếp cận "đúng", cuối cùng tôi đã chuyển sang một giải pháp regex và đã làm việc trong một giờ. - Paul A Jungwirth


Tôi nghĩ lỗ hổng ở đây là HTML là một Chomsky Loại 2 ngữ pháp (ngữ pháp ngữ pháp miễn phí) và RegEx là một Chomsky Loại 3 ngữ pháp (ngữ pháp thông thường). Vì ngữ pháp loại 2 về cơ bản phức tạp hơn ngữ pháp loại 3 (xem Hệ thống phân cấp Chomsky), bạn không thể thực hiện công việc này. Nhưng nhiều người sẽ cố gắng, một số sẽ tuyên bố thành công và những người khác sẽ tìm thấy lỗi và hoàn toàn mess bạn lên.


1801



OP yêu cầu phân tích cú pháp một tập con XHTML rất hạn chế: bắt đầu các thẻ. Điều gì làm cho (X) HTML một CFG là tiềm năng của nó để có các phần tử giữa thẻ bắt đầu và kết thúc của các phần tử khác (như trong một quy tắc ngữ pháp A -> s A e). (X) HTML không phải có tài sản này trong thẻ bắt đầu: thẻ bắt đầu không thể chứa các thẻ bắt đầu khác. Tập hợp con mà OP đang cố phân tích không phải là CFG. - LarsH
Trong lý thuyết CS, ngôn ngữ thông thường là một tập hợp con nghiêm ngặt của các ngôn ngữ không có ngữ cảnh, nhưng việc triển khai biểu thức chính quy trong các ngôn ngữ lập trình chính thống thì mạnh mẽ hơn. Như noulakaz.net/weblog/2007/03/18/… mô tả, cái gọi là "biểu thức chính quy" có thể kiểm tra các số nguyên tố trong unary, mà chắc chắn là một cái gì đó mà một biểu thức chính quy từ lý thuyết CS không thể thực hiện được. - Adam Mihalcin
@eyelidlessness: cùng "chỉ khi" áp dụng cho tất cả CFG, phải không? I E. nếu đầu vào HTML (X) không được định dạng đúng, ngay cả một trình phân tích cú pháp XML đầy đủ sẽ hoạt động đáng tin cậy. Có lẽ nếu bạn đưa ra ví dụ về các lỗi cú pháp HTML "(X) được thực hiện trong các tác nhân người dùng thực tế" bạn đang đề cập đến, tôi sẽ hiểu những gì bạn đang nhận được tốt hơn. - LarsH
@AdamMihalcin là chính xác. Hầu hết các công cụ regex còn tồn tại đều mạnh hơn các charsky Type 3 grammars (ví dụ như không phù hợp với tham lam, backrefs). Một số động cơ regex (như của Perl) là Turing hoàn thành. Đúng là ngay cả đó là những công cụ kém để phân tích cú pháp HTML, nhưng đối số được trích dẫn này không phải là lý do tại sao. - dubiousjim
Đây là câu trả lời "đầy đủ và ngắn" nhất ở đây. Nó dẫn mọi người tìm hiểu các khái niệm cơ bản về ngữ pháp và ngôn ngữ chính thức và hy vọng một số môn toán để họ không lãng phí thời gian vào những thứ vô vọng như giải quyết các nhiệm vụ NP trong thời gian đa thức - mishmashru


Đừng nghe những người này. Bạn thực sự có thể phân tích ngữ pháp ngữ pháp miễn phí với regex nếu bạn chia nhiệm vụ thành các phần nhỏ hơn. Bạn có thể tạo mẫu đúng với tập lệnh thực hiện từng mẫu theo thứ tự sau:

  1. Giải quyết vấn đề dừng.
  2. Vuông hình tròn (mô phỏng phương pháp "thước kẻ và la bàn" cho việc này).
  3. Làm việc ra vấn đề người bán hàng du lịch trong O (log n). Nó cần phải nhanh hoặc máy phát sẽ treo.
  4. Mô hình sẽ khá lớn, vì vậy hãy đảm bảo bạn có một thuật toán nén dữ liệu ngẫu nhiên một cách mất mát.
  5. Hầu như ở đó - chỉ phân chia toàn bộ điều bằng không. Dễ như ăn bánh.

Tôi đã không tìm ra phần cuối cùng, nhưng tôi biết tôi đang đến gần. Mã của tôi tiếp tục ném CthulhuRlyehWgahnaglFhtagnExceptionGần đây, vì vậy tôi sẽ chuyển nó sang VB 6 và sử dụng On Error Resume Next. Tôi sẽ cập nhật với mã khi tôi điều tra cánh cửa lạ này vừa mở trên tường. Hmm.

P.S. Pierre de Fermat cũng đã tìm ra cách để làm điều đó, nhưng mức ký quỹ mà anh đã viết không đủ lớn cho mã.


1169



Chia cho số không là một vấn đề dễ dàng hơn nhiều so với những người khác bạn đề cập đến. Nếu bạn sử dụng các khoảng thời gian, chứ không phải là số học dấu chấm động đơn giản (mà tất cả mọi người nên nhưng không có ai), bạn có thể chia sẻ hạnh phúc một cái gì đó bằng [một khoảng thời gian chứa] số không. Kết quả chỉ đơn giản là một khoảng thời gian chứa dấu cộng và trừ vô cùng. - rjmunro
Vấn đề về lợi nhuận nhỏ của Fermat đã được giải quyết bằng các lợi nhuận mềm trong phần mềm chỉnh sửa văn bản hiện đại. - kd4ttc
Vấn đề về lợi nhuận nhỏ của Fermat đã được giải quyết bởi Randall Munroe bằng cách đặt phông chữ thành 0: xkcd.com/1381 - heltonbiker
FYI: Fermat của vấn đề có thực ra được giải quyết vào năm 1995, và nó chỉ mất các nhà toán học 358 năm để làm như vậy. - jmiserez
Tôi đã có thể bỏ qua bước phân chia dính đó bằng cách thay vào đó sử dụng các ratchet nâu mang lại từ phản ứng tổng hợp lạnh ... mặc dù nó chỉ hoạt động khi tôi loại bỏ hằng số vũ trụ học. - Tim Lehner


Tuyên bố từ chối trách nhiệm: sử dụng trình phân tích cú pháp nếu bạn có tùy chọn. Mà nói...

Đây là regex tôi sử dụng (!) Để khớp các thẻ HTML:

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

Nó có thể không hoàn hảo, nhưng tôi đã chạy mã này thông qua một nhiều của HTML. Lưu ý rằng nó thậm chí còn bắt được những thứ kỳ lạ như <a name="badgenerator"">, hiển thị trên web.

Tôi đoán để làm cho nó không phù hợp với thẻ tự chứa, bạn muốn hoặc là muốn sử dụng Kobicái nhìn tiêu cực:

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

hoặc chỉ kết hợp nếu và nếu không.

Để downvoters: Đây là mã hoạt động từ một sản phẩm thực tế. Tôi nghi ngờ bất cứ ai đọc trang này sẽ nhận được ấn tượng rằng nó được xã hội chấp nhận để sử dụng regexes trên HTML.

Nhớ lại: Tôi nên lưu ý rằng regex này vẫn bị phá vỡ với sự hiện diện của các khối CDATA, các chú thích và các phần tử kịch bản và kiểu. Tin tốt là, bạn có thể loại bỏ những người sử dụng regex ...


1018



Tôi sẽ đi với một cái gì đó mà làm việc trên những điều lành mạnh hơn khóc về việc không được hoàn hảo phổ quát :-) - prajeesh kumar
Có ai đó đang sử dụng CDATA bên trong HTML không? - Danubian Sailor
do đó bạn không thực sự giải quyết vấn đề phân tích cú pháp chỉ với regexp nhưng như một phần của trình phân tích cú pháp, điều này có thể hoạt động. PS: sản phẩm làm việc không có nghĩa là mã tốt. Không có hành vi phạm tội, nhưng đây là cách lập trình công nghiệp và kiếm tiền của họ - mishmashru
Regex của bạn bắt đầu không thành công trên HTML rất ngắn, có thể hợp lệ: <!doctype html><title><</title>. Đơn giản '<!doctype html><title><</title>'.match(/<(?:"[^"]*"['"]*|'[^']*'['"]*|[^'">])+>/g) trả về ["<!doctype html>", "<title>", "<</title>"] trong khi nên ["<title>", "</title>"]. - Benio
"Người dẫn chương trình huy hiệu" là gì - Richard de Wit


Có những người sẽ cho bạn biết rằng Trái Đất tròn (hoặc có lẽ Trái đất là một hình cầu có nghĩa là nếu họ muốn sử dụng những từ lạ). Họ đang nói dối.

Có những người sẽ cho bạn biết rằng Biểu thức chính quy không nên đệ quy. Họ đang hạn chế bạn. Họ cần phải chinh phục bạn, và họ làm điều đó bằng cách giữ cho bạn trong vô minh.

Bạn có thể sống trong thực tế của họ hoặc uống viên thuốc màu đỏ.

Giống như Lord Marshal (anh ta là họ hàng của lớp Marshal .NET?), Tôi đã thấy Nghịch đảo Stack Dựa trên Regex-Verse và được trả về với quyền lực kiến thức bạn không thể tưởng tượng. Vâng, tôi nghĩ có một hoặc hai người già bảo vệ họ, nhưng họ đang xem bóng đá trên TV, nên không khó.

Tôi nghĩ rằng trường hợp XML khá đơn giản. RegEx (trong cú pháp .NET), được xì hơi và mã hóa trong base64 để làm cho nó dễ hiểu hơn bởi tâm trí yếu ớt của bạn, phải là một cái gì đó như thế này:

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=

Các tùy chọn để đặt là RegexOptions.ExplicitCapture. Nhóm chụp bạn đang tìm là ELEMENTNAME. Nếu nhóm chụp ERROR không rỗng thì có lỗi phân tích cú pháp và Regex dừng lại.

Nếu bạn gặp sự cố khi hoàn nguyên nó thành một regex có thể đọc được, điều này sẽ giúp:

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());
    }
}

Nếu bạn không chắc chắn, không, tôi KHÔNG đùa (nhưng có lẽ tôi đang nói dối). Nó S work làm việc. Tôi đã xây dựng rất nhiều bài kiểm tra đơn vị để kiểm tra nó và thậm chí tôi đã sử dụng (một phần) kiểm tra sự phù hợp. Đó là một trình sửa lỗi, không phải là trình phân tích cú pháp đầy đủ, do đó nó sẽ chỉ tách XML thành các thẻ thành phần của nó. Nó sẽ không phân tích cú pháp / tích hợp các DTD.

Oh ... nếu bạn muốn mã nguồn của regex, với một số phương pháp phụ trợ:

regex để tokenize một xml hoặc là toàn bộ đồng bằng regex 


453



Chúa ơi, nó thật to. Câu hỏi lớn nhất của tôi là tại sao? Bạn nhận ra rằng tất cả các ngôn ngữ hiện đại đều có trình phân tích cú pháp XML, đúng không? Bạn có thể làm tất cả những gì trong 3 dòng và chắc chắn rằng nó sẽ làm việc. Hơn nữa, bạn cũng nhận ra rằng regex thuần khiết là có thể chứng minh không thể làm những việc nhất định? Trừ khi bạn đã tạo một trình phân tích cú pháp mã regex / mệnh lệnh lai, nhưng nó không giống như bạn có. Bạn có thể nén dữ liệu ngẫu nhiên không? - Justin Morgan
@ Justin Tôi không cần một lý do. Nó có thể được thực hiện (và nó không phải là bất hợp pháp / vô đạo đức), vì vậy tôi đã làm nó. Không có giới hạn nào đối với tâm trí ngoại trừ những gì chúng ta thừa nhận (Napoleon Hill) ... Các ngôn ngữ hiện đại có thể phân tích cú pháp XML? Có thật không? Và tôi nghĩ rằng đó là bất hợp pháp! :-) - xanatos
Thưa ngài, tôi bị thuyết phục. Tôi sẽ sử dụng mã này như một phần của hạt nhân cho máy chuyển động vĩnh viễn của tôi - bạn có thể tin những kẻ ngu đó tại văn phòng bằng sáng chế không tiếp tục đơn xin của tôi? Vâng, tôi sẽ cho họ xem. Tôi sẽ chỉ cho họ tất cả! - Justin Morgan
@Justin Vì vậy, một Xml Parser là do lỗi định nghĩa miễn phí, trong khi một Regex không? Bởi vì nếu một Xml Parser không phải là lỗi miễn phí theo định nghĩa có thể là một xml mà làm cho nó sụp đổ và chúng tôi đang trở lại bước 0. Hãy nói điều này: cả Xml Parser và Regex này cố gắng để có thể phân tích tất cả các "hợp pháp "XML. Họ CÓ THỂ phân tích một số XML "bất hợp pháp". Bugs có thể sụp đổ cả hai. C # XmlReader chắc chắn được thử nghiệm nhiều hơn Regex này. - xanatos
Không, không có gì là lỗi miễn phí: 1) Tất cả các chương trình có chứa ít nhất một lỗi. 2) Tất cả các chương trình có chứa ít nhất một dòng mã nguồn không cần thiết. 3) Bởi # 1 và # 2 và sử dụng cảm ứng logic, đó là một vấn đề đơn giản để chứng minh rằng bất kỳ chương trình có thể được giảm xuống một dòng mã với một lỗi. (từ Học tập Perl) - sweaver2112


Trong trình bao, bạn có thể phân tích cú pháp HTML sử dụng:


Liên quan (tại sao bạn không nên sử dụng kết hợp regex):


285



Xem thêm perlmonks.org/?displaytype=print;node_id=809842 - dubiousjim
Tôi sợ bạn đã không nhận được trò đùa, @kenorb. Xin vui lòng, đọc câu hỏi và câu trả lời được chấp nhận một lần nữa. Đây không phải là về các công cụ phân tích cú pháp HTML nói chung, cũng như về các công cụ trình phân tích cú pháp HTML, đó là về phân tích HTML thông qua các regex. - Palec
@ Tôi không có trò đùa. Có gần như không thể phân tích cú pháp HTML với regex không? - Abdul
Vâng, câu trả lời đó tóm tắt tốt, @Abdul. Lưu ý rằng, tuy nhiên, việc triển khai regex không thực sự đều đặn các biểu thức theo nghĩa toán học - chúng có các cấu trúc làm cho chúng trở nên mạnh hơn, thường là Turing-complete (tương đương với các loại ngữ pháp loại 0). Lập luận phá vỡ với thực tế này, nhưng vẫn còn phần nào hợp lệ theo nghĩa là các regex không bao giờ có nghĩa là có khả năng thực hiện một công việc như vậy. - Palec
Và bằng cách này, các trò đùa tôi gọi là nội dung của câu trả lời này trước khi chỉnh sửa (cấp tiến) của kenorb, cụ thể sửa đổi 4, @Abdul. - Palec


Tôi đồng ý rằng công cụ thích hợp để phân tích cú pháp XML và đặc biệt là HTML là một trình phân tích cú pháp chứ không phải là một công cụ biểu thức chính quy. Tuy nhiên, như những người khác đã chỉ ra, đôi khi sử dụng một regex là nhanh hơn, dễ dàng hơn, và được công việc làm nếu bạn biết định dạng dữ liệu.

Microsoft thực sự có một phần của Thực tiễn tốt nhất cho biểu thức chính quy trong Khuôn khổ .NET và đặc biệt nói về Xem xét [ing] Nguồn đầu vào.

Cụm từ thông dụng có những giới hạn, nhưng bạn có cân nhắc những điều sau đây không?

Khuôn khổ .NET là duy nhất khi nói đến các biểu thức chính quy ở chỗ nó hỗ trợ Định nghĩa nhóm cân bằng.

Vì lý do này, tôi tin rằng bạn CÓ THỂ phân tích cú pháp XML bằng cách sử dụng cụm từ thông dụng. Tuy nhiên, lưu ý rằng phải là XML hợp lệ (trình duyệt rất tha thứ cho HTML và cho phép cú pháp XML xấu bên trong HTML). Điều này là có thể vì "Balancing Group Definition" sẽ cho phép công cụ biểu thức chính quy hoạt động như một PDA.

Trích dẫn từ bài viết 1 trích dẫn ở trên:

.NET Regular Expression Engine

Như được mô tả ở trên, các cấu trúc cân bằng hợp lý không thể được mô tả bởi   một biểu thức chính quy. Tuy nhiên, công cụ biểu thức chính quy .NET   cung cấp một vài cấu trúc cho phép các cấu trúc cân bằng trở thành   được công nhận.

  • (?<group>) - đẩy kết quả đã chụp trên ngăn xếp chụp bằng   nhóm tên.
  • (?<-group>) - bật đầu chụp nhiều nhất với nhóm tên tắt   bắt giữ.
  • (?(group)yes|no) - khớp với phần có nếu có tồn tại một nhóm   với nhóm tên khác, không khớp với phần nào.

Các cấu trúc này cho phép biểu thức chính quy .NET mô phỏng   PDA bị hạn chế về cơ bản cho phép các phiên bản đơn giản của ngăn xếp   hoạt động: push, pop và trống. Các thao tác đơn giản là khá nhiều   tương đương với tăng, giảm và so sánh với 0 tương ứng.   Điều này cho phép công cụ biểu thức chính quy .NET nhận ra   tập hợp con của các ngôn ngữ không có ngữ cảnh, đặc biệt là các ngôn ngữ chỉ   yêu cầu một bộ đếm đơn giản. Điều này lần lượt cho phép phi truyền thống   Biểu thức chính quy .NET để nhận diện cá nhân được cân bằng đúng cách   cấu trúc.

Xem xét cụm từ thông dụng sau:

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

Sử dụng cờ:

  • Singleline
  • IgnorePatternWhitespace (không cần thiết nếu bạn thu gọn regex và xóa tất cả khoảng trắng)
  • IgnoreCase (không cần thiết)

Giải thích cụm từ thông dụng (nội tuyến)

(?=<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

Bạn có thể thử điều này tại Trình kiểm tra biểu thức chính quy .NET tốt hơn.

Tôi đã sử dụng nguồn mẫu:

<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>

Điều này đã tìm thấy kết quả phù hợp:

   <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>

mặc dù nó thực sự xuất hiện như thế này:

<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>

Cuối cùng, tôi thực sự thích bài viết của Jeff Atwood: Phân tích cú pháp Html Cách Cthulhu. Vui đủ, nó trích dẫn câu trả lời cho câu hỏi này hiện có hơn 4k phiếu bầu.


261



System.Text không phải là một phần của C #. Đó là một phần của .NET. - John Saunders
Trong dòng đầu tiên của regex của bạn ((?=<ul\s*id="matchMe"\s*type="square"\s*>) # match start with <ul id="matchMe"...), ở giữa "<ul" và "id" phải là \s+, không phải \s*, trừ khi bạn muốn nó khớp <ulid = ...;) - C0deH4cker
@ C0deH4cker Bạn đúng, biểu hiện nên có \s+ thay vì \s*. - Sam
Không phải là tôi thực sự hiểu nó, nhưng tôi nghĩ rằng regex của bạn không thành công <img src="images/pic.jpg" /> - Scheintod
@Scheintod Cảm ơn bạn đã bình luận. Tôi đã cập nhật mã. Biểu thức trước đó không thành công cho các thẻ tự đóng có / một nơi nào đó bên trong không thành công cho bạn <img src="images/pic.jpg" /> html. - Sam


Tôi đề nghị sử dụng QueryPath để phân tích cú pháp XML và HTML trong PHP. Về cơ bản nó giống cú pháp giống jQuery, chỉ có nó ở phía máy chủ.


255



@ Kyle — jQuery không phân tích cú pháp XML, nó sử dụng trình phân tích cú pháp dựng sẵn của trình khách (nếu có). Do đó bạn không cần jQuery để làm điều đó, nhưng ít nhất là hai dòng JavaScript cũ thuần túy. Nếu không có trình phân tích cú pháp dựng sẵn, jQuery sẽ không trợ giúp. - RobG
@RobG Trên thực tế jQuery sử dụng DOM, không phải trình phân tích cú pháp được tích hợp sẵn. - Qix
@ Qix — bạn nên nói với tác giả của tài liệu sau đó: "jQuery.parseXML sử dụng chức năng phân tích cú pháp gốc của trình duyệt…". Nguồn: jQuery.parseXML () - RobG
Đến đây từ câu hỏi meme (meta.stackexchange.com/questions/19478/the-many-memes-of-meta/…), Tôi thích rằng một trong những câu trả lời là 'Sử dụng jQuery' - Jorn


Mặc dù các câu trả lời mà bạn không thể phân tích cú pháp HTML với các regex là chính xác nhưng chúng không áp dụng ở đây. OP chỉ muốn phân tích cú pháp một thẻ HTML với các regex, và đó là một cái gì đó có thể được thực hiện với một biểu thức chính quy.

Các regex được đề xuất là sai, mặc dù:

<([a-z]+) *[^/]*?>

Nếu bạn thêm một cái gì đó vào regex, bằng cách backtracking nó có thể bị buộc phải phù hợp với những điều ngớ ngẩn như <a >>, [^/] quá dễ dãi. Cũng lưu ý rằng <space>*[^/]* là thừa, bởi vì [^/]* cũng có thể phù hợp với không gian.

Đề xuất của tôi sẽ là

<([a-z]+)[^>]*(?<!/)>

Ở đâu (?<! ... ) là (trong Perl regexes) cái nhìn tiêu cực. Nó đọc "a <, sau đó là một từ, sau đó bất kỳ thứ gì không phải là>, cuối cùng trong số đó có thể không phải là /, tiếp theo là>".

Lưu ý rằng điều này cho phép những thứ như <a/ > (giống như regex gốc), vì vậy nếu bạn muốn một cái gì đó hạn chế hơn, bạn cần phải xây dựng một regex để phù hợp với các cặp thuộc tính cách nhau bởi dấu cách.


212



1 để lưu ý rằng câu hỏi không phải là về phân tích cú pháp đầy đủ (X) HTML, đó là về các thẻ mở HTML phù hợp (X). - LarsH
Một cái gì đó khác hầu hết các câu trả lời dường như bỏ qua, là một trình phân tích cú pháp HTML có thể sử dụng các biểu thức chính quy trong việc triển khai cho các phần của HTML và tôi sẽ ngạc nhiên nếu hầu hết các trình phân tích cú pháp không làm điều này. - Thayne
@ Thayne Chính xác. Khi phân tích các thẻ riêng lẻ, cụm từ thông dụng là công cụ thích hợp cho công việc. Nó là khá vô lý mà người ta phải di chuyển nửa chừng xuống trang để tìm một câu trả lời hợp lý. Câu trả lời được chấp nhận là không chính xác vì nó kết hợp lexing và phân tích cú pháp. - kasperd
Câu trả lời được đưa ra ở đây sẽ thất bại khi một giá trị thuộc tính chứa ký tự '>' hoặc '/'. - Martin L
Thao tác này sẽ hoạt động không chính xác trên HTML chứa các nhận xét hoặc phần CData. Nó cũng sẽ không hoạt động chính xác nếu thuộc tính được trích dẫn chứa > tính cách. Tôi đồng ý những gì OP đề nghị có thể được thực hiện với một regex, nhưng một trong những trình bày ở đây là đến nay để đơn giản. - JacquesB


Thử:

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

Nó tương tự như của bạn, nhưng cuối cùng > không được sau dấu gạch chéo và cũng chấp nhận h1.


177



<a href="foo" title="5> 3 "> Rất tiếc </a> - Gareth
Điều đó rất đúng, và tôi đã nghĩ về nó, nhưng tôi đã giả định > biểu tượng được thoát đúng cách đến & gt ;. - Kobi
> hợp lệ trong một giá trị thuộc tính. Thật vậy, trong chuỗi tuần tự 'chuẩn XML', bạn không được sử dụng &gt;. (Không hoàn toàn phù hợp, ngoại trừ nhấn mạnh rằng >trong một giá trị thuộc tính không phải là một điều bất thường.) - bobince
@Kobi: những gì hiện các nhãn hiệu exlamation (một trong những bạn đặt tpward kết thúc) có nghĩa là trong một regexp? - Marco Demaio
@bobince: bạn có chắc không? Tôi không hiểu nữa, vì vậy đây cũng là HTML hợp lệ: <div title="this tag is a <div></div>">hello</div> - Marco Demaio