Comments 43
У всех возник вопрос что такое МОММАЙЕ ??? — а вы не написали, ай-ай-ай!!!
Оно ещё и не копипастится!
Посещаемость статьи «Десятичный разделитель» в Википедии (первого результата при поиске «моммайе» и источника картинки) за вчерашний день увеличилась в 10 раз.
Знак, похож на запятую "٫" и используемый в арабских странах
А почему бы просто все внутренние строковые представления вещественных чисел держать, например, с точной? Тогда можно создать CultureInfo для «en-GB». И тогда писать так: double value = Double.Parse(«0.5», new CultureInfo(«en-GB»));
«с точкой». Опечатался.
Можно и так. Это не суть важно каким способом обойти это, главное помнить, что такое может произойти.
Простите, а зачем может понадобиться хранить представления вещественных чисел в виде строки?
Я использую double.Parse(), там в явном виде можно задать формат разделителя, так что эпичные костыли с заменой в строке не нужны
Интересно, когда человечество придет к единому стандарту?..
Можно вопрос? А о чём статья на три экрана? Я увидел мысль о том, что в разных странах разный разделитель и мысль, что можно заменить в строке запятую/точку/моммайе на нужный нам разделитель и радоваться. Ещё я увидел четыре картинки, из которых три — иллюстрированная инструкция по поиску региональных настроек.
Это уже не смешно.
Это уже не смешно.
Было бы лучше, если статья была бы размером в 3 строки. Из которых нельзя сделать никаких выводов.
Было бы лучше, если бы не была статья, в которой абсолютно тривиальная идея разбавлена водой на три экрана.
Нет, ну серьёзно, вы действительно считаете что в этой статье поделились чем-то нестандартным/новым/интересным/тем, чего не знает 90% программистов на этой планете? Если что, без обид, просто я правда не вижу смысловой нагрузки, которая, по мне, должна быть в статье на хабре.
Нет, ну серьёзно, вы действительно считаете что в этой статье поделились чем-то нестандартным/новым/интересным/тем, чего не знает 90% программистов на этой планете? Если что, без обид, просто я правда не вижу смысловой нагрузки, которая, по мне, должна быть в статье на хабре.
Вообще, можно установить текущую культуру на поток или использовать Parse с IFormatProvider, соответствующим нужной культуре. Это было бы правильнее.
Что за костыли в тематическом блоге? Мало того, что некрасивое решение, так еще ж и работать будет только для указанного частного случая.
Вы же, надеюсь, понимаете, что занимаясь подобной бездумной заменой вы запросто можете получить из совершенно корректного «американского» числа «10,000,000.05» (тут запятая — разделитель групп для удобства чтения) бредовое «10.000.000.05»?
Вы же, надеюсь, понимаете, что занимаясь подобной бездумной заменой вы запросто можете получить из совершенно корректного «американского» числа «10,000,000.05» (тут запятая — разделитель групп для удобства чтения) бредовое «10.000.000.05»?
Я думаю что число «10,000,000.05» не совсем корректно, и распарсить его можно только при помощи замены запятой. Т.к. при преобразовании этого числа будет вызвано исключение.
Если при преобразовании использовать культуру «en-US», то исключения не будет. А вот если, как вы и сделали, получить из культуры только CurrencyDecimalSeparator, и тупо заменить все запятые на него — то будет.
UFO just landed and posted this here
В разных странах разный не только разделитель, но например алгоритм преобразования регистров символов.
Не могу не вспомнить фичу в.нет из-за которой игнор-кейс сравнение строк содержащих англ. буквы «i» в разных регистрах не сработает если у пользователя выбрана турецкая локаль.
Т.е. String.Compare(«i», «I», true) возвратит отличное от 0 значение.
А происходит такое от того, что в турецком языке есть 4 буквы i: англ. i маленькая, англ. i большая, англ. I маленькая и англ. I большая. У проблемы есть решение, но по умолчанию происходит именно так.
Не могу не вспомнить фичу в.нет из-за которой игнор-кейс сравнение строк содержащих англ. буквы «i» в разных регистрах не сработает если у пользователя выбрана турецкая локаль.
Т.е. String.Compare(«i», «I», true) возвратит отличное от 0 значение.
А происходит такое от того, что в турецком языке есть 4 буквы i: англ. i маленькая, англ. i большая, англ. I маленькая и англ. I большая. У проблемы есть решение, но по умолчанию происходит именно так.
Ну вот… Кто афтор картинки?
Центральная Азия, да, вон то серое пятно по середине, должно быть зеленым. Потому что бывший СССР, и стандарты и в России и там основаны на ГОСТах, а чаще их повторяют.
Центральная Азия, да, вон то серое пятно по середине, должно быть зеленым. Потому что бывший СССР, и стандарты и в России и там основаны на ГОСТах, а чаще их повторяют.
А не лучше ли использовать Convert.ToDouble(«your string», CultureInfo.CurrentCulture), либо более безопасную версию double.TryParse? При выводе и валидации тоже использовать пользовательскую культуру. Получите глобализацию из коробки — будет работать даже если пользователь умудрится переопределить десятичный разделитель.
большинство современных программ знают, какой именно разделитель используется системой
Если бы это было так… К сожалению, в русской версии Microsoft (!!!) Office (!!!) 2003 (!!!) вылетала ошибка при отображении выпадающего списка межстрочного расстояния, если поставить английскую локаль. 3dsMax русские локали не любит и всячески глючит при ручном вводе чисел.
Это передовой софт с многолетней разработкой. Что уж говорить про мелочь пузатую…
Недавно майкрософту баг по бете пятого сервелата сообщал — они при сохранении—загрузке xaml использовали как раз не инвариант, а системную локаль: в итоге на моей русской машине 5.2 превращалось в 5,2, что для xaml неприемлимо. Так что да — единый формат и язык спасли бы мир :-).
У нас примерно такие практики:
1. Ставим StyleCop и он заставит вас всегда передавать CultureInfo во всякие double.Parse и пр. Даже Int32 порой может не распарситься взависимости от региональных настроек.
2. Стараемся не использовать строки для хранение нестроковых данных (те же double)
3. Там, где строками нужно общаться внутри программы (записать/прочитать файл, отправить по сети и пр), используется только CultureInfo.InvariantCulture.
4. Только при отображении пользователю (или попытке прочитать, что же ввел пользователь) используется CultureInfo.CurrentUICulture.
5. Не совсем в тему, но все же: даты (DateTime) внутри программы только в UTC (DateTime.UtcNow) только на стороне UI переводим в локальное время.
1. Ставим StyleCop и он заставит вас всегда передавать CultureInfo во всякие double.Parse и пр. Даже Int32 порой может не распарситься взависимости от региональных настроек.
2. Стараемся не использовать строки для хранение нестроковых данных (те же double)
3. Там, где строками нужно общаться внутри программы (записать/прочитать файл, отправить по сети и пр), используется только CultureInfo.InvariantCulture.
4. Только при отображении пользователю (или попытке прочитать, что же ввел пользователь) используется CultureInfo.CurrentUICulture.
5. Не совсем в тему, но все же: даты (DateTime) внутри программы только в UTC (DateTime.UtcNow) только на стороне UI переводим в локальное время.
Пожалуйста, объясните почему при использовании InvariantCulture, если разделитель локали отличается от разделителя в тексте, получается странный результат:
Можно ли это как-то избежать, кроме как
double lon = Convert.ToDouble("12,34", CultureInfo.InvariantCulture); // 1234.0
Можно ли это как-то избежать, кроме как
Replace( ',' , separator);Потому что в таком случае оно принудительно игнорирует символы, если они не являются разделителем. В данной ситуации запятая считается за недопустимый символ. Хотя данный случай по идее должен восприниматься верно. Тут я даже не знаю чем помочь. Если найду ответ на данный вопрос — обязательно Вам сообщу.
double val = Convert.ToDouble("12,34");
MessageBox.Show(val.ToString()); //12,34
val = Convert.ToDouble("12.34", CultureInfo.InvariantCulture);
MessageBox.Show(val.ToString()); //12,34
val = Convert.ToDouble("12,34", CultureInfo.InvariantCulture);
MessageBox.Show(val.ToString()); //1234
Т.е. по сути InvariantCulture мы указываем, из какого варианта нам переводить, если не указываем — разделитель по умолчанию (запятая), если указываем — международный (точка). Главное Вам в проекте всегда помнить о том, где и что применяется. Т.е. либо работая с точкой всегда указывать — и будет работать с InvariantCulture, либо работать с разделителем по умолчанию, но тогда может возникнуть проблемы с несовместимым для этого софтом.
.
Эта статья сделала главное — за 15 секунд гугления дала мне «путь», где лежит символ разделителя. Спасибо.
Sign up to leave a comment.
То, что нужно помнить о десятичном разделителе