NumberFormat incorrectly parses numbers contining spaces
Description
Consider the following test case:
This test case fails since the string "1 2" is parsed as number (int)12 using the ICU code. An equivalent testcase that uses the Java SE NumberFormat parser produces a number with value (int) 1 as expected.
Further experiments show that all spaces may be ignored by ICU. For example, Sun fails to parse " 1 2 " and leaves the parse position at 0, whereas ICU parses the whole string and consumes the spaces.
Tested with ICU4J-4.2.1
Activity
Trac Comment 4 by —2009-11-12T02:17:27.000Z
java spec says: If IntegerOnly is set, will stop at a decimal point (or equivalent; e.g., for rational numbers "1 2/3", will stop after the 1), It implies that blank space will be treated as decimal point. Though it is rather vague. I think ticket 7128 doesn’t follow the spec. We should fix it later.
Trac Comment 6 by —2010-01-15T05:19:52.000Z
This behavior is as designed. We already shipped DecimalFormat supporting the extended separator matching behavior in ICU4J 4.0 and 4.2. To support JDK compatible behavior, we need to provide a way to control the extended separator matching logic used in DecimalFormat implementation. I wrote a design note - http://site.icu-project.org/design/number-parsing/icu4j-number-parsing-problems - however, it looks we cannot get a conclusion soon. So I decided to introduce a configuration property to disable the extended separator matching via system property for now. We'll use a new ticket to discuss about API access for future releases.
Trac Comment 8 by cbrowning@28949996bd5864b4—2014-08-07T20:58:18.623Z
It took a long time to locate the configuration property mentioned above. For others who have the same problem: The "fix" involves setting the com.ibm.icu.text.DecimalFormat.SkipExtendedSeparatorParsing ICU config flag to true.
Trac Comment 9 by —2016-10-05T23:15:05.064Z
Milestone 4.3.4 deleted
