Develop Reference

Regex - unhandled js exception in react native

I am using the following regex in my react-native app.
This is an email validation regex :
^[\w]+#((?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+)(?:[A-Za-z0-9-]{2,63}(?<!-))
This works fine in the browser but crashes the react native app due to the following :
no stack', reason: 'Unhandled JS Exception: Invalid regular expression: invalid group specifier name
Could someone please help getting this to work on react native, maybe by achieving the same thing that this regex achieves but without the lookbehind expression ?

The problem is likely caused the by the (?<!-) negative lookahead at the end of the regex pattern, which your JavaScript engine does not support. To ensure that a hyphen does not occur at the end of the email, we can simply use:
^[\w]+#((?:[A-Za-z0-9](?:[A-Za-z0-9-]{0,61}[A-Za-z0-9])?\.)+)(?:[A-Za-z0-9-]{1,62}[A-Za-z0-9])
That is, just use [A-Za-z0-9] to represent the final of 63 possible characters in the pattern.

This regex will not work likely problem in regex pattern i think.
this works for me for simple email format abc#mail.com
var regex = /^(([^<>()\[\]\\.,;:\s#"]+(\.[^<>()\[\]\\.,;:\s#"]+)*)|(".+"))#((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

RegExp & PCRE convert to tree with own syntax

Looking for pre-processor for creating own syntax of regular expression, based on RegExp & PCRE syntax so it can be parsed to PCRE syntax. Example at the end
I guess I need a processor of regular expression that outputs a tree structure that represents regular expression, so I can traverse the tree and hotswap some parts, then compile it to regular expression string.
But this processor must have ability to add own syntax parsing/processing.
Is there some processor like this, already made by someone? I've made one by myself some time ago, but looking for more professional solution.
Of course we are talking about node.js/javascript
Yes, node.js has not support for PCRE, but there is a npm module for using PCRE with node.js, it works great!
Why someone would need it?
For example, you can create big regular expression by smaller ones:
(John (like|love)s every (animal|creature) on earth: (#animals))
(#...) is hash tag group, it means in place of it will be another regular expression containing alterantives for all animals.
Another example, you can create more sophisticated kind of groups:
(#(a|x)(b)(c))
permutation group matches all brackets (3 or less or more) in any order:
(a|x)(b)(c)
(a|x)(c)(b)
(b)(a|x)(c)
(b)(c)(a|x)
(c)(a|x)(b)
(c)(b)(a|x)
have more, but I guess I've made a point.

Why does my JavaScript RegExp not work as expected

I am writing a password screen, and the requirements for the password security are somewhere between 8 and 20 characters in length, must contain at least one Alpha character and at least one numeric character and at least one special character of [!##$%^&*].
I have cobbled together this regular expression, which appeared to work in C#, but when I started rewriting the code for a JavaScript validation, the regular expression is flagging what I thought were valid passwords as invalid.
Here is the regular expression as I assign it to RegExp:
var regExPatt = new RegExp('^(?=(?:.*[a-zA-Z]){1})(?=(?:.*\d){1})(?=(?:.*[!###$%^&*]){1})(?!.*\s).{8,20}$');
NOTE BENE: The double ## symbol is there to get the # symbol into the RegExp, otherwise it tries to treat partial strings like Razor variables and things go sideways fast.
Where did I go wrong with this regular expression? I know it is fairly complicated.
Passwords that work:
freddy1234%
freddy123$5
freddy12#45
freddy1#345
freddy!2345
Passwords that do not work:
test1234%
wilma1234%
Any ideas?

JavaScript developers should have knowledge about
RegExp object description
Regular Expressions chapter in the JavaScript Guide
Developers who want to use positive or negtive lookahead should take into account that this requires JavaScript v1.5 as it can be read on page New in JavaScript 1.5. But that should be no problem nowadays as this is a very old version released on November 2000 and all browsers used nowadays support v1.5 of JavaScript.
Lookbehind is not yet (JavaScript v1.8.5) supported by JavaScript at all.
A list of the JavaScript versions and which browser supports which JavaScript version can be found on Wikipedia page about JavaScript.
New in JavaScript contains the links to the pages explaining what was added in which version of JavaScript.

Do browsers support different HTML5 pattern regexp features?

I had a simple RegEx pattern in a customer-facing payment form on our website:
<input type="text" pattern="(|\$)[0-9]*(|\.[0-9]{2})"
title="Please enter a valid number in the amount field" required>
It was added to help quickly notify customers when they fail to enter a valid number, before hitting the server-side validation.
After four customers called in complaining that they were unable to submit the form because their browser continually told them the amount they had entered was incorrect, I did some digging and discovered that IE10+ doesn't like the back of that expression--any amount entered that did not include a decimal point was accepted, anything with a decimal was rejected. The pattern works in my development environment (Chrome 30+) and in Opera 12, but Firefox 27 won't validate it at all.
I read the specs, which just says:
If specified, the attribute's value must match the JavaScript Pattern production. [ECMA262]
And since the only browsers that support pattern are capable of supporting ECMAScript 5, I figure this includes the full support of all Javascript regular expressions.
Where can I learn more about the quirks between pattern support in the different browsers?

The problem seems to an IE-only bug. Your link to the spec is pretty dead on, heres the bit IE is missing:
... except that the pattern attribute is matched against the entire value, not just any subset (somewhat as if it implied a ^(?: at the start of the pattern and a )$ at the end)
You can actually fix this bug by doing just that to your own pattern - namely:
^(?:(|\$)[0-9]*(|\.[0-9]{2}))$
This is working for me in IE9 and IE10, as well as Chrome. See updated fiddle
The technical reason this happens is a bit more complex:
If you read the EMCA 5.1 spec, in section 15.10.2.3, it talks about how alternations should be evaluated. Basically, each 'part' of the | is evaluated left to right, until one is found that matches. That value is assumed unless there is a problem in the 'sequel', in which case the other possibilities in the alternation are evaluated.
What it seems IE is doing is matching the beginning of your string using the empty parts of your alternations, and it works: \$[digits][empty] matches the start of $12.12 up to the decimal point. IE's regex engine (correctly) says that this is a match, because a substring matched, and it's not been told to check to the end of the string.
Once the regex engine (without the anchors to force the whole string to match) returns true, that there was a match, some engineer at Microsoft took a shortcut and told the pattern attribute to also check that the matched part equals the whole string, and there's where the failure comes from. The engine only matched part of the string, even though it could have matched more, so the secondary check fails, thinking there is extraneous input at the end.
This case is subtle, so I'm not too surprised it hasn't been caught before. I have created a bug report https://connect.microsoft.com/IE/feedback/details/836117/regex-bug-in-pattern-validator to see if there is a response from Microsoft.
The reason this relates to the EMCA spec is that if the engine was told to match the whole string, it would have backtracked when it hit the decimal and tried to match the 2nd part of the alternation, found and matched (\.[0-9{2}), and the whole thing would have worked.
Now, for some workarounds:
Add the anchors ^(?: and )$ to your patterns
Don't use empty alternations. Personally, I like using the optional $ instead for these cases. Your pattern becomes (\$?)[0-9]*(\.[0-9]{2})? and will work because ? is a greedy match, and the engine will consume the whole string if possible, rather than alternation, which is first match
Swap the order on your alternations. If the longer string is tested first, it will match first, and be used first. This has come up in other languages - Why order matters in this RegEx with alternation?
PS: Be careful with the * for your digits. Right now, "$" is a valid match because * allows for 0 digits. My recommendation for your full regex would be (\$)?(\d+)(\.\d{2})?

help making a "universal" regex Javascript compatible

I found a very nice URL regex matcher on this site: http://daringfireball.net/2010/07/improved_regex_for_matching_urls . It states that it's free to use and that it's cross language compatible (including Javascript). First of all, I have to escape some of the slashes to get it to compile at all. When I do that, it works fine on Rubular.com (where I generally test regexes), with the strange side effect that each match has 5 fields: 1 is the url, and the extra 4 are empty. When I put this in JS, I get the error "Invalid Group". I am using Node.js if that makes any difference, but I wish I could understand that error. I'd like to cut back on the unnecessary empty match fields, but I don't even know where to begin diagnosing this beast. This is what I had after escaping:
(?xi)\b((?:[a-z][\w-]+:(?:\/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}\/)(?:[^\s()<>]+|\(([^\s()<>]+|(\([^\s()<>]+\)))*\))+(?:\(([^\s()<>]+|(\([^\s()<>]+\)))*\)|[^\s`!()\[\]{};:'".,<>?«»“”‘’] ))

Actually, you don't need the first capturing group either; it's the same as the whole match in this case, and that can always be accessed via $&. You can change all the capturing groups to non-capturing by adding ?: after the opening parens:
/\b(?:(?:[a-z][\w-]+:(?:\/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}\/)(?:[^\s()<>]+|\((?:[^\s()<>]+|(\(?:[^\s()<>]+\)))*\))+(?:\((?:[^\s()<>]+|(?:\(?:[^\s()<>]+\)))*\)|[^\s`!()\[\]{};:'".,<>?«»“”‘’]))/i
That "invalid group" error is due to the inline modifiers (i.e., (?xi)) which, as #kirilloid observed, are not supported in JavaScript. Jon Gruber (the regex's author) was mistaken about that, as he was about JS supporting free-spacing mode.
Just FYI, the reason you had to escape the slashes is because you were using regex-literal notation, the most common form of which uses the forward-slash as the regex delimiter. In other words, it's the language (Ruby or JavaScript) that requires you to escape that particular character, not the regex. Some languages let you choose different regex delimiters, while others don't support regex literals at all.
But these are all language issues, not regex issues; the regex itself appears to work as advertised.

Seemes, that you copied it wrong.
http://www.regular-expressions.info/javascript.html
No mode modifiers to set matching options within the regular expression.
No regular expression comments
I.e. (?xi) at the beginning is useless.
x is useless at all for compacted RegExp
i can be replaced with flag
All these result in:
/\b((?:[a-z][\w-]+:(?:\/{1,3}|[a-z0-9%])|www\d{0,3}[.]|[a-z0-9.\-]+[.][a-z]{2,4}\/)(?:[^\s()<>]+|\(([^\s()<>]+|(\([^\s()<>]+\)))*\))+(?:\(([^\s()<>]+|(\([^\s()<>]+\)))*\)|[^\s`!()\[\]{};:'".,<>?«»“”‘’]))/i
Tested and working in Google Chrome => should work in Node.js