> Why use regex? It's much simpler to write a URL validator by hand...
I actually have a use-case. I am firming up a feature right now that detects when a user types a url into a text field and replaces it on the fly with a footnote-style reference number (much like your comment above). This is done to (1) minimize input string length, (2) draw the benefits of a consistent interface, and (3) avoid screwing around with the fragility of url shortening nonsense.
I may regret this, but here's a link to my dev environment for this feature (please be gentle), to see it in action:
...just start typing in the big text box and add in some urls.
It uses a fairly ugly-looking regular expression[0].
If you take out the unicode mumbojumbo, it's not really THAT tricky of a pattern. It does fail on IP addresses and it may be a little over-aggressive on matching, but, I wanted it to catch things like "abc.com" and "//xyz.com".
Edit: Formatting and clarity. Removed the explicit regular expression because it predictably got garbled.
[0] http://regexr.com/38vsq not exactly the same one I'm currently using, but it's pretty close. See source for most up-to-date version.
I agree, the correct one (+500 chars) looks like a maintenance nightmare to me. I tried to build a real e-mail address validator that would accept also the more exotic forms and there was no way in hell I would have done that in regex.
I also met very few people that actually understood regex. It's a whole new skill and if I use it in my application I don't know if the next guy can pick it up.
It's why you should always write regex (at least, anything beyond a couple of characters) using the `x / PCRE_EXTENDED` flag. It makes them ignore whitespace and anything following a #, so you can split your regex up onto multiple lines and comment it to explain what it's doing.
If you looked at the page before commenting you’d know that PHP’s built-in URL parser is one of the implementations that is being tested. You’d also see that one of the requirements was to not match scheme-relative URLs (e.g. `//foo.bar`) like the ones your commit fixes.
The regular expressions presented do not conform to the URL Standard or to any RFC, but rather to the list of requirements on that page.
I applaud your work in improving PHP’s built-in URL parser.
Or, you know, use a robust existing validator or parser. Like PHP's, for instance.
[1] https://github.com/TazeTSchnitzel/Faucet-HTTP-Extension - granted, this deliberately limits the space of URLs it can parse, but it's not difficult to cover all valid cases if you need to
[2] https://github.com/php/php-src/commit/36b88d77f2a9d0ac74692a...