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.

Silverlight 4 Coming in April, or Maybe Sooner

The exact release date has not been announced. But Visual Studio 2010 RTM is coming out in April and I think it's safe to assume that Silverlight 4 will be released no later than that. Each release of Silverlight has brought massive improvements over the previous version. And once again, Silverlight 4 does not disappoint. There is a long list of improvements but the ones that I think that will affect Regex Hero are as follows: RichTextBox My plan is to use this in place of all 4 major textboxes in Regex Hero. The new RichTextBox has built-in multiple undos & redos, so I can ditch my home-brewed code. It should be nice to use for syntax highlighting for the regular expressions I intend to create. It also has a built-in API to determine the pixel position of the text. I should be able to use this API and build a new highlighting scheme based off of it. This should do a couple things. First, I should be able to finally fix the problem I had with the ScrollViewer and

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.