This is my quick reminder to self to use
$&
instead of
$0
in JavaScript for Regular Expression replacement patterns when wishing to use the entire matched text.
Some browsers allow $0, but $& is officially documented (table 22, page 147) and supposed to work in all of them.
Example:
document.write("Hello World".replace(/^Hello/, "$& to the whole");
Output:
Hello to the whole World
Showing posts with label Regular Expressions. Show all posts
Showing posts with label Regular Expressions. Show all posts
2008-05-06
Bug Discovered in Internet Explorer 7 JavaScript Regular Expression Engine
I enhanced my understanding about Regular Expressions' "look-ahead" concept that I hadn't fully comprehended before. The fact that (at least in the .NET framework and most JavaScript engines; I assume it also works in PERL and other popular RegEx engines...) you can use look-aheads to not only find a match but not include in the full-text match; but can look-ahead and not have the position of the start of the match matter either.
For some reason I always thought that the match would be made and the beginning of the next match would start at the position the other left off at. I wet my pants with glee when I found that wasn't the case...
That is, until I tried an expression in JavaScript in Internet Explorer 7.
To see an example of what I'm talking about, run my "Regular Expression Tests for Your Browser" on JavaScriptJedi.com in multiple browsers on your computer. You'll be running the "Pre Match Look Aheads (2008-05-05)" tests which are the only ones there at the time of this writing. I may add more in the future.
The scenario is this:
I had a set of password restriction requirements to enforce on a form when a user wanted to change their password. The requirements were that the password must be at least 8 characters long; contains at least one number and at least one "symbol". Due to a database constraint, I also added a max-length requirement of 50 characters, and I interpreted "symbol" to mean any non-alpha-numeric character.
That said, the regular expression ended up like this:
/^(?=.*[0-9])(?=.*[^a-zA-Z0-9]).{8,50}$/
What's really cool about this is; when run in a properly working regular expression engine, it doesn't matter if the number or "symbol" come first, it will detect them both and then from the beginning of the string match any characters between the lengths 8 and 50. Genius. Whoever came up with Regular Expressions needs a Nobel prize or some equivalent; because, well, they just make a developer's world a better place to live. :)
So after getting uber-excited about my new found knowledge and greater love for Regular Expressions, my bubble was quickly burst when I found out it didn't work correctly in IE7 and I had to come up with a workaround.
So go see my page and try it for yourself; and I'd love to get your feedback on this one. I'll be submitting a bug report to Microsoft (if I can figure out how...) and if I hear anything back from them (which I'm sure I won't...) I'll post my findings here.
I'd especially like to hear from Mac users that can test on the major Mac browsers for me and tell me which work and which don't.
For some reason I always thought that the match would be made and the beginning of the next match would start at the position the other left off at. I wet my pants with glee when I found that wasn't the case...
That is, until I tried an expression in JavaScript in Internet Explorer 7.
To see an example of what I'm talking about, run my "Regular Expression Tests for Your Browser" on JavaScriptJedi.com in multiple browsers on your computer. You'll be running the "Pre Match Look Aheads (2008-05-05)" tests which are the only ones there at the time of this writing. I may add more in the future.
The scenario is this:
I had a set of password restriction requirements to enforce on a form when a user wanted to change their password. The requirements were that the password must be at least 8 characters long; contains at least one number and at least one "symbol". Due to a database constraint, I also added a max-length requirement of 50 characters, and I interpreted "symbol" to mean any non-alpha-numeric character.
That said, the regular expression ended up like this:
/^(?=.*[0-9])(?=.*[^a-zA-Z0-9]).{8,50}$/
What's really cool about this is; when run in a properly working regular expression engine, it doesn't matter if the number or "symbol" come first, it will detect them both and then from the beginning of the string match any characters between the lengths 8 and 50. Genius. Whoever came up with Regular Expressions needs a Nobel prize or some equivalent; because, well, they just make a developer's world a better place to live. :)
So after getting uber-excited about my new found knowledge and greater love for Regular Expressions, my bubble was quickly burst when I found out it didn't work correctly in IE7 and I had to come up with a workaround.
So go see my page and try it for yourself; and I'd love to get your feedback on this one. I'll be submitting a bug report to Microsoft (if I can figure out how...) and if I hear anything back from them (which I'm sure I won't...) I'll post my findings here.
I'd especially like to hear from Mac users that can test on the major Mac browsers for me and tell me which work and which don't.
Subscribe to:
Posts (Atom)