Skip to main content

ASP.NET MVC DataAnnotations and the RegularExpressionAttribute

A fellow Regex Hero user emailed me this morning about an inconsistency between what they were seeing in Regex Hero vs what they were seeing with the RegularExpression DataAnnotation in ASP.NET MVC.

As a test, they were trying the following regular expression...


Against this string...


In Regex Hero you see 3 matches (as you should).  But in ASP.NET MVC it doesn't match, and validation fails.

Why is this?

As it turns out, the RegularExpressionAttribute is hiding an implementation detail.  In fact, I couldn't even find any mention of this on MSDN.

It's most plainly visible if you open up the Javascript file that comes with an MVC project template, MicrosoftMvcValidation.js.  Inside you'll find this bit of code...
var $0=new RegExp(this.$0);
var $1=$0.exec(value);
return (!Sys.Mvc._ValidationUtil.$0($1) && $1[0].length===value.length);

I've highlighted the important piece. It's checking to make sure the text value's length is equal to the match's length.  In other words, the validation is designed to prevent any extraneous input beyond what a single regular expression match contains.  And it does the same thing server side as well.

So for RegularExpressionAttribute testing purposes in Regex Hero you could just always use ^ and $ anchors for every regular expression.  And then check to make sure that you're getting 1 match, and 1 match only.


  1. I usually use grouping or non-matching groups around choice operators. I believe Learning Perl suggests doing this to avoid such confusion.

    I'm not sure Microsoft's implementation is *wrong* per se. It's honoring the start and end anchors with a higher precedence than the choice operator. I looked briefly for the specification of this behavior, but my power went out.

    Suppose you want to find any single line which contains A, B, or C. Using the pattern ^A|B|C$ and the input texts:


    One would expect the last line to not match, but the choice operator is greedy and causes the last line to provide 3 matches.

    On the other hand, if you use a non-matching group pattern, you have the expected results: ^(?:A|B|C)$ matches only the first three lines.

    My advice is to always 'embrace your choices'. Cheesy? Yes. But, it works to avoid confusion.


Post a Comment

Popular posts from this blog

Regex Hero for Windows 10 is Underway

Awhile back I began working on an HTML5 / JavaScript version of Regex Hero . However, it was a huge undertaking essentially requiring a complete rewrite of the entire application. I have not had enough time to dedicate to this lately. So I've begun again, this time rewriting Regex Hero to work in WPF. It'll be usable in Windows 10 and downloadable from the Microsoft Store. This is a much easier task that also has the advantage of running the .NET regex library from the application itself. This will allow for the same speedy experience of testing your regular expressions and getting instant feedback that Regex Hero users have always enjoyed. I expect the first release to be ready in Q4 of 2019.

Optimizing Your Regular Expressions

Regular expressions will backtrack.  That's an unfortunate thing about them because backtracking can be slow.    And in certain (rare) cases the performance can become so awful that executing the regular expression against a relatively short string could take over a minute.  There's a good article about catastrophic backtracking over at . And today I created a video about all of this called  Regex Lesson 5: Optimization .  In the video I start with a very poorly written regular expression and make several improvements to it, using the benchmarking feature along the way.  By the end of the video I make the regular expression over 3 million times faster. In addition, today's update to Regex Hero provides a little message in the event that you encounter a regular expression that takes over 10 seconds to evaluate... And then last of all, I changed the benchmarking feature a bit.  In the past it would simply test your regular expression against

Regex Analysis Bug Fixes

All of these updates relate to the analyzer, so if you're not a Regex Hero Professional user, then this won't affect you. I received a report of an analysis bug  related to character classes.  The regex analyzer wouldn't handle opening brackets inside a character class properly. It's one of the finer details of the regular expression syntax.  You wouldn't think that [[abc] would be valid, but it is.  You don't have to escape the opening bracket inside the character class.  So now the analyzer interprets this as it should. I've also fixed bugs around interpreting the \x00 (hex), \u0000 (unicode), and \k<group>  (backreference) expressions. P.S. The major updates I mentioned recently are still in the works.  So the price for Regex Hero Professional is still $20 for now.