使用Java Double.parseDouble和Android中的相同方法有区别吗？

Question

The reason I ask is because I have 2 exact same bits of code in an android app and in a java program doing the same thing (collecting tidal data):

String[] string4 = tide4.replaceAll("[LmH]", "").split(" ");
         Time4 = string4[0];
         String height4 = string4[1].replaceAll("\\s", "");

         System.out.println("HEIGHT4 = " + "'" + height4 + "'" );

        //Convert the Meters into feet for tide heights
      double heightM4 = Double.parseDouble(height4); //FAILS ON THIS LINE IN **JAVA** NOT IN ANDROID

Exception: java.lang.NumberFormatException: For input string: "6.24 "

However in the java program running on my machine it fails when parsing it? in Android it carries on fine. I have noticed one thing different when testing. When printing the value of "height4" in eclipse on my machine it outputs something like this: HEIGHT4 = '6.24 ' <--Notice the space! In Android it outputs this: HEIGHT4 = '6.24'<--No Space? Nothing is different between the 2 bits of code except the platform they are running on( as far as I can see). What could the cause of this be? Something to do with that un-removable whitespace?

Answer 1

What could the cause of this be? Something to do with that un-removable whitespace?

I think it is everything to do with that mysterious character. It is clearly not a digit or one of the other characters that are valid in a number, and that would definitely result in a parse error.

What you need to do is to use a debugger or some trace printing to find out what the mysterious character is. For example:

    char last = height4.charAt(height4.length() - 1); 
    System.out.println("The last character codepoint is " + ((int) last));

then convert the codepoint to hexadecimal and look it up in the Unicode tables at http://unicode.org

Once you have done that, you can figure out where the mystery is coming from and / or what is the best way to get rid of it.

---

Advice: If I would you, I would focus on figuring out where the character is coming from. The fact that you are getting strange stuff is a worry, and points to the potential for other problems. If you just try to get rid of the bad stuff, then you may be sweeping a larger problem under the carpet; eg making it harder to find.

---

UPDATE - The 0x00A0 code point is the "non-breaking space" (NBSP) character in the LATIN-1 supplement:

• The String.trim() method doesn't remove this. It only removes ASCII control codes; ie 0x0000 through 0x0020 .

• In the regex language implemented by Pattern , "\\\\s" doesn't match all Unicode space variants. This Question has the solution: Java regular expression to match _all_ whitespace characters

The presence of a NBSP is not as problematic as "random characters", but it suggests that you are "scraping" your input from rendered text (eg HTML) and there are differences in the rendering or scraping processes between the two platforms. While not worrying per se , this is something you need to keep in mind.