Laden...

[gelöst] - Zahlen anzeigen/parsen aufgrund von Format ohne CultureInfo

Erstellt von mosspower vor 8 Jahren Letzter Beitrag vor 8 Jahren 2.049 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 8 Jahren
[gelöst] - Zahlen anzeigen/parsen aufgrund von Format ohne CultureInfo

Hallo,

ist es möglich in C# Nummern, z.B. Decimal verschieden zu formatieren nur anhand eines Patterns / Expression ohne Cluture-Objekten?

Ich kenne das nur mit den Culture-Objecten (IFormatProvider) - ist es auch irgendwie anders möglich.

Beispiel. Ich habe die Zahl 2500.50 (englisch standard, also so in der DB), jetzt gibt es auf der Applikationsumgebung jeweils zwei User aus Deutschland und USA und jeweils auf einem en-US-System und auf einem de-System, welche die Zahlen unterschiedlich angezeigt bekommen möchten.

(de) User a) 2.500,50
(de) User b) 2,500.50
(us) User c) 2.500,50
(us) User d) 2,500.50

Gibt es da eine Möglichkeit das an einem Pattern (# und / oder 0) festzumachen ** OHNE ** eine CultureInfo, bzw. IFormatProvider?

K
89 Beiträge seit 2013
vor 8 Jahren

Im Quellcode wird die Trennung zu den NAchkommastellen ja auch als "." angegeben.
Mein Ansatz wäre das ganze in einen String zu wandeln.
Dann würde ich das ganze splitten in Vor- und NAchkommastellen.
Dann musst du halt alle drei Ziffern ein Zeichen (. oder,) einfügen und am Ende das ganze mit dem jeweils anderen Zeichen zusammenfügen.
Bestimmt geht das auch elegant mit Regex.

T
2.219 Beiträge seit 2008
vor 8 Jahren

Du könntest doch das Format mit einer CultureInfo vorgeben.
Ich würde hier die CultureInfo en-US nehmen.
Spielereien mit irgendwelchen String Formaten würde ich ehrlich gesagt nicht machen.
Dann bist du in der Pflicht dich um die Korrektheit des Formats beim auslesen zu kümmern, was den Aufwand der Wartbarkeit auch noch erhöht sowie die Fehleranfälligkeit.

Nachtrag:
Hatte dich wohl falsch verstanden.
Aber wenn du deinem Nutzern die jeweiligen Formate anzeigen willst, musst du die CultureInfo nutzen.
Genau dafür sind die da.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

W
872 Beiträge seit 2005
vor 8 Jahren

Wie ist denn die Spalte in der Tabelle definiert?
Ich bin sehr verwundert, dass die Datenbank eine Zahl mit Locale speichert und nicht als Zahl - sei es als (small/)money oder decimal/numeric.
Du solltest ganz klar zwischen dem Modell/Datenbank und der Darstellung trennen.

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 8 Jahren

Ich danke euch für die Anregungen.

Ich hab es jetzt mit dem NumberFormatInfo-Objekt gelöst.

Beispiel für user a:


Dim deci As Decimal = 2500.5
Dim nfi As NumberFormatInfo = New NumberFormatInfo()
nfi.NumberDecimalSeparator = ","
nfi.NumberGroupSeparator = "."
 Console.WriteLine(deci.ToString(",#.00", nfi)) // ==> 2.500,50

und das geht auch unabhängig von der aktuellen (Thread) CultureInfo 👍

16.806 Beiträge seit 2008
vor 8 Jahren

Ganz ehrlich: was soll das bringen außer einer höheren Fehleranfälligkeit / Abweichung von Standard?
Würde mich interessieren.

Datenbanken ist die Culture egal; wenn es das nicht ist, dann wurde etwas falsch gemacht.
Aufgrund von Rundungsfehlern etc werden Geldwerte sowieso in der Mill-Darstellung über Ganzzahlen gespeichert; (ansonsten vergeben einige Prüfinstitute für Software zB auch kein entsprechendes Zertifikat, falls das relevant sein sollte. 2.500,50 wären demnach einfach 2500500 falls ich mich nun nicht beim Faktor vertan hab).

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 8 Jahren

Ich bin der Meinung, dass hier die Fehleranfälligkeit gegen 0 geht und vom Standard auch nicht abgewichen wird, denn in meinem Fall handelt es sich um eine Option, die Usern anbietet, die Formatierungen nach ihrem Gusto einzustellen völlig unabhängig von der Culture der Laufzeitumgebung und Herkunft der User, bzw. der eingestellten Sprache.

O
79 Beiträge seit 2011
vor 8 Jahren

Das ist sehr löblich - aber IMHO der falsche Weg.

benutzerdefinierte Formatierungen betreffen nicht nur Währungen (von denen du übrigens nicht alle Optionen anbietest - Währungskennzeichen und -position anyone ?). Das Spiel geht weiter mit Datumsangaben: Trenner zwischen den einzelnen Elementen, Position der einzelnen Elemente, 2- oder 4-stellige Jahreszahl und und und. Und das ganze nocheinmal für die Uhrzeit.

Tatsächlich ist es so, das der Benutzer in der Regel genau weiß, welche Landesspezifische Formatierung er gerne haben will. Wenn jemand die en-US-Formatierung für Währungen will, dann will er fast immer auch das Datum in en-US. Windows hat weit über 150 verschiedene, länderspezifische Formatierungen in seinen Innereien (und da gibt es echt einige haarsträubende Exoten drunter), die du erst umständlich nachprogrammieren müßtest. Spätestens bei den Chinesen, wo der 02.06.2015 überhaupt keine von uns gewohnte Formatierung besitzt (ja nicht mal entsprechende Symbole), bist du geplatzt 😉

Ich würde dem User eine Liste der verfügbaren Formatierungen anbieten und damit dann arbeiten.

16.806 Beiträge seit 2008
vor 8 Jahren

Ich bin der Meinung, dass hier die Fehleranfälligkeit gegen 0 geht

Ja; da täuscht Du Dich gewaltig 😃 Ich würde es wie OlafSt machen und gewisse Optionen anbieten. Bei Freitext gibt es immer eine Fehleranfälligkeit höher 0 - immer. Ohne Ausnahme.

5.657 Beiträge seit 2006
vor 8 Jahren

Hi OlafSt,

Spätestens bei den Chinesen, wo der 02.06.2015 überhaupt keine von uns gewohnte Formatierung besitzt (ja nicht mal entsprechende Symbole), bist du geplatzt 😉

Ich geb dir zwar völlig Recht, mit dem was du sagst. Aber das Beispiel ist ein bißchen unpassend, denn in China verwendet man seit 1949 auch den Gregorianischen Kalender.

Christian

Weeks of programming can save you hours of planning

O
79 Beiträge seit 2011
vor 8 Jahren

Das stimmt, sie benutzen den gregorianischen Kalender. Darum ist der 02.06.2015 in unseren Breiten auch der 02.06.2015 in China. Keine Frage. Aber die Chinesen haben eine eigentümliche Schrift und ich habe den 02.06.2015 in Chinesisch auch hier posten wollen - nur leider kriegt das Forum das nicht so ganz hin.

Darum hänge ich das genannte Datum in chinesischer Form mal hier als PNG dran. In der ersten Zeile, wie es üblicherweise geschrieben wird, darunter die verwestlichte Form mit Zahlen wie wir sie kennen.