RegEx match open tags except XHTML self-contained tags

Question

I need to match all of these opening tags:

<p>
<a href="foo">

But not these:

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

I came up with this and wanted to make sure I've got it right. I am only capturing the a-z.

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

I believe it says:

Find a less-than, then
Find (and capture) a-z one or more times, then
Find zero or more spaces, then
Find any character zero or more times, greedy, except /, then
Find a greater-than

Do I have that right? And more importantly, what do you think?

score 4407 · Accepted Answer · edited Nov 12 '20 at 14:21

You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is not a tool that can be used to correctly parse HTML. As I have answered in HTML-and-regex questions here so many times before, the use of regex will not allow you to consume HTML. Regular expressions are a tool that is insufficiently sophisticated to understand the constructs employed by HTML. HTML is not a regular language and hence cannot be parsed by regular expressions. Regex queries are not equipped to break down HTML into its meaningful parts. so many times but it is not getting to me. Even enhanced irregular regular expressions as used by Perl are not up to the task of parsing HTML. You will never make me crack. HTML is a language of sufficient complexity that it cannot be parsed by regular expressions. Even Jon Skeet cannot parse HTML using regular expressions. Every time you attempt to parse HTML with regular expressions, the unholy child weeps the blood of virgins, and Russian hackers pwn your webapp. Parsing HTML with regex summons tainted souls into the realm of the living. HTML and regex go together like love, marriage, and ritual infanticide. The <center> cannot hold it is too late. The force of regex and HTML together in the same conceptual space will destroy your mind like so much watery putty. If you parse HTML with regex you are giving in to Them and their blasphemous ways which doom us all to inhuman toil for the One whose Name cannot be expressed in the Basic Multilingual Plane, he comes. HTML-plus-regexp will liquify the nerves of the sentient whilst you observe, your psyche withering in the onslaught of horror. Rege̿̔̉x-based HTML parsers are the cancer that is killing StackOverflow it is too late it is too late we cannot be saved the transgression of a chi͡ld ensures regex will consume all living tissue (except for HTML which it cannot, as previously prophesied) dear lord help us how can anyone survive this scourge using regex to parse HTML has doomed humanity to an eternity of dread torture and security holes using regex as a tool to process HTML establishes a breach between this world and the dread realm of c͒ͪo͛ͫrrupt entities (like SGML entities, but more corrupt) a mere glimpse of the world of regex parsers for HTML will instantly transport a programmer's consciousness into a world of ceaseless screaming, he comes~~, the pestilent sl~~ithy regex-infection will devour your HTML parser, application and existence for all time like Visual Basic only worse he comes he comes do not fight he com̡e̶s, ̕h̵is un̨ho͞ly radiańcé destro҉ying all enli̍̈́̂̈́ghtenment, HTML tags lea͠ki̧n͘g fr̶ǫm ̡yo͟ur eye͢s̸ ̛l̕ik͏e liquid pain, the song of re̸gular expre~~ssion parsing~~ will extinguish the voices of mortal man from the sphere I can see it can you see ̲͚̖͔̙î̩́t̲͎̩̱͔́̋̀ it is beautiful the final snuffing of the lies of Man ALL IS LOŚ͖̩͇̗̪̏̈́T ALL IS LOST the pon̷y he comes he c̶̮om~~es he co~~mes the ichor permeates all MY FACE MY FACE ᵒh god no NO NOO̼OO NΘ stop the an*̶͑̾̾̅ͫ͏̙̤g͇̫͛͆̾ͫ̑͆l͖͉̗̩̳̟̍ͫͥͨe̠̅s ͎a̧͈͖r̽̾̈́͒͑e not rè̑ͧ̌aͨl̘̝̙̃ͤ͂̾̆ ZA̡͊͠͝LGΌ ISͮ̂҉̯͈͕̹̘̱ TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

Have you tried using an XML parser instead?

Moderator's Note

This post is locked to prevent inappropriate edits to its content. The post looks exactly as it is supposed to look - there are no problems with its content. Please do not flag it for our attention.

Kobi: I think it's time for me to quit the post of Assistant Don't Parse HTML With Regex Officer. No matter how many times we say it, they won't stop coming every day... every hour even. It is a lost cause, which someone else can fight for a bit. So go on, parse HTML with regex, if you must. It's only broken code, not life and death. — bobince, Nov 13 '09 at 23:18
If you can't see this post, here's a screencapture of it in all its glory: http://imgur.com/gOPS2.png — Andrew Keeton, Nov 19 '09 at 14:37

score 3560 · Answer 2 · edited Sep 19 '19 at 15:30

3560

While arbitrary HTML with only a regex is impossible, it's sometimes appropriate to use them for parsing a limited, known set of HTML.

If you have a small set of HTML pages that you want to scrape data from and then stuff into a database, regexes might work fine. For example, I recently wanted to get the names, parties, and districts of Australian federal Representatives, which I got off of the Parliament's web site. This was a limited, one-time job.

Regexes worked just fine for me, and were very fast to set up.

edited Sep 19 '19 at 15:30

Ruben Verborgh

3,545
2
31
43

answered Nov 14 '09 at 06:27

Kaitlin Duck Sherwood

807
1
5
3

159

Also, scraping fairly regularly formatted data from large documents is going to be WAY faster with judicious use of scan & regex than any generic parser. And if you are comfortable with coding regexes, way faster to code than coding xpaths. And almost certainly less fragile to changes in what you are scraping. So bleh. – Michael Johnston Apr 17 '12 at 20:47
314

@MichaelJohnston "Less fragile"? Almost certainly not. Regexes care about text-formatting details than an XML parser can silently ignore. Switching between `&foo;` encodings and `CDATA` sections? Using an HTML minifier to remove all whitespace in your document that the browser doesn't render? An XML parser won't care, and neither will a well-written XPath statement. A regex-based "parser", on the other hand... – Charles Duffy Jul 11 '12 at 16:03
46

@CharlesDuffy for an one time job it's ok, and for spaces we use \s+ – quantum Jul 12 '12 at 13:50
80

@xiaomao indeed, if having to know all the gotchas and workarounds to get an 80% solution that fails the rest of the time "works for you", I can't stop you. Meanwhile, I'm over on my side of the fence using parsers that work on 100% of syntactically valid XML. – Charles Duffy Jul 12 '12 at 16:07
433

I once had to pull some data off ~10k pages, all with the same HTML template. They were littered with HTML errors that caused parsers to choke, and all their styling was inline or with `` etc.: no classes or IDs to help navigate the DOM. After fighting all day with the "right" approach, I finally switched to a regex solution and had it working in an hour. – Paul A Jungwirth Sep 07 '12 at 07:14
42

@CharlesDuffy: definitely less fragile. When the third-party changes their html, they are much more likely to change the structure (breaking your xpaths) than the leaf nodes you are scraping. Scraping is not parsing. Scraping is pulling specific bits of data from a puddle of designer contaminated crap you don't care about. You DO NOT WANT to parse that puddle. You want to do only the absolute minimum amount of "parsing" that will get you your data. You don't CARE about the structure. You care about your bits of data. – Michael Johnston Nov 19 '13 at 03:23

score 2310 · Answer 3 · edited Aug 22 '22 at 12:51

2310

I think the flaw here is that HTML is a Chomsky Type 2 grammar (context free grammar) and a regular expression is a Chomsky Type 3 grammar (regular grammar). Since a Type 2 grammar is fundamentally more complex than a Type 3 grammar (see the Chomsky hierarchy), you can't possibly make this work.

But many will try, and some will even claim success - but until others find the fault and totally mess you up.

edited Aug 22 '22 at 12:51

Ash

60,973
31
151
169

answered Nov 18 '09 at 18:42

NealB

16,670
2
39
60

276

The OP is asking to parse a very limited subset of XHTML: start tags. What makes (X)HTML a CFG is its potential to have elements between the start and end tags of other elements (as in a grammar rule `A -> s A e`). (X)HTML does *not* have this property *within* a start tag: a start tag cannot contain other start tags. The subset that the OP is trying to parse is not a CFG. – LarsH Mar 02 '12 at 08:43
129

In CS theory, regular languages *are* a strict subset of context-free languages, but regular expression implementations in mainstream programming languages are more powerful. As http://www.noulakaz.net/weblog/2007/03/18/a-regular-expression-to-check-for-prime-numbers/ describes, so-called "regular expressions" can check for prime numbers in unary, which is certainly something that a regular expression from CS theory can't accomplish. – Adam Mihalcin Mar 19 '12 at 23:50
2

@LarsH, that may be strictly true, but only if you can depend on well-formedness. To be able to reliably parse even start tags one would have to accommodate a number of workarounds for (X)HTML syntax errors implemented in real world user agents, and even then probably cross fingers and pray. – eyelidlessness May 21 '12 at 21:04
18

@eyelidlessness: the same "only if" applies to all CFGs, does it not? I.e. if the (X)HTML input is not well-formed, not even a full-blown XML parser will work reliably. Maybe if you give examples of the "(X)HTML syntax errors implemented in real world user agents" you're referring to, I'll understand what you're getting at better. – LarsH May 22 '12 at 05:09
100

@AdamMihalcin is exactly right. Most extant regex engines are more powerful than Chomsky Type 3 grammars (eg non-greedy matching, backrefs). Some regex engines (such as Perl's) are Turing complete. It's true that even those are poor tools for parsing HTML, but this oft-cited argument is not the reason why. – dubiousjim May 31 '12 at 13:44
5

You are correct, I just want to drop this: You can write a finite state-machine that is equivalent to any regex expression (finite state-machines are equivalent in power to Type 3 languages.) But to parse HTML you need memory, there is this thing called pushdown automaton that is basically an state-machine with a stack to store values. That can be used to parse HTML, unfortunately it is pretty hard to describe a pushdown automaton in text language (like you can represent state-machines in regex,) it is easier to program it yourself. – Hoffmann Aug 01 '14 at 14:03
3

I used regex for a long time before learning the theory and when I was first told you can't parse things with regex I said that was nonsense which is kind of true, it depends what you mean. Language is ambiguous. You can't parse HTML using *only* regex. I was using regex but additionally with functions that provided the higher level elements for parsing such as maintaining a stack of the current nesting. I wouldn't try using regex alone for parsing anything complex even if it had added features to make it possible. – jgmjgm Sep 06 '15 at 23:52
7

To say the grammar of language A dictates it's parsing capabilities of another language B based on its grammar, is not valid. For example, just because HTML is Chomsky Type 2 language, doesn't mean you could write pure HTML which could parse any Chomsky Type 3 language. HTML itself is not a language with any features that give it the ability to parse other languages. Please don't say "Javascript", because javascript is not parsed by something written in HTML. – AaronLS Nov 24 '15 at 23:54
7

However, you are on the right track. Since HTML is a Chomsky Type 2 language, then to parse a Chomsky Type 2 language you generally need a stack capability within the parsing language(to track context). Regex doesn't have stack management capability: not because it is a Chomsky Type 3, but simply because the language was not designed with that capability. With some support for some extended constructs like recursion, it is possible in Regex, but would not be easy. Just as HTML lacks any capabilities to parse other languages, Regex lacks a stack capability needed to parse HTML. – AaronLS Nov 25 '15 at 00:03
3

FWIW HTML is not context-free (although the ways in which it is not are not relevant to this problem). For example, you cannot have unique ids in a context-free grammar. – Tgr Jan 16 '17 at 05:00
6

RegEx hasn't been limited to regular languages for 30 years now. – Erik Reppen Oct 30 '17 at 20:37

score 1170 · Answer 4 · edited May 23 '17 at 12:34

1170

Disclaimer: use a parser if you have the option. That said...

This is the regex I use (!) to match HTML tags:

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

It may not be perfect, but I ran this code through a lot of HTML. Note that it even catches strange things like <a name="badgenerator"">, which show up on the web.

I guess to make it not match self contained tags, you'd either want to use Kobi's negative look-behind:

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

or just combine if and if not.

To downvoters: This is working code from an actual product. I doubt anyone reading this page will get the impression that it is socially acceptable to use regexes on HTML.

Caveat: I should note that this regex still breaks down in the presence of CDATA blocks, comments, and script and style elements. Good news is, you can get rid of those using a regex...

edited May 23 '17 at 12:34

Community

1
1

answered Nov 15 '09 at 06:37

itsadok

28,822
30
126
171

121

I would go with something that works on sane things than weep about not being universally perfect :-) – prajeesh kumar May 10 '12 at 03:44
23

so you do not actually solve the parsing problem with regexp only but as a part of the parser this may work. PS: working product doesn't mean good code. No offence, but this is how industrial programming works and gets their money – mishmashru Apr 19 '13 at 12:18
43

Your regex starts fail on the very shortest possible, valid HTML: ` <`. Simple `' <'.match(/<(?:"[^"]*"['"]*|'[^']*'['"]*|[^'">])+>/g)` returns `[" ", "", "<"]` while should `["", ""]`. – May 01 '14 at 16:48
3

if we're just trying to match & not match the examples given, /<.([^r>][^>]*)?>/g works :-) // javascript: '

'.match(/<.([^r>][^>]*)?>/g)
– imma May 22 '14 at 16:14
There is a difference between pattern matching a fragment of html and pattern matching html while ensuring a valid structure is returned. Tokenising HTML is probably easy with regex but then try dealing with: – jgmjgm Sep 06 '15 at 23:55
2
"Is someone using CDATA inside HTML?" - yes, I do. It takes less bytes if you show HTML source code in `
```
` tags.
```
– cweiske Oct 14 '15 at 10:56
Your regex [fails with three false positives](https://regex101.com/r/WfRjbO/2) in the basic set (first group after the blank initial line). The [regex I use to detect _possible_ HTML](https://regex101.com/r/GIzRty/18) (detection, **not** parsing!) does not suffer these failures, additionally covers DOCTYPE and encoded entities. – amcgregor Apr 08 '20 at 17:32
1

This one for Python https://regex101.com/r/6IbTnI/1 , this one for PCRE https://regex101.com/r/p0t1H8/1 – Oct 01 '20 at 20:03
This partially matches comments, but not the whole thing. – Cody Nov 18 '21 at 00:08
`<42>These shouldn't match either42>`. Credit to LiveOverflow's Generic HTML Sanitizer Bypass Investigation – Cameron Tacklind Jul 09 '23 at 08:28

score 589 · Answer 5 · edited Nov 10 '21 at 00:06

589

There are people that will tell you that the Earth is round (or perhaps that the Earth is an oblate spheroid if they want to use strange words). They are lying.

There are people that will tell you that Regular Expressions shouldn't be recursive. They are limiting you. They need to subjugate you, and they do it by keeping you in ignorance.

You can live in their reality or take the red pill.

Like Lord Marshal (is he a relative of the Marshal .NET class?), I have seen the ~~Underverse~~ Stack Based Regex-Verse and returned with ~~powers~~ knowledge you can't imagine. Yes, I think there were an Old One or two protecting them, but they were watching football on the TV, so it wasn't difficult.

I think the XML case is quite simple. The RegEx (in the .NET syntax), deflated and coded in base64 to make it easier to comprehend by your feeble mind, should be something like this:

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=

The options to set is RegexOptions.ExplicitCapture. The capture group you are looking for is ELEMENTNAME. If the capture group ERROR is not empty then there was a parsing error and the Regex stopped.

If you have problems reconverting it to a human-readable regex, this should help:

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

If you are unsure, no, I'm NOT kidding (but perhaps I'm lying). It WILL work. I've built tons of unit tests to test it, and I have even used (part of) the conformance tests. It's a tokenizer, not a full-blown parser, so it will only split the XML into its component tokens. It won't parse/integrate DTDs.

Oh... if you want the source code of the regex, with some auxiliary methods:

regex to tokenize an xml or the full plain regex

edited Nov 10 '21 at 00:06

romellem

5,792
1
32
64

answered Mar 08 '11 at 13:30

xanatos

109,618
12
197
280

72

not-sure-if-serious.jpg -- hopefully this is brilliant satire – Brad Mace Mar 08 '11 at 14:53
7

@bemace You can try it... In a VM... disconnected from the Internet and from your LAN... Using a 10 foot pole to run it! :-) – xanatos Mar 08 '11 at 14:58
85

Good Lord, it's massive. My biggest question is why? You realize that all modern languages have XML parsers, right? You can do all that in like 3 lines and be sure it'll work. Furthermore, do you also realize that pure regex is **provably** unable to do certain things? Unless you've created a hybrid regex/imperative code parser, but it doesn't look like you have. Can you compress random data as well? – Justin Morgan - On strike Mar 08 '11 at 15:23
153

@Justin I don't need a reason. It could be done (and it wasn't illegal/immoral), so I have done it. There are no limitations to the mind except those we acknowledge (Napoleon Hill)... Modern languages can parse XML? Really? And I thought that THAT was illegal! :-) – xanatos Mar 08 '11 at 15:31
6

Well, we're talking about the theoretical limits of the language; it's not like we just haven't figured out how to do it yet. If you use pure regex, there's always going to be some (X)HTML valid code that breaks it. Maybe it's `` or maybe it's a certain nesting depth. Not that I didn't find your post funny (Old Ones - hah!) – Justin Morgan - On strike Mar 08 '11 at 15:42
10

Don't try it! If you do, the entire internet will be compressed to a quantum singularity and sucked down the rabbit hole! – Christian Hayter Mar 08 '11 at 16:47
96

Sir, I'm convinced. I'm going to use this code as part of the kernel for my perpetual-motion machine--can you believe those fools at the patent office keep rejecting my application? Well, I'll show them. I'll show them all! – Justin Morgan - On strike Mar 08 '11 at 17:55
6

@Justin Unless there is a bug, or unless the memory becomes full, I'm pretty sure that any VALID XML can be tokenized. As @John-David Dalton noticed, the specifics of XML are given in Regex-like expressions, so it was quite easy (if not long and harduous) – xanatos Mar 08 '11 at 18:35
4

Does it work for ``? Because that is in fact valid. So is stuff like ``. There's a LOT of stuff that looks "wrong" but is still valid XML. – Justin Morgan - On strike Mar 08 '11 at 21:51
6

@justin The second one is illegal, you can't escape the quotes with a \ . The first one will work if you close the foo. – xanatos Mar 09 '11 at 01:46
4

@justin And if you don't trust me, http://stackoverflow.com/questions/1222367/escape-quote-character-in-xml – xanatos Mar 09 '11 at 01:54
3

Huh, looks like I stand corrected on that one. Fair enough. The basic point is more or less the same, though: Just because you haven't figured out how to break it yet, that doesn't mean it always works. And if it doesn't always work, what's the point? An HTML parser will be more practical AND catch everything. – Justin Morgan - On strike Mar 09 '11 at 15:06
34

@Justin So an Xml Parser is by definition bug free, while a Regex isn't? Because if an Xml Parser isn't bug free by definition there could be an xml that make it crash and we are back to step 0. Let say this: both the Xml Parser and this Regex try to be able to parse all the "legal" XML. They CAN parse some "illegal" XML. Bugs could crash both of them. C# XmlReader is surely more tested than this Regex. – xanatos Mar 09 '11 at 15:08
44

No, nothing is bug free: 1) All programs contain at least one bug. 2) All programs contain at least one line of unnecessary source code. 3) By #1 and #2 and using logical induction, it's a simple matter to prove that any program can be reduced to a single line of code with a bug. (from Learning Perl) – Scott Weaver Feb 16 '12 at 00:53
24

Nope, not all XML parsers are free of defects. Not all cars are free of defects, but it's a lot easier to buy one than it is to grow a mutant ant big enough to ride. You've spent hours constructing a mutant ant recipe which *may or may not* work at all, and may even be biologically impossible. Meanwhile, there's a perfectly good car sitting there. – Justin Morgan - On strike May 16 '12 at 19:41
9

The .NET regular language *does* span XML, and so you *can* tokenize XML with a .NET regular expression. Tokenization and parsing are very very far from the same. The above regex will accept (I presume). It is a valid sequence of Xml tokens. This string is in the *language* of XML tokens. It is not in the language of XML, but that doesn't mean it cannot be tokenized. Just because you cannot parse something doesn't mean that it can't be tokenized. LR(0) parsers can't parse binary strings "00011", but the regex [01]* sure can tokenize them. – Michael Graczyk Jul 16 '12 at 02:51
LR(0) can't parse them because they are left recursive, btw. – Michael Graczyk Jul 16 '12 at 02:51
3

@MichaelGraczyk I remember correctly, the above regex *won't* accept ``. It is a stateful tokenizer, not a stateless tokenizer. – xanatos Jul 16 '12 at 04:32
4

In that case, it isn't a *regular* expression proper. If it uses backtracking at all, or for whatever reason cannot be expressed in terms of empty strings, literals, and the empty set with concatenations, alternations, Kleene stars thereof (inductive concatenations), then it isn't *formally* regular. A lot of people here seem to think that all "regular expressions" are true, formal *regular* expressions. It's true that Thompson NFA regular expressions are not true *regular expressions*, and are not recursive. However, PCRE regex is not truly *regular*, and hence can be recursive. – Michael Graczyk Jul 16 '12 at 05:00
2

Of course, you never said that it was a proper regular expression. You just accurately stated that it would tokenize XML. – Michael Graczyk Jul 16 '12 at 05:00
1

Actually, an algorithm **CAN** be made to compress random data. It would search through all seeds and compare them to the random data to find what seed was used, and find the algorithm used. Then all of that random data can be compressed down to a seed, length, and algorithm. **Only problem: it would take *days*.** :-) – uınbɐɥs Aug 02 '12 at 04:37
5

@ShaquinTrifonoff - Then it's not actually random. [I think your idea of random data is different from mine](http://en.wikipedia.org/wiki/Lossless_data_compression#The_Million_Random_Number_Challenge). – Justin Morgan - On strike Aug 09 '12 at 19:38
@JustinMorgan - You're right. I was thinking of 'normal' random numbers produced by the browser - see [Temporary User Tracking In Major Browsers](http://packetstorm.wowhacker.com/papers/general/Temporary_User_Tracking_in_Major_Browsers.pdf). That document was originally [here](http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdf), but has since been removed. – uınbɐɥs Aug 09 '12 at 21:04
3

This isn't regex, this is full blown parser! While it's perfectly fine to tokenize bits of string by regex, you need some functions around that to make it into a real parser, and that's exactly what this is. By "parsing html with regex", I imagine regex-only-"parser", which is obviously impossible. This is just C# parser that uses regexes every now and then, not regex parser. – enrey Jun 01 '13 at 12:59
This is certainly the second best answer here, particularly because the other top answers make fun of the idea of parsing HTML with regex while this one literally succeeds at just that. The only dispute is that PCRE is not _mathematically_ considered a regular expression language: the naysayers hinge their argument on the opinion that regular expressions cannot be recursive. My response? The OP said nothing about regular expressions and only asked for a regex. And yes there is a difference, you just need to take the red pill to see it: http://www.rexegg.com/regex-vs-regular-expression.html – Pluto Apr 22 '21 at 15:36
If anyone wants to deflate the base64 string (saved in my case as xml-parser.b64) on the command prompt, you can try this: `printf "\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\x00" | cat - <(base64 -d xml-regex.b64 ) | gunzip` – Alexander Stumpf Jun 20 '22 at 09:35

score 318 · Answer 6 · edited Apr 23 '19 at 16:44

318

In shell, you can parse HTML using sed:

Turing.sed
Write HTML parser (homework)
???
Profit!

Related (why you shouldn't use regex match):

edited Apr 23 '19 at 16:44

Alan H.

16,219
17
80
113

answered Feb 15 '10 at 00:55

dubiousjim

4,722
1
36
34

4

I’m afraid you did not get the joke, @kenorb. Please, read the question and the accepted answer once more. This is not about HTML parsing tools in general, nor about HTML parsing shell tools, it’s about parsing HTML via regexes. – Palec Oct 13 '15 at 08:12
1

@Palec I don't get the joke either. Is it nearly impossible to parse HTML with regex? – Honinbo Shusaku Mar 24 '17 at 11:49
3

No, @Abdul. It is completely, provably (in the mathematical sense) impossible. – Palec Mar 24 '17 at 13:24
@Palec Is that mathematical sense in relation to VladGudim's answer on the grammar types? Or something else? – Honinbo Shusaku Mar 24 '17 at 13:47
6

Yes, that answer summarizes it well, @Abdul. Note that, however, regex implementations are not really *regular* expressions in the mathematical sense -- they have constructs that make them stronger, often Turing-complete (equivalent to Type 0 grammars). The argument breaks with this fact, but is still somewhat valid in the sense that regexes were never meant to be capable of doing such a job, though. – Palec Mar 24 '17 at 14:24
2

And by the way, the joke I referred to was the content of this answer before kenorb's (radical) edits, specifically revision 4, @Abdul. – Palec Mar 24 '17 at 14:26
12

The funny thing is that OP never asked to parse html using regex. He asked to match text (which happens to be HTML) using regex. Which is perfectly reasonable. – Paralife Mar 29 '18 at 15:29

score 293 · Answer 7 · edited Feb 23 '20 at 04:43

I agree that the right tool to parse XML and especially HTML is a parser and not a regular expression engine. However, like others have pointed out, sometimes using a regex is quicker, easier, and gets the job done if you know the data format.

Microsoft actually has a section of Best Practices for Regular Expressions in the .NET Framework and specifically talks about Consider[ing] the Input Source.

Regular Expressions do have limitations, but have you considered the following?

The .NET framework is unique when it comes to regular expressions in that it supports Balancing Group Definitions.

See Matching Balanced Constructs with .NET Regular Expressions
See .NET Regular Expressions: Regex and Balanced Matching
See Microsoft's docs on Balancing Group Definitions

For this reason, I believe you CAN parse XML using regular expressions. Note however, that it must be valid XML (browsers are very forgiving of HTML and allow bad XML syntax inside HTML). This is possible since the "Balancing Group Definition" will allow the regular expression engine to act as a PDA.

Quote from article 1 cited above:

.NET Regular Expression Engine

As described above properly balanced constructs cannot be described by a regular expression. However, the .NET regular expression engine provides a few constructs that allow balanced constructs to be recognized.

(?<group>) - pushes the captured result on the capture stack with the name group.

(?<-group>) - pops the top most capture with the name group off the capture stack.

(?(group)yes|no) - matches the yes part if there exists a group with the name group otherwise matches no part.

These constructs allow for a .NET regular expression to emulate a restricted PDA by essentially allowing simple versions of the stack operations: push, pop and empty. The simple operations are pretty much equivalent to increment, decrement and compare to zero respectively. This allows for the .NET regular expression engine to recognize a subset of the context-free languages, in particular the ones that only require a simple counter. This in turn allows for the non-traditional .NET regular expressions to recognize individual properly balanced constructs.

Consider the following regular expression:

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

Use the flags:

Singleline
IgnorePatternWhitespace (not necessary if you collapse regex and remove all whitespace)
IgnoreCase (not necessary)

Regular Expression Explained (inline)

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

You can try this at A Better .NET Regular Expression Tester.

I used the sample source of:

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

This found the match:

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

although it actually came out like this:

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

Lastly, I really enjoyed Jeff Atwood's article: Parsing Html The Cthulhu Way. Funny enough, it cites the answer to this question that currently has over 4k votes.

@C0deH4cker You are correct, the expression should have `\s+` instead of `\s*`. — Sam, Jul 06 '12 at 22:33
Not that I really understand it, but I think your regex fails on `` — Scheintod, Sep 27 '13 at 17:05
@Scheintod Thank you for the comment. I updated the code. The previous expression failed for self closing tags that had a `/` somewhere inside which failed for your `` html. — Sam, Sep 27 '13 at 19:00
It's an interesting regex approach! I just noticed that if you add `
` (with a space after the slash) inside a child of the `
` you are looking for, then the pattern will also match the closing `` because the self-closing tag pattern should be `<[^>]*/\s*>`. Spaces are also allowed in closing tags. I came up with these minor corrections: https://regex101.com/r/tUtKXj/1 So this typically shows that even advanced regular expressions like your very nice one may break on valid HTML if we don't think at everything :-/ — Patrick Janser, Jun 02 '23 at 10:18

score 267 · Answer 8 · edited May 12 '15 at 18:54

267

I suggest using QueryPath for parsing XML and HTML in PHP. It's basically much the same syntax as jQuery, only it's on the server side.

edited May 12 '15 at 18:54

davidism

121,510
29
395
339

answered Nov 13 '09 at 23:44

John Fiala

4,561
3
30
26

9

@Kyle—jQuery does not parse XML, it uses the client's built–in parser (if there is one). Therefore you do not need jQuery to do it, but as little as two lines of [plain old JavaScript](https://developer.mozilla.org/en-US/docs/Parsing_and_serializing_XML). If there is no built–in parser, jQuery will not help. – RobG Oct 31 '13 at 06:25
2

@RobG Actually jQuery uses the DOM, not the built-in parser. – Qix - MONICA WAS MISTREATED Sep 22 '14 at 03:49
12

@Qix—you'd better tell the authors of the documentation then: "*jQuery.parseXML uses the native parsing function of the browser…*". Source: [*jQuery.parseXML()*](http://api.jquery.com/jQuery.parseXML/) – RobG Sep 22 '14 at 05:01
6

Having come here from the meme question (http://meta.stackexchange.com/questions/19478/the-many-memes-of-meta/19479#19479), I love that one of the answers is 'Use jQuery' – Jorn Apr 01 '16 at 21:09

score 236 · Answer 9 · answered Jan 27 '10 at 12:54

236

While the answers that you can't parse HTML with regexes are correct, they don't apply here. The OP just wants to parse one HTML tag with regexes, and that is something that can be done with a regular expression.

The suggested regex is wrong, though:

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

If you add something to the regex, by backtracking it can be forced to match silly things like <a >>, [^/] is too permissive. Also note that <space>*[^/]* is redundant, because the [^/]* can also match spaces.

My suggestion would be

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

Where (?<! ... ) is (in Perl regexes) the negative look-behind. It reads "a <, then a word, then anything that's not a >, the last of which may not be a /, followed by >".

Note that this allows things like <a/ > (just like the original regex), so if you want something more restrictive, you need to build a regex to match attribute pairs separated by spaces.

answered Jan 27 '10 at 12:54

moritz

12,710
1
41
63

31

+1 for noting that the question is not about parsing full (X)HTML, it's about matching (X)HTML open tags. – LarsH Sep 08 '12 at 02:26
11

Something else most of the answers seem to ignore, is that an HTML parser can very well use regular expressions in its implementation for parts of HTML, and I would be surprised if most parsers didn't do this. – Thayne Mar 26 '15 at 19:15
2

@Thayne Exactly. When parsing individual tags, a regular expression is the right tool for the job. It is quite ridiculous that one has to scroll halfway down the page to find a reasonable answer. The accepted answer is incorrect because it mixes up lexing and parsing. – kasperd Nov 22 '15 at 10:26
4

The answer given here will fail when an attribute value contains a '>' or '/' character. – Martin L Apr 21 '16 at 08:14
1

This will work incorrectly on HTML containing comments or CData sections. It will also not work correctly if a quoted attribute contains a `>` character. I agree what OP suggest *can* be done with a regex, but the one presented here is far to simplistic. – JacquesB Jul 30 '17 at 10:14
1

The `
` tag would like a word with you (easily fixed, I know, but still)...
– jimbobmcgee May 07 '20 at 18:28

score 196 · Answer 10 · edited Oct 05 '13 at 04:52

Sun Tzu, an ancient Chinese strategist, general, and philosopher, said:

It is said that if you know your enemies and know yourself, you can win a hundred battles without a single loss. If you only know yourself, but not your opponent, you may win or may lose. If you know neither yourself nor your enemy, you will always endanger yourself.

In this case your enemy is HTML and you are either yourself or regex. You might even be Perl with irregular regex. Know HTML. Know yourself.

I have composed a haiku describing the nature of HTML.

HTML has
complexity exceeding
regular language.

I have also composed a haiku describing the nature of regex in Perl.

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

score 193 · Answer 11 · edited Nov 25 '09 at 21:12

193

Try:

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

It is similar to yours, but the last > must not be after a slash, and also accepts h1.

edited Nov 25 '09 at 21:12

Peter Mortensen

30,738
21
105
131

answered Nov 13 '09 at 22:50

Kobi

135,331
41
252
292

115

Oops – Gareth Nov 13 '09 at 23:11
67

`>` is valid in an attribute value. Indeed, in the ‘canonical XML’ serialisation you must not use `>`. (Which isn't entirely relevant, except to emphasise that `>` in an attribute value is not at all an unusual thing.) – bobince Nov 14 '09 at 00:15
5

@Kobi: what does the exlamation mark (the one you placed tpward the end) mean in a regexp? – Marco Demaio Apr 30 '11 at 17:16
6

@bobince: are u sure? I don't understand anymore, so is this valid HTML too: `
hello
` – Marco Demaio Apr 30 '11 at 17:31
3

@MarcoDemaio - `>` does not have to be escaped in an attribute value, but `<` does. So this is would be valid HTML: `
hello
` – Daniel Haley Oct 12 '16 at 22:11
This also matches ``. – fritzmg Mar 03 '18 at 09:32

meder omuraliev · Answer 12 · 2009-11-15T14:44:04.163

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

Output:

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

Basically just define the element node names that are self closing, load the whole html string into a DOM library, grab all elements, loop through and filter out ones which aren't self closing and operate on them.

I'm sure you already know by now that you shouldn't use regex for this purpose.

If you're dealing with real XHTML then append getElementsByTagName with `NS` and specify the namespace. — meder omuraliev, Nov 15 '09 at 14:39

score 153 · Answer 13 · answered Nov 16 '09 at 23:15

153

I don't know your exact need for this, but if you are also using .NET, couldn't you use Html Agility Pack?

Excerpt:

It is a .NET code library that allows you to parse "out of the web" HTML files. The parser is very tolerant with "real world" malformed HTML.

answered Nov 16 '09 at 23:15

GONeale

26,302
21
106
149

CodePlex closed down (but this one is in the CodePlex archive). Perhaps update? – Peter Mortensen Aug 14 '20 at 15:47

score 142 · Answer 14 · edited Mar 19 '12 at 15:04

142

You want the first > not preceded by a /. Look here for details on how to do that. It's referred to as negative lookbehind.

However, a naïve implementation of that will end up matching <bar/></foo> in this example document

<foo><bar/></foo>

Can you provide a little more information on the problem you're trying to solve? Are you iterating through tags programatically?

edited Mar 19 '12 at 15:04

Ry-

218,210
55
464
476

answered Nov 13 '09 at 22:47

Jherico

28,584
8
61
87

score 110 · Answer 15 · edited Mar 19 '12 at 15:02

If you need this for PHP:

The PHP DOM functions won't work properly unless it is properly formatted XML. No matter how much better their use is for the rest of mankind.

simplehtmldom is good, but I found it a bit buggy, and it is is quite memory heavy [Will crash on large pages.]

I have never used querypath, so can't comment on its usefulness.

Another one to try is my DOMParser which is very light on resources and I've been using happily for a while. Simple to learn & powerful.

For Python and Java, similar links were posted.

For the downvoters - I only wrote my class when the XML parsers proved unable to withstand real use. Religious downvoting just prevents useful answers from being posted - keep things within perspective of the question, please.

score 100 · Answer 16 · edited Oct 18 '17 at 07:33

Here's the solution:

<?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]);
?>

To test it deeply, I entered in the string auto-closing tags like:

<hr />
<br/>
<br>

I also entered tags with:

one attribute
more than one attribute
attributes which value is bound either into single quotes or into double quotes
attributes containing single quotes when the delimiter is a double quote and vice versa
"unpretty" attributes with a space before the "=" symbol, after it and both before and after it.

Should you find something which does not work in the proof of concept above, I am available in analyzing the code to improve my skills.

<EDIT> I forgot that the question from the user was to avoid the parsing of self-closing tags. In this case the pattern is simpler, turning into this:

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

The user @ridgerunner noticed that the pattern does not allow unquoted attributes or attributes with no value. In this case a fine tuning brings us the following pattern:

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

</EDIT>

Understanding the pattern

If someone is interested in learning more about the pattern, I provide some line:

the first sub-expression (\w+) matches the tag name
the second sub-expression contains the pattern of an attribute. It is composed by:
1. one or more whitespaces \s+
2. the name of the attribute (\w+)
3. zero or more whitespaces \s* (it is possible or not, leaving blanks here)
4. the "=" symbol
5. again, zero or more whitespaces
6. the delimiter of the attribute value, a single or double quote ('|"). In the pattern, the single quote is escaped because it coincides with the PHP string delimiter. This sub-expression is captured with the parentheses so it can be referenced again to parse the closure of the attribute, that's why it is very important.
7. the value of the attribute, matched by almost anything: (.*?); in this specific syntax, using the greedy match (the question mark after the asterisk) the RegExp engine enables a "look-ahead"-like operator, which matches anything but what follows this sub-expression
8. here comes the fun: the \4 part is a backreference operator, which refers to a sub-expression defined before in the pattern, in this case, I am referring to the fourth sub-expression, which is the first attribute delimiter found
9. zero or more whitespaces \s*
10. the attribute sub-expression ends here, with the specification of zero or more possible occurrences, given by the asterisk.
Then, since a tag may end with a whitespace before the ">" symbol, zero or more whitespaces are matched with the \s* subpattern.
The tag to match may end with a simple ">" symbol, or a possible XHTML closure, which makes use of the slash before it: (/>|>). The slash is, of course, escaped since it coincides with the regular expression delimiter.

Small tip: to better analyze this code it is necessary looking at the source code generated since I did not provide any HTML special characters escaping.

Does not match valid tags having attributes with no value, i.e. ` — ridgerunner, Jul 25 '11 at 15:01
@ridgerunner: Thanks very much for your comment. In that case the pattern must change a bit: $pattern = '/<(\w+)(\s+(\w+)(\s*\=\s*(\'|"|)(.*?)\\5\s*)?)*\s*>/'; I tested it and works in case of non-quoted attributes or attributes with no value. — yodabar, Jul 25 '11 at 16:41
How about a space before the tag name: `< a href="http://wtf.org" >` I'm pretty sure it is legal, but you don't match it. — Floris, Oct 05 '13 at 04:58
NO sorry, whitespaces before a tagname are illegal. Beyond being "pretty sure" why don't you provide some evidences of your objection? Here are mine, http://www.w3.org/TR/xml11/#sec-starttags referred to XML 1.1, and you can find the same for HTML 4, 5 and XHTML, as a W3C validation would also warn if you make a test. As a lot of other blah-blah-poets around here, I did not still receive any intelligent argumentation, apart some hundred of minus to my answers, to demonstrate where my code fails according to the _rules of contract_ specified in the question. I would only welcome them. — yodabar, Oct 06 '13 at 18:03
XML tags can contain colons, e.g. ``, is that not so in HTML? — Qwertie, Jul 17 '20 at 21:54

score 94 · Answer 17 · edited Apr 04 '14 at 08:11

94

Whenever I need to quickly extract something from an HTML document, I use Tidy to convert it to XML and then use XPath or XSLT to get what I need. In your case, something like this:

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

edited Apr 04 '14 at 08:11

Amal Murali

75,622
18
128
150

answered Nov 18 '09 at 14:50

Sembiance

833
3
11
14

score 91 · Answer 18 · answered Nov 16 '09 at 18:34

I used a open source tool called HTMLParser before. It's designed to parse HTML in various ways and serves the purpose quite well. It can parse HTML as different treenode and you can easily use its API to get attributes out of the node. Check it out and see if this can help you.

score 87 · Answer 19 · edited Oct 28 '20 at 23:11

87

I like to parse HTML with regular expressions. I don't attempt to parse idiot HTML that is deliberately broken. This code is my main parser (Perl edition):

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

It's called htmlsplit, splits the HTML into lines, with one tag or chunk of text on each line. The lines can then be processed further with other text tools and scripts, such as grep, sed, Perl, etc. I'm not even joking :) Enjoy.

It is simple enough to rejig my slurp-everything-first Perl script into a nice streaming thing, if you wish to process enormous web pages. But it's not really necessary.

HTML Split

Some better regular expressions:

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

They are good for XML / XHTML.

With minor variations, it can cope with messy HTML... or convert the HTML -> XHTML first.

The best way to write regular expressions is in the Lex / Yacc style, not as opaque one-liners or commented multi-line monstrosities. I didn't do that here, yet; these ones barely need it.

edited Oct 28 '20 at 23:11

Peter Mortensen

30,738
21
105
131

answered Jul 11 '11 at 17:13

Sam Watkins

7,819
3
38
38

57

"I don't attempt to parse idiot HTML that is deliberately broken." How does your code know the difference? – Kevin Panko Jul 26 '11 at 20:38
Well it doesn't matter much if the HTML is broken or not. The thing will still split HTML into tags and text. The only thing that could foul it up is if people include unescaped < or > characters in text or attributes. In practise, my tiny HTML splitter works well. I don't need an enormous monstrosity chock full of heuristics. Simple solutions are not for everyone...! – Sam Watkins Mar 08 '12 at 03:22
I added some simpler regexps for extracting tags, text, and attributes, for XML / XHTML. – Sam Watkins May 22 '12 at 08:00
5

(get attributes bug 1) `/(\w+)="(.*?)"/` assumes double quotes. It will miss values in single quotes. In html version 4 and earlier unquoted value is allowed, if it is a simple word. – David Andersson Sep 11 '16 at 08:23
4

(get attributes bug 2) `/(\w+)="(.*?)"/` may falsely match text that looks like an attribute within an attribute, e.g. ``. If applied globally, it will also match such things in ordinary text or in html comments. – David Andersson Sep 11 '16 at 08:28
3

(get attributes bug 3) `/(\w+)="(.*?)"/` Optional whitespace should be allowed around the equal sign. – David Andersson Sep 11 '16 at 08:42
4

(html split bug 1) `s/>/>\n/g` Since ">" is allowed in data, this may split text lines and confuse subsequent processing. – David Andersson Sep 11 '16 at 09:09
@DavidAndersson, as I said above those regexps are for XML / XHTML, which has a more strict syntax and is easier to parse. If you want a "perfect" parser that can cope with any difficult or malformed HTML input, maybe it's better not to use regexps. But I've found that regexps are more than sufficient for all the html processing tasks I have ever needed to do, and if they don't work for some reason I can tweak them to make them work. In face regexps can be more flexible with some types of broken html that would be rejected by a fussy parser. – Sam Watkins Sep 13 '16 at 04:52
2

The four bugs above apply to xhtml too. (Except the last part of *get attributes bug 1* does not apply to xhtml.) If you put these regexps into production code, would you notice if they occasionally miss input data and/or generate additional fake data? (You have a case for using regexps when trying to parse malformed html, but I think these are too simplistic.) – David Andersson Sep 13 '16 at 06:27

score 71 · Answer 20 · edited May 19 '15 at 16:20

There are some nice regexes for replacing HTML with BBCode here. For all you nay-sayers, note that he's not trying to fully parse HTML, just to sanitize it. He can probably afford to kill off tags that his simple "parser" can't understand.

For example:

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

score 71 · Answer 21 · edited Aug 14 '20 at 16:06

71

About the question of the regular expression methods to parse (x)HTML, the answer to all of the ones who spoke about some limits is: you have not been trained enough to rule the force of this powerful weapon, since nobody here spoke about recursion.

A regular expression-agnostic colleague notified me this discussion, which is not certainly the first on the web about this old and hot topic.

After reading some posts, the first thing I did was looking for the "?R" string in this thread. The second was to search about "recursion".

No, holy cow, no match found. Since nobody mentioned the main mechanism a parser is built onto, I was soon aware that nobody got the point.

If an (x)HTML parser needs recursion, a regular expression parser without recursion is not enough for the purpose. It's a simple construct.

The black art of regular expressions is hard to master, so maybe there are further possibilities we left out while trying and testing our personal solution to capture the whole web in one hand... Well, I am sure about it :)

Here's the magic pattern:

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

Just try it. It's written as a PHP string, so the "s" modifier makes classes include newlines.

Here's a sample note on the PHP manual I wrote in January: Reference

(Take care. In that note I wrongly used the "m" modifier; it should be erased, notwithstanding it is discarded by the regular expression engine, since no ^ or $ anchoring was used).

Now, we could speak about the limits of this method from a more informed point of view:

according to the specific implementation of the regular expression engine, recursion may have a limit in the number of nested patterns parsed, but it depends on the language used
although corrupted, (x)HTML does not drive into severe errors. It is not sanitized.

Anyhow, it is only a regular expression pattern, but it discloses the possibility to develop of a lot of powerful implementations.

I wrote this pattern to power the recursive descent parser of a template engine I built in my framework, and performances are really great, both in execution times or in memory usage (nothing to do with other template engines which use the same syntax).

edited Aug 14 '20 at 16:06

Peter Mortensen

30,738
21
105
131

answered Jul 05 '10 at 14:16

yodabar

4,651
2
33
38

40

I'll put this in the "Regex which doesn't allow greater-than in attributes" bin. Check it against – Gareth Jul 05 '10 at 16:24
74

If you put something like that in production code, you would likely be shot by the maintainer. A jury would never convict him. – aehiilrs Jul 05 '10 at 16:33
@Gareth: thanks for your objection, but are you sure that putting a greater-than inside an attribute is a valid code? Well, also if not, this evidences another limit to add to the ones I listed above in case to create a greed parser for the real world... But it is not too much to demonstrate the way is not good, do you agree? There are other useful operators in RegExp which allow to check for next occurrences, this should be a proper use for them. – yodabar Jul 05 '10 at 17:40
1

@Bart K.: it is valid only in an HTML 4- document. XHTML documents need the five XML entities encoded. – yodabar Jul 06 '10 at 08:20
If your comments are aimed to nothing but criticize, I see no good results this discussion may reach. – yodabar Jul 06 '10 at 16:13
3

I was the first to say that my solution has some limits, but of course I am available to listen anyone who can help me in improving it. I posted something which costed me time and work, and which results are effective in a number of projects up and running. I thought it could help, proposing the way of a RegExp solution which nobody nearly spoke about (recursion), and which is the only way to parse nested markup patterns (through RegExp, of course). – yodabar Jul 06 '10 at 16:16
32

Regular expressions can't work because by definition they are not recursive. Adding a recursive operator to regular expressions basically makes a CFG only with poorer syntax. Why not use something designed to be recursive in the first place rather than violently insert recursion into something already overflowing with extraneous functionality? – Welbog Jul 06 '10 at 18:38
3

Once again... > is valid pretty much everywhere in XML, and thus in XHTML, see section 2.4 of the XML spec (at http://www.xml.com/axml/target.html#syntax for example) – mirod Jul 07 '10 at 04:55
1

You are right, the lesser-than only is not valid inside XML attributes. Thanks to your criticism, I implemented my solution so that it can parse *anything* inside the attributes :) Beside this, I implemented the parsing of XML prologue, DTDs and CDATA. The only upset is that the mod closed the possibility to answer this discussion for users with less than 10 points, so that I cannot post it. I twitted him the request to unlock it, but had no response. Come to me, enemies, I wait you! :) The more you are, the stronger I become! – yodabar Jul 09 '10 at 08:14
20

My objection isn't one of functionality it is one of time invested. The problem with RegEx is that by the time you post the cutsey little one liners it appears that you did something more efficiently ("See one line of code!"). And of course no one mentions the half hour (or 3) that they spent with their cheat-sheet and (hopefully) testing every possible permutation of input. And once you get past all that when the maintainer goes to figure out or validate the code they can't just look at it and see that it is right. The have to dissect the expression and essentially retest it all over again... – Oorang Jul 10 '10 at 15:11
17

... to know that it is good. And that will happen even with people who are *good* with regex. And honestly I suspect that overwhelming majority of people won't know it well. So you take one of the most notorious maintenance nightmares and combine it with recursion which is the *other* maintenance nightmare and I think to myself what I really need on my project is someone a little less clever. The goal is to write code that bad programmers can maintain without breaking the code base. I know it galls to code to the least common denominator. But hiring excellent talent is hard, and you often... – Oorang Jul 10 '10 at 15:17

score 66 · Answer 22 · edited Oct 28 '20 at 23:09

66

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

The parts explained:

<: Starting character

\s*: It may have whitespaces before the tag name (ugly, but possible).

(\w+): tags can contain letters and numbers (h1). Well, \w also matches '_', but it does not hurt I guess. If curious, use ([a-zA-Z0-9]+) instead.

[^/>]*: Anything except > and / until closing >

>: Closing >

UNRELATED

And to the fellows, who underestimate regular expressions, saying they are only as powerful as regular languages:

aⁿbaⁿbaⁿ which is not regular and not even context free, can be matched with ^(a+)b\1b\1$

Backreferencing FTW!

edited Oct 28 '20 at 23:09

Peter Mortensen

30,738
21
105
131

answered May 10 '12 at 13:53

daghan

948
10
18

@GlitchMr, that was his point. Modern regular expressions are not technically regular, nor is there any reason for them to be. – alanaktion Feb 02 '13 at 15:45
5

@alanaktion: The "modern" regular expressions (read: with Perl extensions) cannot match within `O(MN)` (M being regular expression length, N being text length). Backreferences are one of causes of that. The implementation in awk doesn't have backreferences and matches everything within `O(MN)` time. – Konrad Borowski Feb 14 '13 at 16:52
3

` Oops ` (quoting @Gareth - odd how people keep posting answers with this specific deficiency over and over. CDATA is kind of easy to overlook, but this is rather more basic) – Qwertie Jul 17 '20 at 21:59
1

This regex will not work if html tag will contains `/` in between. For example : `` – Debug Diva Oct 18 '22 at 11:07

score 63 · Answer 23 · answered Feb 04 '10 at 16:22

As many people have already pointed out, HTML is not a regular language which can make it very difficult to parse. My solution to this is to turn it into a regular language using a tidy program and then to use an XML parser to consume the results. There are a lot of good options for this. My program is written using Java with the jtidy library to turn the HTML into XML and then Jaxen to xpath into the result.

Lonnie Best · Answer 24 · 2016-05-31T07:23:30.850

56

If you're simply trying to find those tags (without ambitions of parsing) try this regular expression:

/<[^/]*?>/g

I wrote it in 30 seconds, and tested here: http://gskinner.com/RegExr/

It matches the types of tags you mentioned, while ignoring the types you said you wanted to ignore.

edited May 31 '16 at 07:23

answered Jun 01 '12 at 05:13

Lonnie Best

9,936
10
57
97

2

FYI, you don't need to escape angle brackets. Of course, it does no harm to escape them anyway, but look at the confusion you could have avoided. ;) – Alan Moore May 29 '16 at 07:47
I sometimes escape unnecessarily when I'm unsure if something is special character or not. I've edited the answer; it works the same but more concise. – Lonnie Best May 31 '16 at 07:23

slevithan · Answer 25 · 2012-05-29T00:01:51.930

It's true that when programming it's usually best to use dedicated parsers and APIs instead of regular expressions when dealing with HTML, especially if accuracy is paramount (e.g., if your processing might have security implications). However, I don’t ascribe to a dogmatic view that XML-style markup should never be processed with regular expressions. There are cases when regular expressions are a great tool for the job, such as when making one-time edits in a text editor, fixing broken XML files, or dealing with file formats that look like but aren’t quite XML. There are some issues to be aware of, but they're not insurmountable or even necessarily relevant.

A simple regex like <([^>"']|"[^"]*"|'[^']*')*> is usually good enough, in cases such as those I just mentioned. It's a naive solution, all things considered, but it does correctly allow unencoded > symbols in attribute values. If you're looking for, e.g., a table tag, you could adapt it as </?table\b([^>"']|"[^"]*"|'[^']*')*>.

Just to give a sense of what a more "advanced" HTML regex would look like, the following does a fairly respectable job of emulating real-world browser behavior and the HTML5 parsing algorithm:

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

The following matches a fairly strict definition of XML tags (although it doesn't account for the full set of Unicode characters allowed in XML names):

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

Granted, these don't account for surrounding context and a few edge cases, but even such things could be dealt with if you really wanted to (e.g., by searching between the matches of another regex).

At the end of the day, use the most appropriate tool for the job, even in the cases when that tool happens to be a regex.

score 54 · Answer 26 · answered Nov 15 '09 at 17:13

54

It seems to me you're trying to match tags without a "/" at the end. Try this:

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

answered Nov 15 '09 at 17:13

manixrock

2,533
4
24
29

10

This does not work. For the input '' the matches are x and y, although x is terminated. – ceving May 04 '11 at 16:33

score 51 · Answer 27 · answered Feb 09 '10 at 03:59

Although it's not suitable and effective to use regular expressions for that purpose sometimes regular expressions provide quick solutions for simple match problems and in my view it's not that horrbile to use regular expressions for trivial works.

There is a definitive blog post about matching innermost HTML elements written by Steven Levithan.

score 43 · Answer 28 · edited Aug 14 '20 at 16:00

If you only want the tag names, it should be possible to do this via a regular expression.

<([a-zA-Z]+)(?:[^>]*[^/] *)?>

should do what you need. But I think the solution of "moritz" is already fine. I didn't see it in the beginning.

For all downvoters: In some cases it just makes sense to use a regular expression, because it can be the easiest and quickest solution. I agree that in general you should not parse HTML with regular expressions.

But regular expressions can be a very powerful tool when you have a subset of HTML where you know the format and you just want to extract some values. I did that hundreds of times and almost always achieved what I wanted.

score 39 · Answer 29 · edited Aug 14 '20 at 15:59

The OP doesn't seem to say what he needs to do with the tags. For example, does he need to extract inner text, or just examine the tags?

I'm firmly in the camp that says a regular expression is not the be-all, end-all text parser. I've written a large amount of text-parsing code including this code to parse HTML tags.

While it's true I'm not all that great with regular expressions, I consider regular expressions just too rigid and hard to maintain for this sort of parsing.

score 33 · Answer 30 · edited Jul 05 '10 at 16:27

33

This may do:

<.*?[^/]>

Or without the ending tags:

<[^/].*?[^/]>

What's with the flame wars on HTML parsers? HTML parsers must parse (and rebuild!) the entire document before it can categorize your search. Regular expressions may be a faster / elegant in certain circumstances. My 2 cents...

edited Jul 05 '10 at 16:27

Kevin Panko

8,356
19
50
61

answered Apr 23 '10 at 06:38

Paul

171
2
10

4

` Oops ` (quoting @Gareth) – Qwertie Jul 17 '20 at 22:06

score 20 · Answer 31 · edited Aug 14 '20 at 15:57

20

I think this might work

<[a-z][^<>]*(?:(?:[^/]\s*)|(?:\s*[^/]))>

And that could be tested here.

As per W3Schools...

XML Naming Rules

XML elements must follow these naming rules:

Names can contain letters, numbers, and other characters
Names cannot start with a number or punctuation character
Names cannot start with the letters xml (or XML, Xml, etc.)
Names cannot contain spaces
Any name can be used, and no words are reserved.

And the pattern I used is going to adhere these rules.

edited Aug 14 '20 at 15:57

Peter Mortensen

30,738
21
105
131

answered May 26 '12 at 13:25

Cylian

10,970
4
42
55

80

**Warning:** w3schools should not be treated as an authoritative or reliable reference ([ref](http://w3fools.com/)). Anyway, the rules you listed only apply to the *names* of elements and attributes; attribute *values* are much more flexible. You might get away with disallowing `>` (which is legal but rarely used), but imagine an HREF attribute with no slashes! ;) – Alan Moore Jun 01 '12 at 07:25
7

This expression will work for many element names, however, the XML spec uses letter in the Unicode sense. There are legitimate element names which this won't match. – JamieSee Aug 24 '12 at 16:20
@AlanMoore href attribute with no slashes: `href="some_other_page.html"` – Solomon Ucko Mar 20 '18 at 16:18

score 7 · Answer 32 · edited Aug 14 '20 at 15:56

Here's a PCRE regular expression for XML/XHTML, built from a simplified EBNF syntax definition:

/
(?(DEFINE)
(?<tag> (?&tagempty) | (?&tagopen) ((?&textnode) | (?&tag) | (?&comment))* (?&tagclose))
(?<tagunnested> (?&tagempty) | (?&tagopen) ((?&textnode) | (?&comment))* (?&tagclose))
(?<textnode> [^<>]+)
(?<comment> <!--([\s\S]*?)-->)
(?<tagopen> < (?&tagname) (?&attrlist)? (?&ws)* >)
(?<tagempty> < (?&tagname) (?&ws)* (?&attrlist)? (?&ws)* \/>)
(?<tagclose> <\/ (?&tagname) (?&ws)* >)
(?<attrlist> ((?&ws)+ (?&attr))+)
(?<attr> (?&attrunquoted) | (?&attrsinglequoted) | (?&attrdoublequoted) | (?&attrempty))
(?<attrempty> (?&attrname))
(?<attrunquoted> (?&attrname) (?&ws)* = (?&ws)* (?&attrunquotedvalue))
(?<attrsinglequoted> (?&attrname) (?&ws)* = (?&ws)* ' (?&attrsinglequotedvalue) ')
(?<attrdoublequoted> (?&attrname) (?&ws)* = (?&ws)* " (?&attrdoublequotedvalue) ")
(?<tagname> (?&alphabets) ((?&alphabets) | (?&digits))*)
(?<attrname>(?&alphabets)+((?&alphabets)|(?&digits)|[:-]) )
(?<attrunquotedvalue> [^\s"'=<>`]+)
(?<attrsinglequotedvalue> [^']+)
(?<attrdoublequotedvalue> [^"]+)
(?<alphabets> [a-zA-Z])
(?<digits> [0-9])
(?<ws> \s)
)
(?&tagopen)
/x

This illustrates how to build regular expressions for context-free grammars. You can match other parts of the definition by changing the match on the last line from (?&tagopen) to e.g. (?&tagunnested)

The real question is: Should you do it?

For XML/XHTML the consensus is no!

Credits to nikic for supplying the idea.

score 6 · Answer 33 · answered May 10 '21 at 07:50

First, to answer the direct question: Your regex has a bug since it will exclude a tag with a slash anywhere, not just at the end. For example it would exclude this valid opening tag: <a href="foo/bar.html"> because it has a slash in an attribute value.

We can fix that, but more seriously, this regex will lead to false positives, because it will also match inside comments and cdata sections, where the same characters doesn't represent a valid tag. For example:

<!-- <foo> -->

or

<![CDATA[ <foo> ]]>

Especially html strings embedded in scripts is likely to trigger false positives, and so is the regular use of < and > as comparison operators in JavaScript. And of course sections of html which is commented-out with .

So to only match actual tags, you also need to be able to skip past comments and cdata sections. So you need the regex to also match comments and cdata, but only capture the opening tags. This is still possible using a rexep, but it becomes significantly more complex, for example:

(  
    <!-- .*? --> # comment   
  | <!\[CDATA\[ .*? \]\]> # CData section
  | < \w+ ( "" [^""]* "" | ' [^']* ' | [^>/'""] )* /> # self-closing tag  
  | (?<tag> < \w+ ( "" [^""]* "" | ' [^']* ' | [^>/'""] )* > ) # opening tag - captured  
  | </ \w+ \s* > # end tag  
)

And this just for XHTML conforming to the HTML compatibility guidelines. If you want to handle arbitrary XHTML you should also handle processing instructions and internal DTD's, since they can also embed false positives. If you also want to handle HTML there are additional complexities like the <script>-tag. And if you also want to handle invalid HTML it gets yet more complex.

Given the complexity, I would not recommend going down that road. Instead, look for an off-the-shelf (X)HTML parsing library which can solve your problem.

A parser typically uses regular expressions (or similar) under the hood to split the document into "tokens" (doctype, start tags, end tags, text content etc.). But someone else will have debugged and tested these regexes for you! Depending on the type of parser it may further build a tree structure of elements by matching start tags to end tags. This will almost certainly save you a lot of time.

The exact parser library to use depend on your language and platform and the task you are solving. If you need access to the actual tag-substrings (e.g. if you are writing a syntax highlighter for HTML) you need to use a SAX-style parser which exposes the syntax tokens directly.

If you are only performing the tag-matching in order to manually build a syntax tree of elements, then a DOM parser does this work for you. But a DOM parser does not expose the underlying tag syntax, so does not solve the exact problem you describe.

You should also consider if you need to to parse invalid HTML. This is a much more complex task, but on the wild web most of the HTML is actually invalid. Something like Pytons html5lib can parse invalid HTML.

score 2 · Answer 34 · 2020-10-01T19:08:24.290

RegEx match open tags except XHTML self-contained tags
All other tags (and content) are skipped.

This regex does that. If you need to match only specific Open tags, make a list
in an alternation (?:p|br|<whatever tags you want>) and replace the [\w:]+ construct
in the appropriate place below.

https://regex101.com/r/uMvJn0/1

 # Mix html/xml     
 # https://regex101.com/r/uMvJn0/1     
 
 <
 (?:
    
    # Invisible content gets failed
    
    (?:
       (?:
                               # Invisible content; end tag req'd
          (                    # (1 start)
             script
           | style
           | object
           | embed
           | applet
           | noframes
           | noscript
           | noembed 
          )                    # (1 end)
          (?:
             \s+ 
             (?>
                " [\S\s]*? "
              | ' [\S\s]*? '
              | (?:
                   (?! /> )
                   [^>] 
                )?
             )+
          )?
          \s* >
       )
       
       [\S\s]*? </ \1 \s* 
       (?= > )
       (*SKIP)(*FAIL)
    )
    
  | 
    
    # This is any open html tag we will match
    
    (?:
       [\w:]+ \b 
       (?=
          (                    # (2 start)
             (?:
                " [\S\s]*? " 
              | ' [\S\s]*? ' 
              | [^>]? 
             )*
          )                    # (2 end)
          >
       )
       \2 
       (?<! / )
    )
    
  | 
    # All other tags get failed
    
    (?:
       (?: /? [\w:]+ \s* /? )
     | (?:
          [\w:]+ 
          \s+ 
          (?:
             " [\S\s]*? " 
           | ' [\S\s]*? ' 
           | [^>]? 
          )+
          \s* /?
       )
     | \? [\S\s]*? \?
     | (?:
          !
          (?:
             (?: DOCTYPE [\S\s]*? )
           | (?: \[CDATA\[ [\S\s]*? \]\] )
           | (?: -- [\S\s]*? -- )
           | (?: ATTLIST [\S\s]*? )
           | (?: ENTITY [\S\s]*? )
           | (?: ELEMENT [\S\s]*? )
          )
       )
    )
    (*SKIP)(*FAIL)
 )
 >

score 1 · Answer 35 · answered Dec 27 '22 at 11:39

<([a-z][^>\s]*)(?:\s+[^>]+)?>

This regular expression will match opening tags that consist of a single word (e.g. <p>, <a>, etc.), followed by zero or more spaces and any number of characters (except > or whitespace) before the closing > character. It will also match tags with attributes, and will not match tags with names that contain characters other than a-z. However, it will still not match self-closing tags.

score 0 · Answer 36 · answered Aug 27 '23 at 12:32

To match open tags (start tags) except XHTML self-contained tags, you can use the following regular expression:

<[^/][^>]*>

<: Matches the opening angle bracket.
[^/]: Matches any character except the forward slash /, ensuring the tag is not a closing tag.
[^>]*: Matches zero or more characters, not the closing angle bracket >, allowing any attributes to be present.
>: Matches the closing angle bracket, completing the tag.

RegEx match open tags except XHTML self-contained tags

36 Answers36

Regular Expression Explained (inline)

` tag would like a word with you (easily fixed, I know, but still)...

Understanding the pattern

UNRELATED

As per W3Schools...

XML Naming Rules

The real question is: Should you do it?

Linked

Related