I'm trying to format and parse numbers using GWT's NumberFormat but I would like to use the default format (for ex. that of EN locale) regardless of user selected locale, so users can select any language, but I want the numbers to be displayed and parsed using the default format (for ex. 1,234.89).
Is there a way to do this?
EDIT:
For ex. this code only works in EN locale, in RU I get NumberFormatException
NumberFormat format = NumberFormat.getFormat("#,##0.00");
String n = "1,234.89";
double value = format.parse(n);
//do something with value...
I would need to get a NumberFormat instance for locale EN, but I can't find any method/constructor in the javadocs that can do this.
I you have the number you should use NumberFormat.format, not NumberFormat.parse:
NumberFormat format = NumberFormat.getFormat("#,##0.00");
Double n = 1234.89;
RootPanel.get().add(new HTML("Number: " + format.format(n)));
I you already have a formated String representation of the number, you don't need NumberFormat:
String n = "1,234.89";
RootPanel.get().add(new HTML("Number: " + n));
NumberFormat always parses a localized text. It uses NumberConstants witch are instantiated via deferred binding according to current locale. Unfortunately you can not force using other NumberConstants.
But you know the default grouping separator (,) and decimal separator (.). You can also get the grouping and decimal separator for current locale. So you just need to replace them before parsing.
String n = "1,234.89";
n = n.replace(",", LocaleInfo.getCurrentLocale().getNumberConstants().groupingSeparator());
n = n.replace(".", LocaleInfo.getCurrentLocale().getNumberConstants().decimalSeparator());
double value = format.parse(n);
This should work for any locale.
To format a number with default locale just do the opposite replacements after formatting in current locale.
Related
I've got a little problem with JFormattedTextField: I want to hold and retrieve numbers from 1000 to 65535. But when I retriev value (7000) from JFormattedTextField, it have one space like 7 000, and when I parse value to Integer (Integer.parseInt(formattedTextField.getText())), it fail.
java.lang.NumberFormatException: For input string: "7 000"
If I do this with MaskFormatter() and .setMask("#####") it's ok, but I want to do this with NumberFormatter().
How can I setup JFormattedTextField without an additon space?
NumberFormatter nfsoc = new NumberFormatter();
nfsoc.setMaximum(Short.MAX_VALUE*2 - 1);
nfsoc.setMinimum(1);
nfsoc.setAllowsInvalid(false);
formattedTextField = new JFormattedTextField(nfsoc);
formattedTextField.setText("7000");
int socket = Integer.parseInt(formattedTextField.getText())
//java.lang.NumberFormatException: For input string: "7 000"
I expect the output of Integer.parseInt(tfServerSocket.getText()) to be 7000, but the actual output is //java.lang.NumberFormatException: For input string: "7 000"
There are two ways to parse an integer.
NumberFormatter uses a localized NumberFormat, which means it formats and parses according to your locale (country/region).
Integer.parseInt doesn’t care about locale. It always expects numbers in the same format used by Java source code, namely “[±]ddd…” (all ASCII digits, optionally preceded by a sign).
Use the getValue() method of JFormattedTextField. It exists specifically to do what you’re trying to do: obtain the value of the JFormattedTextField.
It also has the advantage that it will allow your code to work in all locales, not just yours. For instance, in the United States, your example value is written 7,000. In Germany, it’s written 7.000.
Number socketValue = (Number) formattedTextField.getValue();
if (socketValue == null) {
JOptionPane.showMessageDialog(
formattedTextField.getTopLevelAncestor(),
"A valid port valid is required.",
"Cannot create connection",
JOptionPane.ERROR_MESSAGE);
return;
}
int socket = socketValue.intValue();
To get rid of addition space:
NumberFormatter nfsoc = new NumberFormatter();
NumberFormat nf = NumberFormat.getIntegerInstance();
nf.setGroupingUsed(false); // It removes any separator
nfsoc.setFormat(nf);
nfsoc.setMaximum(Short.MAX_VALUE*2 - 1);
nfsoc.setMinimum(1);
nfsoc.setAllowsInvalid(false);
I've found out it not a space but special character \p{Zs}
tfServerSocket.getText().replaceAll("\p{Zs}", "") = 7000 // without any addition character!
Double.valueOf with comma decimal separator throws NumberFormatException.
Java 1.7.0_67 and 1.8.0_25.
I also try to set DecimalFormatSymbols with "," as decimalSeparator.
Locale.setDefault(Locale.FRANCE);
assert "12,3".equals(NumberFormat.getInstance().format(12.3));
if (((DecimalFormat) NumberFormat.getInstance()).getDecimalFormatSymbols().getDecimalSeparator() == ',')
Double.valueOf("12,3");
NumberFormat format = NumberFormat.getInstance(Locale.FRANCE);
Number number = format.parse("12,3");
Double d = number.doubleValue();
System.out.println(d);
Double.valueOf() is not Locale aware. It only understands numbers with dots as decimal places.
Luckily you can use the same NumberFormat instance for formatting and parsing which is Locale aware ....
NumberFormat format = NumberFormat.getInstance(Locale.FRANCE);
System.out.println(format.format(12.3)); // ==> "12,3"
System.out.println(format.parse("12,3")); // ==> 12.3
Double.valueOf(String) does not take the default locale into account. Note that the API documentation of the method explains exactly what format it expects. It also tells you this:
To interpret localized string representations of a floating-point value, use subclasses of NumberFormat.
Use, for example, DecimalFormat instead to parse the string.
DecimalFormat format = new DecimalFormat("##.#");
Double value = (Double) format.parse("12,3");
I have a requirement to show a number value like 123456789.905 in the following format 123,456,789.90. But the comma separation changes depending on the locale selected in the phone (as if with US English selected comma separation is 3 places and if India English is selected it is like 12,34,56,789.90).
How can I format my Double?
So, java.text.NumberFormat doesn't slove the problem, unfortunately, but com.ibm.icu.text.NumberFormat does.
You can use this:
Double d = 123456789.905;
com.ibm.icu.text.NumberFormat format = com.ibm.icu.text.NumberFormat.getNumberInstance(new Locale("en", "in"));
format.setMinimumFractionDigits(2);
format.setMaximumFractionDigits(2);
System.out.println(format.format(d));
This outputs: 12,34,56,789.90.
For the generic case, use java.text.NumberFormat:
NumberFormat nf = NumberFormat.getInstance();
String formatted = nf.format(yourDoubleValue);
By default getInstance() returns a NumberFormat that is configured as appropriate for the current Locale. You can change the configuration yourself, too.
The "comma separation" is called "grouping".
For the specific case of grouping in an Indian currency format, see: Displaying Currency in Indian Numbering Format
Try this one:
try {
Locale l = Locale.getDefault();
NumberFormat nf = NumberFormat.getInstance(l);
String formato = NumberFormat.getInstance().format(your_data);
} catch (Exception e) {
e.printStackTrace();}
Use NumberFormat, which helps you to format and parse numbers for any locale.
Your code can be completely independent of the locale conventions for
decimal points, thousands-separators, or even the particular decimal
digits used, or whether the number format is even decimal.
Locale fmtLocale = Locale.getDefault();
NumberFormat formatter = NumberFormat.getInstance(fmtLocale);
formatter.format(your_number);
Hm, I have not found for any locale in NumberFormat.getAvailableLocales() a format with only two digits between grouping signs (for example for new Locale("en", "IN")). So I think you have to use DecimalFormat-pattern like this:
DecimalFormat df = new DecimalFormat("##,##,##,##,##.###");
System.out.println(df.format(123456789.905));
// Output: 1.23.45.67.89,905
It is not exactly the same since DecimalFormat is not able to have varying counts of grouping sizes, but maybe this is acceptable for you.
NumberFormat nf = NumberFormat.getInstance(Locale.getDefault());
double value = nf.parse(iValue).doubleValue();
I have a simple EditText, which allows the user to enter a number such as 45.60 (example for American Dollar). I then format this number using the following method:
public String format() {
NumberFormat formatter = NumberFormat.getCurrencyInstance(Locale.getDefault());
return formatter.format(amount.doubleValue());
}
And on my Android phone, the language is set to English (United States) - hence the Locale.getDefault() should return the US locale (and it does).
Now the edit text is correctly updated to: $45.60 (hence formatting the entered number works).
However if I attempt to parse the above String "$45.60" using the following method:
NumberFormat numberFormat = NumberFormat.getInstance(Locale.getDefault());
Number result = numberFormat.parse("$45.60");
It fails with:
java.lang.IllegalArgumentException: Failed to parse amount $45.60 using locale en_US.
If I set my phone to English/ UK, formatting this "45.60" to "£45.60" works correctly (as for US), however parsing "£45.60" fails, just as it does for the above US sample.
However, if I set my phone to German (Germany), formatting "45,60" to "45,60€" works correctly, AND parsing "45,60€" works correctly as well!
The only difference I see between those three currencies: The Euro is appended to the amount, while the Dollar and the Pound are prepended to the amount.
Does anyone have an idea, why the same code works for Euro, but not for Pound and Dollar? Am I missing something?
I also created a unit test, to reproduce the issue:
public void testCreateStringBased() throws Exception {
// For German locale
CurrencyAmount amount = new CurrencyAmount("25,46€", Locale.GERMANY);
assertEquals(25.46, amount.getAsDouble());
// For French locale
amount = new CurrencyAmount("25,46€", Locale.FRANCE);
assertEquals(25.46, amount.getAsDouble());
// For US locale
amount = new CurrencyAmount("$25.46", Locale.US);
assertEquals(25.46, amount.getAsDouble());
// For UK locale
amount = new CurrencyAmount("£25.46", Locale.UK);
assertEquals(25.46, amount.getAsDouble());
}
CurrencyAmount basically wraps the code I posted for parsing currency strings, except that it takes the given locale instead of the default locale. In the above example, the test succeeds for the GERMANY and FRANCE locale but fails for US and UK locale.
Since the answers that have been suggested thus far, did not completely solve the problem, I took a painfully amateurish approach:
String value = "$24,76"
value = value.replace(getCurrencySymbol(locale), StringUtils.EMPTY);
NumberFormat numberFormat = NumberFormat.getInstance(locale);
Number result = numberFormat.parse(value);
So now I simply strip the String value off it's currency symbol... This way I can process everything I want, such as: 45.78 or 45,78 or $45.78 or 45,78€ ....
Whatever the input, the currency symbol is simply stripped and I end up with the plain number. My unittests (see OP) now complete successfully.
If anyone comes up with something better, please let me know.
Try following:
NumberFormat numberFormat = new DecimalFormat("¤#.00", new DecimalFormatSymbols(Locale.UK));
numberFormat.parse("£123.5678");
¤ - currency sign, expects matches with currency symbol by Locale.
other pattern symbols you can see by following link http://docs.oracle.com/javase/6/docs/api/java/text/DecimalFormat.html
Try NumberFormat.getCurrencyInstance().parse() instead of NumberFormat.getInstance().parse().
You must know the locale of the string you wish to parse in order to have a locale-aware parser. The GBP string parse to a numeric ONLY when the NumberFormat's locale is en_GB; there is no such thing as a "universal" parser.
For example, how does the string "12.000" parse? For en-us, the answer is twelve; for de-de, the answer is twelve-thousand.
Always use NumberFormat.getCurrencyInstance( java.util.Locale ) to parse currency amounts.
I'm using below adapted from https://dzone.com/articles/currency-format-validation-and
import java.math.BigDecimal;
import org.apache.commons.validator.routines.*;
BigDecimalValidator currencyValidator = CurrencyValidator.getInstance();
BigDecimal parsedCurrency = currencyValidator.validate(currencyString);
if ( parsedCurrency == null ) {
throw new Exception("Invalid currency format (please also ensure it is UTF-8)");
}
If you need to insure the correct Locale is being used per user look at
Change locale on login
Sorry, but any answer provided are misleading. This is what I would call a BUG in Java.
An example like this explains it better. If I want to print a value in EUR using Locale.US and then I parse it again, it fails unless I specify on the DecimalFormat the currency (EUR). Using dollars, it works:
DecimalFormat df = new DecimalFormat("¤#,##0.00", new DecimalFormatSymbols(Locale.US));
df.setCurrency(Currency.getInstance("EUR"));
BigDecimal value = new BigDecimal("1.23");
String text = df.format(value);
System.out.println(text);
DecimalFormat df2 = new DecimalFormat("¤#,##0.00", new DecimalFormatSymbols(Locale.US));
df2.setParseBigDecimal(true);
BigDecimal parsed = (BigDecimal) df2.parse(text);
BigDecimalAsserts.assertBigDecimalEquals("parsed value is the same of the original", value, parsed);
I'm trying save a values' input field to a BigDecimal. Which already works.
But it produces strange results if I enter decimal deliminator that is not of the locale type.
eg:
class Payment {
BigDecimal amount;
}
<p:inputText id="amount" value="#{payment.amount}">
<f:convertNumber locale="en"/>
</p:inputText>
<h:outputText value="#{payment.amount}" />
If I input 10,10
I get: 1,010.00
So the value is taken as 1010
How could I work around this? What am I doing wrong here?
ty
The commas are not significant when parsing an English-locale number. Java's raw Number types will not retain any formatting information - that's just presentation data.
The logic for the inputText with a NumberConverter goes like this:
NumberFormat formatter = NumberFormat.getNumberInstance(Locale.ENGLISH);
// NumberConverter turns input string into Number
Number number = formatter.parse("10,10");
// Expression language coerces the Number to BigDecimal
BigDecimal decimal = BigDecimal.valueOf(number.doubleValue());
// On output back to browser:
String output = formatter.format(decimal);
System.out.println(output);
The outputText doesn't have a converter, so will merely call toString() on its value binding (the BigDecimal.)
I would expect the results to be 1,010 and 1010.0 respectively.
The behavior of NumberConverter is documented in the javadoc. The rules for EL type coercion are documented in JSR 245:
Coerce A to Number type N
If A is Number, coerce quietly to type N using the following algorithm:
If N is BigDecimal,
If A is a BigInteger, return new BigDecimal(A)
Otherwise, return new BigDecimal(A.doubleValue())
If you want to use the user's browser locale to interpret number formats, remove the locale attribute. If you want a converter to treat both periods and commas as decimal separators, provide your own Converter implementation.
As McDowel clearly stated in the comments - EN locale states that , is a delimiter for thousands and . is a delimiter for decimal point.. if you like to use "," as decimal separator, use a locale that has given format (for example french (fr))
In java i would suggest following:
// Using french locale as it is in form of "123 456 789,012345"
DecimalFormat df = (DecimalFormat)
NumberFormat.getInstance(Locale.FRENCH);
df.setParseBigDecimal(true);
// Replace all dots (due to the french format) so we handle "." as well as ","
hodnota = hodnota.replace('.', ',');
try {
return (BigDecimal) df.parseObject(hodnota);
} catch(ParseException e) {
// TODO: What ever you desire
}