Pull to refresh

Comments 43

У всех возник вопрос что такое МОММАЙЕ ??? — а вы не написали, ай-ай-ай!!!
Оно ещё и не копипастится!
Знак, похож на запятую "٫" и используемый в арабских странах
А почему бы просто все внутренние строковые представления вещественных чисел держать, например, с точной? Тогда можно создать CultureInfo для «en-GB». И тогда писать так: double value = Double.Parse(«0.5», new CultureInfo(«en-GB»));
«с точкой». Опечатался.
Можно и так. Это не суть важно каким способом обойти это, главное помнить, что такое может произойти.
Простите, а зачем может понадобиться хранить представления вещественных чисел в виде строки?
В случае, когда эти числа были приняты из другой программы, в которой строковое представление числа изначально неправильное.
Много для чего. Как примеры: XML, CSV,…
Если эти файлы создаются людьми — не забудьте их предупредить, что Вы используете в качестве разделителя запятую. Могут возникнуть (и скорее всего возникнут) ситуации, когда данный подход принесет Вам много головной боли при работе с клиентами с разными локальными настройками.
Я использую double.Parse(), там в явном виде можно задать формат разделителя, так что эпичные костыли с заменой в строке не нужны
Ваш способ — бесспорно правильнее, я лишь описал, как это было решено мной.
Интересно, когда человечество придет к единому стандарту?..
Вспомните сколько проблем с переходом на IPv6, а вы говорите про десятичный разделитель, под который даже калькуляторы придется переделать
Можно вопрос? А о чём статья на три экрана? Я увидел мысль о том, что в разных странах разный разделитель и мысль, что можно заменить в строке запятую/точку/моммайе на нужный нам разделитель и радоваться. Ещё я увидел четыре картинки, из которых три — иллюстрированная инструкция по поиску региональных настроек.

Это уже не смешно.
Было бы лучше, если статья была бы размером в 3 строки. Из которых нельзя сделать никаких выводов.
Было бы лучше, если бы не была статья, в которой абсолютно тривиальная идея разбавлена водой на три экрана.

Нет, ну серьёзно, вы действительно считаете что в этой статье поделились чем-то нестандартным/новым/интересным/тем, чего не знает 90% программистов на этой планете? Если что, без обид, просто я правда не вижу смысловой нагрузки, которая, по мне, должна быть в статье на хабре.
Ну я очень сильно извиняюсь за то, что я настолько не опытен в написании статей, быть может когда-то с опытом и прийдет. Но это не повод даже не пытаться. Когда получу достаточно критики в свой адрес — тогда учту все свои ошибки и напишу статью получше, но уже на другую тему
Вообще, можно установить текущую культуру на поток или использовать Parse с IFormatProvider, соответствующим нужной культуре. Это было бы правильнее.
Что за костыли в тематическом блоге? Мало того, что некрасивое решение, так еще ж и работать будет только для указанного частного случая.

Вы же, надеюсь, понимаете, что занимаясь подобной бездумной заменой вы запросто можете получить из совершенно корректного «американского» числа «10,000,000.05» (тут запятая — разделитель групп для удобства чтения) бредовое «10.000.000.05»?
Я думаю что число «10,000,000.05» не совсем корректно, и распарсить его можно только при помощи замены запятой. Т.к. при преобразовании этого числа будет вызвано исключение.
Если при преобразовании использовать культуру «en-US», то исключения не будет. А вот если, как вы и сделали, получить из культуры только CurrencyDecimalSeparator, и тупо заменить все запятые на него — то будет.
так еще ж и работать будет только для указанного частного случая

Суть данной статьи не в том, какое решение будет для данного случая оптимальным, а в том, что можно напороться на ошибку там, где ее не ожидаешь. Я думаю что не все об этом помнят и знают.
Ну, программист тем и отличается от быдлокодера, что способен при встрече с ошибкой чуть-чуть подумать, понять, из-за чего она получилась и исправить её. Другое дело, что исправлять её можно либо костылём, либо по науке — этим отличается хороший программист от неважного.
UFO landed and left these words here
В разных странах разный не только разделитель, но например алгоритм преобразования регистров символов.
Не могу не вспомнить фичу в.нет из-за которой игнор-кейс сравнение строк содержащих англ. буквы «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 русские локали не любит и всячески глючит при ручном вводе чисел.

Это передовой софт с многолетней разработкой. Что уж говорить про мелочь пузатую…
Ну Meta Trader 4 — самая популярная программа для торговли на форексе, нельзя сказать что это мелочь пузатая.
Недавно майкрософту баг по бете пятого сервелата сообщал — они при сохранении—загрузке 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 переводим в локальное время.
Пожалуйста, объясните почему при использовании 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 секунд гугления дала мне «путь», где лежит символ разделителя. Спасибо.
Only those users with full accounts are able to leave comments. Log in, please.