0
 double test = Convert.ToDouble("39,618840‎");

this gives me a format exception, and I have tried using the Cultureinfo.invariantculture setting, it does the same.

Bohrend
  • 1,467
  • 3
  • 17
  • 26
  • Should we interpret that as 39 million (etc), or as 39 "and a bit"? Both are valid interpretations... – Marc Gravell Apr 04 '14 at 13:54
  • Invariant culture would expect a dot for the decimal separator, not a comma. You will need to specify a culture that uses the comma separator. – Golden Dragon Apr 04 '14 at 13:54

3 Answers3

5

You have a trailing invisible character after the zero. Remove it.

enter image description here

Then, this works:

var culture = CultureInfo.GetCultureInfo("FR-fr");       
var qty = Convert.ToDouble("39,618840", culture);
Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • ok ill mark as answerd thank you, but now obviously my next question is how do I remove this, but ill create a new question thanx – Bohrend Apr 04 '14 at 14:18
  • For the record, 8206 is the following character: [U+200E left-to-right mark](http://www.fileformat.info/info/unicode/char/200e/index.htm) – Tim S. Apr 04 '14 at 14:20
  • @user2042227 the answer to that is "find at what point it appeared, and remove it at source" – Marc Gravell Apr 04 '14 at 14:23
  • no I understand but, the thing is its a dynamic string so ill need to make a method te remove special invis chars – Bohrend Apr 04 '14 at 14:25
  • @user2042227 you might prefer to remove everything that isn't something you actively expect - there's a *LOT* of unicode characters ;p `0123456789.,-+E` would be a good starting point – Marc Gravell Apr 04 '14 at 14:35
1

There are some invalid characters in that string.

Looking at the hex string we see the following:

"39,618840‎" --> 0x22, 0x33, 0x39, 0x2c, 0x36, 0x31, 0x38, 0x34, 0x30, 0xe2, 0x80, 0x8e, 0x22

And the characters actually look like:

"39,618840â€Ẑ"
Kevin Hogg
  • 1,771
  • 25
  • 34
  • Actually, I'd say that "what they look like" is an invisible token. Those last few bytes are actually just one character. Gotta love unicode. – Marc Gravell Apr 04 '14 at 14:10
  • 1
    The bytes you show are UTF-8 encoded. If you enter `22 33 39 2c 36 31 38 34 30 e2 80 8e 22` at http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder, you'll see that it does not look like `â€Ẑ` unless you confuse the encodings. E2 80 8E decodes to [U+200E left-to-right mark](http://www.fileformat.info/info/unicode/char/200e/index.htm), an invisible formatting character. – Tim S. Apr 04 '14 at 14:19
  • I bow down to the superior knowledge on unicode, but I felt that Marc Gravell already stated things correctly (but in a nicer way) :p – Kevin Hogg Apr 04 '14 at 14:25
0
        if (myString.Contains(","))
            myString = myString.Replace(",", "");
        double mydouble = Double.Parse(myString);

Using the above method will parse a string into a double, your issue is the comma. If you intended for the comma to act as the decimal point, the following amendment can be made:

        myString = myString.Replace(",", ".");
Kris
  • 36
  • 1
  • 8
  • 1
    Replacing commas with periods is **not** the correct way to handle international formatting. However, as it happens, international formatting *is not the issue here*. The problem is actually an unrelated unicode character. – Marc Gravell Apr 04 '14 at 14:08