I am trying to add escaped values to an error message in a Spring MVC Validator
final Object[] vatErrorArray = new String[2];
vatErrorArray[0] = "aaa";
vatErrorArray[1] = "bbb";
errors.rejectValue("vatfield", "vendor.vat.number.invalid.pattern.generic", vatErrorArray, "Invalid VAT");
where vendor.vat.number.invalid.pattern.generic is as follows:
vendor.vat.number.invalid.pattern.generic=VAT Number's pattern is invalid for {0}. Valid pattern: {1}.
Unfortunately, the displayed error message doesn't contain the escaped values:
VAT Numbers pattern is invalid for {0}. Valid pattern: {1}.
What am I doing wrong?
PS I am using Spring MVC version 4.2.1.RELEASE
I think you need to change the single quote in Number's to two single quotes ('').
I haven't tried it myself but am basing this mostly on the content of this question, and the MessageFormat docs it links to, plus the fact that your single quote seems to be disappearing.
Related
I try to remove an element from an array. This operation
UpdateItemSpec updateItemSpec = new UpdateItemSpec()
.withPrimaryKey("id", id)
.withNameMap(new NameMap().with("#P", "myArray"))
.withValueMap(new ValueMap().withInt(":index", index))
.withUpdateExpression("REMOVE #P[:index]");
table.updateItem(updateItemSpec);
results with com.amazonaws.services.dynamodbv2.model.AmazonDynamoDBException: Invalid UpdateExpression: Syntax error; token: ":index", near: "[:index]"
If I remove ValueMap and concat string like this "REMOVE #P["+index+"]" it works fine but this solution looks ugly (like old bad SQL injection stuff). Is there a way to provide an index as a parameter?
REMOVE - Removes one or more attributes from an item
REMOVE - The UpdateExpression is expected to have attribute name only for REMOVE. It should not contain attribute value similar to SET.
There is no alternative other than String concatenation by some means.
i want to allow only alphanumeric password i have written following code to match the same
but the same is not working
Regex.IsMatch(txtpassword.Text, "^[a-zA-Z0-9_]*$") never return false
even if i type password test(which do not contain any number).
ElseIf Regex.IsMatch(txtpassword.Text, "^[a-zA-Z0-9_]*$") = False Then
div_msg.Attributes.Add("class", "err-msg")
lblmsg.Text = "password is incorrect"
I have tried this also
Dim r As New Regex("^[a-zA-Z0-9]+$")
Dim bool As Boolean
bool = r.IsMatch(txtpassword.Text) and for txtpassword.Text = '4444' , bool is coming true i dont know what is wrong.
First of all, the '_' is not a valid alpha-numeric character.
See http://en.wikipedia.org/wiki/Alphanumeric
And, second, take another look at your regular expression.
[a-zA-Z0-9_]*
This can match 0 OR more alpha-numeric characters or 0 OR more '_' characters.
Using this pattern, a password '&#&#^$' would return TRUE.
You probably want to test for 1 OR more characters that ARE NOT an alpha-numeric. If that test returns TRUE, then throw the error.
Hope this helps.
Try the following Expression:
([^a-zA-Z0-9]+)
This will match if your Password contains any character that is not alphanumeric.
If you get a match, do your error handling.
So based on the Regex that you have in the question, it appears you want a password with one lower-case and upper-case letter, one number, and an _; so here is a Regex that will do that:
(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*_).{4,8}
Debuggex Demo
The {4,8} indicates the length of the password; you can set that accordingly.
The URL link below will open a new Google mail window. The problem I have is that Google replaces all the plus (+) signs in the email body with blank space. It looks like it only happens with the + sign. How can I remedy this? (I am working on a ASP.NET web page.)
https://mail.google.com/mail?view=cm&tf=0&to=someemail#somedomain.com&su=some subject&body=Hi there+Hello there
(In the body email, "Hi there+Hello there" will show up as "Hi there Hello there")
The + character has a special meaning in [the query segment of] a URL => it means whitespace: . If you want to use the literal + sign there, you need to URL encode it to %2b:
body=Hi+there%2bHello+there
Here's an example of how you could properly generate URLs in .NET:
var uriBuilder = new UriBuilder("https://mail.google.com/mail");
var values = HttpUtility.ParseQueryString(string.Empty);
values["view"] = "cm";
values["tf"] = "0";
values["to"] = "someemail#somedomain.com";
values["su"] = "some subject";
values["body"] = "Hi there+Hello there";
uriBuilder.Query = values.ToString();
Console.WriteLine(uriBuilder.ToString());
The result:
https://mail.google.com:443/mail?view=cm&tf=0&to=someemail%40somedomain.com&su=some+subject&body=Hi+there%2bHello+there
If you want a plus + symbol in the body you have to encode it as 2B.
For example:
Try this
In order to encode a + value using JavaScript, you can use the encodeURIComponent function.
Example:
var url = "+11";
var encoded_url = encodeURIComponent(url);
console.log(encoded_url)
It's safer to always percent-encode all characters except those defined as "unreserved" in RFC-3986.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
So, percent-encode the plus character and other special characters.
The problem that you are having with pluses is because, according to RFC-1866 (HTML 2.0 specification), paragraph 8.2.1. subparagraph 1., "The form field names and values are escaped: space characters are replaced by `+', and then reserved characters are escaped"). This way of encoding form data is also given in later HTML specifications, look for relevant paragraphs about application/x-www-form-urlencoded.
Just to add this to the list:
Uri.EscapeUriString("Hi there+Hello there") // Hi%20there+Hello%20there
Uri.EscapeDataString("Hi there+Hello there") // Hi%20there%2BHello%20there
See https://stackoverflow.com/a/34189188/98491
Usually you want to use EscapeDataString which does it right.
Generally if you use .NET API's - new Uri("someproto:with+plus").LocalPath or AbsolutePath will keep plus character in URL. (Same "someproto:with+plus" string)
but Uri.EscapeDataString("with+plus") will escape plus character and will produce "with%2Bplus".
Just to be consistent I would recommend to always escape plus character to "%2B" and use it everywhere - then no need to guess who thinks and what about your plus character.
I'm not sure why from escaped character '+' decoding would produce space character ' ' - but apparently it's the issue with some of components.
We have ASP.NET application which runs different clients around the world. In this application we have dictionary for each language. In dictionary we have words in lowercase and sometimes we uppercase it in code for typographic reasons.
var greek= new CultureInfo("el-GR");
string grrr = "Πόλη";
string GRRR = grrr.ToUpper(greek); // "ΠΌΛΗ"
The problem is:
...if you're using capital letters
then they must appear like this: f.e.
ΠΟΛΗ and not like ΠΌΛΗ, same for all
other words written in capital letters
So is it possible generically to uppercase Greek words correctly in .NET? Or should I wrote my own custom algorithm for Greek uppercase?
How do they solve this problem in Greece?
I suspect that you're going to have to write your own method, if el-GR doesn't do what you want. Don't think you need to go to the full length of creating a custom CultureInfo, if this is all you need. Which is good, because that looks quite fiddly.
What I do suggest you do is read this Michael Kaplan blog post and anything else relevant you can find by him - he's been working on and writing about i18n and language issues for years and years and his commentary is my first point of call for any such issues on Windows.
I don't know much about ASP.Net but I know how I'd do this in Java.
If the characters are Unicode, I would just post-process the output from ToUpper with some simple substitutions, one being the conversion of \u038C (Ό) to \u039F (Ο) or \u0386 (Ά) to \u0391 (Α).
From the looks of the Greek/Coptic code page (\u0370 through \u03ff), there's only a few characters (6 or 7) you'll need to change.
Check out How do I remove diacritics (accents) from a string in .NET?
How about replacing the wrong characters with the right ones:
/// <summary>
/// Returns the string to uppercase using Greek uppercase rules.
/// </summary>
/// <param name="source">The string that will be converted to uppercase</param>
public static string ToUpperGreek(this string source)
{
Dictionary<char, char> mappings = new Dictionary<char, char>(){
{'Ά','Α'}, {'Έ','Ε'}, {'Ή','Η'}, {'Ί','Ι'}, {'Ό','Ο'}, {'Ύ','Υ'}, {'Ώ','Ω'}
};
source = source.ToUpper();
char[] result = new char[source.Length];
for (int i = 0; i < result.Length; i++)
{
result[i] = mappings.ContainsKey(source[i]) ? mappings[source[i]] : source[i];
}
return new string(result);
}
I've used both of the following Regular Expressions for testing for a valid email expression with ASP.NET validation controls. I was wondering which is the better expression from a performance standpoint, or if someone has better one.
- \w+([-+.']\w+)*#\w+([-.]\w+)*\.\w+([-.]\w+)*
- ^([0-9a-zA-Z]([-\.\w]*[0-9a-zA-Z])*#([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9})$
I'm trying avoid the "exponentially slow expression" problem described on the BCL Team Blog.
UPDATE
Based on feedback I ended up creating a function to test if an email is valid:
Public Function IsValidEmail(ByVal emailString As String, Optional ByVal isRequired As Boolean = False) As Boolean
Dim emailSplit As String()
Dim isValid As Boolean = True
Dim localPart As String = String.Empty
Dim domainPart As String = String.Empty
Dim domainSplit As String()
Dim tld As String
If emailString.Length >= 80 Then
isValid = False
ElseIf emailString.Length > 0 And emailString.Length < 6 Then
'Email is too short
isValid = False
ElseIf emailString.Length > 0 Then
'Email is optional, only test value if provided
emailSplit = emailString.Split(CChar("#"))
If emailSplit.Count <> 2 Then
'Only 1 # should exist
isValid = False
Else
localPart = emailSplit(0)
domainPart = emailSplit(1)
End If
If isValid = False OrElse domainPart.Contains(".") = False Then
'Needs at least 1 period after #
isValid = False
Else
'Test Local-Part Length and Characters
If localPart.Length > 64 OrElse ValidateString(localPart, ValidateTests.EmailLocalPartSafeChars) = False OrElse _
localPart.StartsWith(".") OrElse localPart.EndsWith(".") OrElse localPart.Contains("..") Then
isValid = False
End If
'Validate Domain Name Portion of email address
If isValid = False OrElse _
ValidateString(domainPart, ValidateTests.HostNameChars) = False OrElse _
domainPart.StartsWith("-") OrElse domainPart.StartsWith(".") OrElse domainPart.Contains("..") Then
isValid = False
Else
domainSplit = domainPart.Split(CChar("."))
tld = domainSplit(UBound(domainSplit))
' Top Level Domains must be at least two characters
If tld.Length < 2 Then
isValid = False
End If
End If
End If
Else
'If no value is passed review if required
If isRequired = True Then
isValid = False
Else
isValid = True
End If
End If
Return isValid
End Function
Notes:
IsValidEmail is more restrictive about characters allowed then the RFC, but it doesn't test for all possible invalid uses of those characters
If you're wondering why this question is generating so little activity, it's because there are so many other issues that should be dealt with before you start thinking about performance. Foremost among those is whether you should be using regexes to validate email addresses at all--and the consensus is that you should not. It's much trickier than most people expect, and probably pointless anyway.
Another problem is that your two regexes vary hugely in the kinds of strings they can match. For example, the second one is anchored at both ends, but the first isn't; it would match ">>>>foo#bar.com<<<<" because there's something that looks like an email address embedded in it. Maybe the framework forces the regex to match the whole string, but if that's the case, why is the second one anchored?
Another difference is that the first regex uses \w throughout, while the second uses [0-9a-zA-Z] in many places. In most regex flavors, \w matches the underscore in addition to letters and digits, but in some (including .NET) it also matches letters and digits from every writing system known to Unicode.
There are many other differences, but that's academic; neither of those regexes is very good. See here for a good discussion of the topic, and a much better regex.
Getting back to the original question, I don't see a performance problem with either of those regexes. Aside from the nested-quantifiers anti-pattern cited in that BCL blog entry, you should also watch out for situations where two or more adjacent parts of the regex can match the same set of characters--for example,
([A-Za-z]+|\w+)#
There's nothing like that in either of the regexes you posted. Parts that are controlled by quantifiers are always broken up by other parts that aren't quantified. Both regexes will experience some avoidable backtracking, but there are many better reasons than performance to reject them.
EDIT: So the second regex is subject to catastrophic backtracking; I should have tested it thoroughly before shooting my mouth off. Taking a closer look at that regex, I don't see why you need the outer asterisk in the first part:
[0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*
All that bit does is make sure the first and last characters are alphanumeric while allowing some additional characters in between. This version does the same thing, but it fails much more quickly when no match is possible:
[0-9a-zA-Z][-.\w]*[0-9a-zA-Z]
That would probably suffice to eliminate the backtracking problem, but you could also make the part after the "#" more efficient by using an atomic group:
(?>(?:[0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+)[a-zA-Z]{2,9}
In other words, if you've matched all you can of substrings that look like domain components with trailing dots, and the next part doesn't look like a TLD, don't bother backtracking. The first character you would have to give up is the final dot, and you know [a-zA-Z]{2,9} won't match that.
We use this RegEx which has been tested in-house against 1.5 million addresses. It correctly identifies better than 98% of ours, but there are some formats that I'm aware of that it would error on.
^([\w-]+(?:\.[\w-]+)*)#((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$
We also make sure that there are no EOL characters in the data since an EOL can fake out this RegEx. Our Function:
Public Function IsValidEmail(ByVal strEmail As String) As Boolean
' Check An eMail Address To Ensure That It Is Valid
Const cValidEmail = "^([\w-]+(?:\.[\w-]+)*)#((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$" ' 98% Of All Valid eMail Addresses
IsValidEmail = False
' Take Care Of Blanks, Nulls & EOLs
strEmail = Replace(Replace(Trim$(strEmail & " "), vbCr, ""), vbLf, "")
' Blank eMail Is Invalid
If strEmail = "" Then Exit Function
' RegEx Test The eMail Address
Dim regEx As New System.Text.RegularExpressions.Regex(cValidEmail)
IsValidEmail = regEx.IsMatch(strEmail)
End Function
I am a newbie, but I tried the following and it seemed to have limited the ".xxx" to only two occurrences or less, after the symbol '#'.
^([a-zA-Z0-9]+[a-zA-Z0-9._%-]*#(?:[a-zA-Z0-9-])+(\.+[a-zA-Z]{2,4}){1,2})$
Note: I had to substitute single '\' with double '\\' as I am using this reg expr in R.
These don't check for all allowable email addresses according to the email address RFC.
I let MS to do the work for me:
Public Function IsValidEmail(ByVal emailString As String) As Boolean
Dim retval As Boolean = True
Try
Dim address As New System.Net.Mail.MailAddress(emailString)
Catch ex As Exception
retval = False
End Try
Return retval
End Function
For server side validation, I found Phil Haack's solution to be one of the better ones. His attempt was to stick to the RFC:
string pattern = #"^(?!\.)(""([^""\r\\]|\\[""\r\\])*""|"
+ #"([-a-z0-9!#$%&'*+/=?^_`{|}~]|(?<!\.)\.)*)(?<!\.)"
+ #"#[a-z0-9][\w\.-]*[a-z0-9]\.[a-z][a-z\.]*[a-z]$";
Regex regex = new Regex(pattern, RegexOptions.IgnoreCase);
return regex.IsMatch(emailAddress);
Details:
http://blog.degree.no/2013/01/email-validation-finally-a-net-regular-expression-that-works/
Just to contribute, I am using this regex.
^([a-zA-Z0-9]+[a-zA-Z0-9._%-]*#(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,4})$
The thing about it is the specifications are changing with each domain extension that is introduced.
You sit here mod your regex, test, test, test, and more testing. You finally get what you "think" is accurate then the specification changes... You update your regex to account for what the new requirements are..
Then someone enters aa#aa.aa and you've done all that work for what? It walks through your fancy regex.. bummer!
You may as well just check for a single #, and a "." and move on. I assure you, you will not get someones email if they do not want to give it up. You'll get garbage or their hotmail account they never check and couldn't care less about.
I've seen in many cases this goes horribly wrong and a client calls up because their own email address is rejected because of a poorly crafted regex check. Which as mentioned shouldn't have even been attempted.
TextBox :-
<asp:TextBox ID="txtemail" runat="server" CssClass="form-control pantxt" Placeholder="Enter Email Address"></asp:TextBox>
Required Filed validator:
<asp:RequiredFieldValidator ID="RequiredFieldValidator9" runat="server" ControlToValidate="txtemail" ErrorMessage="Required"></asp:RequiredFieldValidator>
Regular Expression for email validation :
<asp:RegularExpressionValidator ID="validateemail" runat="server" ControlToValidate="txtemail" ValidationExpression="\w+([-+.']\w+)*#\w+([-.]\w+)*\.\w+([-.]\w+)*" ErrorMessage="Invalid Email"></asp:RegularExpressionValidator>
Use this regular expression for email validation in asp.net