views:

167

answers:

2

It seems that the NSNumberFormatter can't parse Euro (and probably other) currency strings into a numerical type. Can someone please prove me wrong.

I'm attempting to use the following to get a numeric amount from a currency string:

NSNumberFormatter *currencyFormatter = [[[NSNumberFormatter alloc] init] autorelease];
[currencyFormatter setNumberStyle:NSNumberFormatterCurrencyStyle];
NSNumber *currencyNumber = [currencyFormatter numberFromString:currencyString];

This works fine for UK and US currency amounts. It even deals with $ and £ and thousands separators with no problems.

However, when I use it with euro currency amounts (with the Region Format set to France or Germany in the settings app) it returns an empty string. All of the following strings fail:

12,34 €
12,34
12.345,67 €
12.345,67

It's worth noting that these strings match exactly what comes out of the NSNumberFormatter's stringFromNumber method when using the corresponding locale.

Setting the Region Format to France in the settings app, then setting currencyNumber to 12.34 in the following code, results in currencyString being set to '12,34 €' :

NSNumberFormatter *currencyFormatter = [[[NSNumberFormatter alloc] init] autorelease];
[currencyFormatter setNumberStyle:NSNumberFormatterCurrencyStyle];
NSString *currencyString = [currencyFormatter stringFromNumber:currencyNumber];

It would obviously be fairly easy to hack around this problem specifically for the Euro but I'm hoping to sell this app in as many countries as possible and I'm thinking that a similar situation is bound to occur with other locales.

Does anyone have an answer?

TIA, Duncan

A: 

Have you tried setting the region to France in settings and then attempting to get the numeric amount for the string? Or you could manually set the local of the number formatter with setLocale:. NSNumberFormatter uses whatever locale it has to figure out what the numbers is a string are. If you just need the user to be able to put in a localized currency string for their area, change the system to that locale and then test. If you need the user to be able to put in multiple formats then add some sort of selection system so you know what they are putting in.

theMikeSwan
Yes, everything is being done under the correct locale. I don't need to support multiple currencies, just work with strings in the user's native locale. So, in the example above, the locale is set to France (or Germany etc). I'll update the question ;)
Duncan A
A: 

This is a difficult one. Doing the following works without issues:

double moneyAmount = 1256.34;
NSLocale *french = [[NSLocale alloc] initWithLocaleIdentifier:@"fr_FR"]; 
NSNumberFormatter *currencyStyle = [[NSNumberFormatter alloc] init];

[currencyStyle setLocale:french];
[currencyStyle setNumberStyle:NSNumberFormatterCurrencyStyle];
NSNumber *amount = [NSNumber numberWithDouble:moneyAmount];
NSString *amountString =  [currencyStyle stringFromNumber:amount];

NSNumber *pAmount = [currencyStyle numberFromString:amountString]; // == 1256.34

However, the output of the -currencyGroupingSeparator method returns the string \u00a0, a non-breaking space, rather than the expected ,.

The formatter classes (as well as the regex classes, among others) on OS X / iOS make use of the ICU library, also used by other projects. I found at least two other bug reports with regards to this particular issue. It appears that this is expected behaviour, though. (I spent some time sifting through the ICU source to find where this is defined, but it is a labyrinth.)

My recommendation, for the time being, would be to pass -setLenient:YES to the currency formatter. Perhaps even file a bug report with Apple's radar.

Sedate Alien