Zahlenwerte in XML (Decimalseparator)

[HenryE]

Zahlenwerte in XML (Decimalseparator)


Hallo,

also ich bin mittlerweile ziemlich genervt von folgendem Problem. Dies sei evtl. auch als Warnung an Kollegen gemeint, die evtl. in die selbe Falle laufen.

Ich erstelle für die Verarbeitung von XML-Daten ein Schema und vergebe dort entsprechende Datentypen für die einzelnen Elemente.
Da nach W3C-Spezifikation Dezimalzahlen nur mittels Punkt als Trennzeichen angegeben werden dürfen, muß der Wert 1,34 als "1.34 angegeben werden. Sonst meckert eine Validierung gegen das Schema.

Aber jetzt kommt der dicke Hund. Wenn man nun mittels XML-Dokument oder die XML-Bindung auf ein XML-Dokument zugreifen möchte, dabei im System jedoch z.B. ein "," eingestellt ist (so wie im deutschen Schema eben), dann verwendet der Parser dieses Komma als Trennzeichen und wertet "1.34" als 134. Der Parser scheint sich also immer den Dezimal-Trenner aus den Gebietsschema-Einstellungen zu nehmen.
D.h., es wird kein Fehler geworfen, es wird halt eine völlig fasche Zahl zurückgeliefert.

Das Umbiegen der Gebietseinstellungen ist sicher keine gute Idee. Man benötigt also einen Weg, wie man dem Parser mitteilen kann, dass er ein "." als Dezimaltrenner benutzen soll.
Das einfachste wäre ja evtl. ein Processing-Anweisung oder irgendein Wert im XML-Dokument selbst. Nur habe ich da noch nichts finden können.
Ich habe lediglich in xsl das "xsl:decimal-format"-Konstrukt gefunden, aber das kann mir ja nicht wirklich weiterhelfen. Man abgesehen davon, dass ich nicht erst eine Transformation durchführen will.

Im Netzt habe ich nun schon viele Stunden gesucht und auch andere Beschreibungen des Problems gefunden. Jedoch war nie eine brauchbare (elegante) Lösung des Problems zu finden.
Nun dachte ich mir, dass Delphi-Nutzer (MSXML+Deutsches Gebietsschema) schließlich zur "Risikogruppe" für dieses Problem gehören müßten.

Vielen Dank für die Aufmerksamkeit
Grüße Henry

Systemumgebung: Delphi 2009 (alle Updates) + Vista

[himitsu]

tja, XML ist ja als systemübergreifendes Austauschformat definiert und spricht demnach immer englisch,
damit es keine Probleme gibt ... leider arbeiten die delphiinternen Typumwandlungen mit den lokalen Spracheinstellungen.

leider muß ich zugeben, daß es dafür auch in meiner Lib noch keine "richtige" Lösung gibt, vorallem da dort die Werte auch mal via Variant ausgetauscht werden und demnach die Umwandlung über Delphi und dessen geladene Spracheinstellungen laufen

[Namenloser]

Ich weiß nicht, ob das für dich eine "elegeante" Lösung ist, aber zumindest ist sie einfach:
DecimalSeparator := '.';

[himitsu]

Zitat von NamenLozer:

Ich weiß nicht, ob das für dich eine "elegeante" Lösung ist, aber zumindest ist sie einfach:

einfach son nd dann läuft mit dem XML vieles besser,
aber dafür spricht dann deine restliche Anwendung auch plötzlich (etwas) englisch.

z.B. möchte nmun FloatToStr einen Punkt statt Komma, Format nimmt nun auch einen Punkt usw.
heißt: da wo es .B. um Usereingaben geht, wird nun nicht mehr die Systemeinstellung genommen.

[HenryE]

Mit SysUtils.DecimalSeparator habe ich natürlich bereits experimentiert. Jedoch nur mit Teilerfolg. Beim Schreiben von Knoten und nachfolgendem Speichern werden zumindest Punkte ins XML geschrieben. Beim Lesen kommt aber immer noch Quatsch heraus.
Komisch, jetzt bin ich erst recht verwirrt.

Eigentlich will ich die XML-Bindung verwenden, da diese ja einen riesigen Komfort bietet. Da ist es ja genau Sinn und Zweck, nicht noch eigene Umwandlungsrutinen dazwischen zu schalten, sondern typsicher auf die Elemente zuzugreifen.

[himitsu]

also bei meinem himXML gibt es derzeit zumindestens keine Probleme, wenn es auf Systemen mit gleichen Spracheinstellungen verwendet wird, da ihm Punkt und Komma egal sind ... allerdings landen dann auf einem deutschen System dann natürlich die Werte mit Komma in der Datei

[HenryE]

Ohne XML-Bindung hatte ich früher auch eine eigene Umwandlungsrutine eingebaut, die selbst geschaut hat, ob im String ein Punkt oder Komma vorhanden ist. Aber nun möchte ich die Vorzüge der XML-Bindung (die im Grunde echt cool ist, insbesondere wenn mann über das Schma eine echte Typisierung der Elemente reinbringt) nutzen und muß zuverlässig schema-konforme XML-Dateien erzeugen, weil diese noch von Fremdsystemen weiterverarbeitet werden sollen.

Was mich wundert: da müssen doch schon einige in diese Falle getappt sein, da man sie unter Umständen gar nicht bemerkt.
Aus 1.44 wir 144, aus 1.3872833 immerhin schon 13872833. Das ist doch ein Scheunentor zu allerlei Unfug!

[Namenloser]

Zitat von himitsu:

Zitat von NamenLozer:

Ich weiß nicht, ob das für dich eine "elegeante" Lösung ist, aber zumindest ist sie einfach:

einfach son nd dann läuft mit dem XML vieles besser,
aber dafür spricht dann deine restliche Anwendung auch plötzlich (etwas) englisch.

z.B. möchte nmun FloatToStr einen Punkt statt Komma, Format nimmt nun auch einen Punkt usw.
heißt: da wo es .B. um Usereingaben geht, wird nun nicht mehr die Systemeinstellung genommen.

Schon klar, aber immer noch besser als wenn falsche Werte eingelesen werden. Man könnte auch im restlichen Teil des Programms die Funktion mit dem zweiten Parameter FormatSettings aufrufen, um das zu umgehen.

[HenryE]

Das Ganze muß doch ohne das munuelle Aufrufen von eigenen Umwandlungsrutinen zu lösen sein, da ansonsten die XML-Bindung so nicht verwendet werden kann. Auf die kann und will ich nicht verzichten.
Übrigens scheint es hier
https://forums.codegear.com/thread.j...20509&tstart=0
um das selbe Problem zu gehen. Aber eine Lösung kann ich dort auch noch nicht finden. Im Prinzip muß der Parser ja nur wissen, dass er ein bestimmtes Zeichen benutzen soll, aber eben nicht das, was im System-Gebietsschema hinterlegt ist.

Grüße Henry

[alzaimar]

Ich formatiere/konvertiere meine Float-Werte in/aus XML gnadenlos selbst. Eine bessere Idee habe ich auch nicht.