Go is vocal about the former, but seems to not give a shit about the latter.
"੧".match(/\d/); //null
(Incidentally, this may explain the finding from http://stackoverflow.com/a/16622773/172322, as to why adding the RegexOptions.ECMAScript flag in the C# code eliminates the performance gap) pfedor@Pawels-iMac:~$ perl -ne 'print "Digit!\n" if /\d/'
af
3
Digit!
23fa3
Digit!
asdf
١٢٣٤٥٦٧٨٩۰۱۲۳۴۵۶۷۸۹
৩৪৫৬৭৮৯੦੧੨੩੪੫੬੭੮੯૦૧૨૩૪૫
୧୨୩୪୫୬୭୮
౨౩౪౫౬౭౮౯೦೧೨೩೪೫೬೭೮೯൦൧൨൩൪൫൬൭൮൯๐๑๒๓๔๕๖๗๘๙໐໑໒໓
234
Digit!
(perl from Macports and perl from /usr/bin/perl behave the same in this respect.)Doesn't in Ruby:
/\d/.match "੧" #=> nil
/\p{Digit}/.match "੧" => #<MatchData "੧"> \d A digit: [0-9]
\p{Digit} A decimal digit: [0-9]
which is actually somewhat depressing. I'd expect the named class to include the full Unicode digit set. It's surprising to see: ab1234567890cd matched 1234567890
ab𝟣𝟤𝟥𝟦𝟧𝟨𝟩𝟪𝟫𝟢cd no match
from code using
Pattern.compile("(\\p{Digit}+)");EDIT: and perhaps more surprising to see in the logs:
Exception in thread "main" java.lang.NumberFormatException: For input string: "𝟤𝟥𝟦𝟧"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:449)
That'll keep someone guessing for a while... NSString *pattern = @"\\d", *string = @"੧";
NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:pattern
options:NSRegularExpressionCaseInsensitive
error:nil];
NSUInteger numMatches = [regex numberOfMatchesInString:string
options:0
range:NSMakeRange(0, [string length])];
numMatches ? NSLog(@"%@ found by %@", string, pattern) : NSLog(@"%@ not found", string);
// 2013-05-20 09:38:42.650 Regexperiment[17848:c07] ੧ found by \d