"Sicheres" Umwandeln von Zeichenkette in Zahl

[stifflersmom]

Moin,

ivh muss relativ häufig Daten aus CSV-Dateien einlesen, bzw. die User bei uns im Haus bekommen Exceltabellen aus den unterschedlichsten Ländern und da ist eine willkürliche Formatierung von Zahlen fast selbstverständlich.
Ich habe mir gerade eine kleine Hilfsfunktion geschrieben, die zumindest für deutsche und englische Formatierungen funktionieren sollte.
Ich hätte gerne noch ein paar Ideen bzw. Vorschläge von euch, wie das ganze vielleicht noch umfassender werden kann, ohne gleich dafür einen zig-tausend Zeilen Block zu erstellen...

Delphi-Quellcode:

function SaveStringTofloat(aString: string): Double;
const
  Kickchar = ' €$';
  Sepchar = ',.';
var
  i, y: Integer;
  sLang: string;
  dezSep: char;
begin
  Result := 0;
  y := 0;
  sLang := '';
  // Festgelegten Dezimalseparator merken
  dezSep := DecimalSeparator;
  try
    if aString <> '' then
      begin
        // für die Umwandlung den '.' als Dezimalseparator festlegen
        DecimalSeparator := '.';
        // Zuerst alle Falschzeichen raus
        for i := 1 to length(Kickchar) do
          aString := StringReplace(aString, KickChar[i], '', [RfReplaceAll]);

        for i := Length(aString) downto 1 do
          begin
            // die übergebene Zeichenkette von rechts aufdröseln
            // und die Anzahl der Zeichen merken, da der Dezimalseparator eigentlich nicht
            // weiter als vier zeichen von rechts vorhanden sein sollte
            // Ok, bei mehr als drei Nachkommastellen fahren wir gegen sie Wand... krach, bumms, quietsch
            inc(y);
            // mögl. Dezimalseparator gefunden
            if pos(aString[i], SepChar) > 0 then
              begin
                if (y <= 4) and (sLang = '') then
                  begin
                    if aString[i] = ',' then
                      sLang := 'de'
                    else
                      sLang := 'en';
                  end;
                // Bei mehr als 4 Stellen von rechts und keinem erkanntem Dezimalseparator bisher
                // wird es wohl eine 1000er-Formatierung sein
                if (y > 4) and (sLang = '') then
                  begin
                    if aString[i] = '.' then
                      slang := 'de'
                    else
                      sLang := 'en';
                  end;
              end;
          end;
        if sLang <> '' then
          begin
            if (slang = 'de') then
              begin
                // Deutsch: '.' als 1000-er Formatierung entfernen
                // Dezimalseparator wird auf '.' ersetzt
                aString := StringReplace(aString, '.', '', [rfReplaceAll]);
                aString := StringReplace(aString, ',', '.', [rfReplaceAll]);
              end
            else
              // kein deutsch, also ',' als 1000-er Formatierung entfernen
              aString := Stringreplace(aString, ',', '', [rfReplaceAll]);
          end;
        result := StrTofloat(astring);
      end;

  finally
    DecimalSeparator := dezSep;
  end;
end;

Moin

[Uwe Raabe]

Wirklich Delphi 2006 oder darf es auch etwas moderner sein?

[nahpets]

Anderer Ansatz:

CSV-Dateien mit Excel öffnen und dann mit Excelmitteln auslesen.

Dazu könnte man Excel aus Delphi heraus fernsteuern.
(Allerdings kann man da auch nicht absolut sicherstellen, dass das lokale Excel mit jeder beliebigen CSV-Datei vom Rest der Welt sicher und korrekt umgehen kann.)

Ein schon etwas älteres Tutorial ist hier zu finden: Excel mit OLE-Automation steuern

Egal was Du bei Deinem Ansatz machst und wie gut Du ihn umgesetzt bekommst. Irgendwann kommt eine Datei, die nicht passt. Murphy wird gewinnen ;-) (Im Prinzip hast Du das Problem in Deinem Kommentar schon benannt.)

[stifflersmom]

Ja, zu meiner Schande mus ich gestehen, dass das größte Projekt bei uns noch in 2006 geschrieben ist.
Den Umzug zu Beerlin oder Tokyo habe ich noch nicht vollzogen...

[Uwe Raabe]

Ich kenne jetzt nicht die genauen Anforderungen, aber so spontan würde ich es mit

Delphi-Quellcode:

function TryStrToFloat(const S: string; out Value: Single;
  const FormatSettings: TFormatSettings): Boolean; overload;

und verschiedenen FormatSettings versuchen. Natürlich würde die Kenntnis der Sprache vorab deutlich helfen.

[stifflersmom]

Wie gesagt, das sind je nach Zulieferer die verschiedensten Sprachen Italien, Türkei, Spanien...
Wir bekommen auch Dateien aus china, aber die lassen wir mal aussen vor

[Neutral General]

Zitat:

Zitat von stifflersmom (Beitrag 1382245)

Wie gesagt, das sind je nach Zulieferer die verschiedensten Sprachen Italien, Türkei, Spanien...
Wir bekommen auch Dateien aus china, aber die lassen wir mal aussen vor

Wer oder was generiert denn die Dateien?
Bzw.. falls ihr das Format festlegt, dann könnt ihr auch den Dezimalseparator bestimmen.
Dann muss jeder Kunde nur schauen dass er es richtig abspeichert und ihr könnt ohne Probleme alles lesen ohne 353 verschiedene Sprachen/Notationen unterstützen zu müssen.

[Uwe Raabe]

Um meinen Vorschlag mal zu konkretisieren (hoffe mal, das geht alles unter D2006):

Delphi-Quellcode:

var
  AllFormatSettings: array of TFormatSettings;

procedure InitFormatSettings;
const
  cLocales: array[0..5] of Integer
      = (
         1031, { German }
         1033, { English }
         1040, { Italian }
         1055, { Turkish }
         3082, { Spanish }
         LOCALE_USER_DEFAULT);
var
  I: Integer;

begin
  SetLength(AllFormatSettings, Length(cLocales));
  for I := 0 to Length(cLocales) - 1 do begin
    GetLocaleFormatSettings(cLocales[I], AllFormatSettings[I]);
  end;
end;

function TryStrToFloatAll(const S: string; out Value: Double): Boolean;
var
  I: Integer;
begin
  Result := True;
  for I := 0 to Length(AllFormatSettings) - 1 do begin
    if TryStrToFloat(S, Value, AllFormatSettings[I]) then Exit;
  end;
  Result := False;
end;

[sakura]

Zitat:

Zitat von Uwe Raabe (Beitrag 1382248)

Um meinen Vorschlag mal zu konkretisieren (hoffe mal, das geht alles unter D2006):

Ein generelles Problem bleibt aber, zumindest in der Theorie.

Im Englischen ist die Zahl 10,345 für den PC eine 10345
Im Deutschen ist die Zahl 10,345 für den PC ein 10 und ein paar Zerquetschte.

Daher kann keine Lösung garantieren, dass die Zahlen korrekt interpretiert werden, wenn der Nutzer nicht darüber wacht.

...:cat:...

[stifflersmom]

Zitat:

Zitat von sakura (Beitrag 1382249)

Zitat:

Zitat von Uwe Raabe (Beitrag 1382248)

Um meinen Vorschlag mal zu konkretisieren (hoffe mal, das geht alles unter D2006):

Ein generelles Problem bleibt aber, zumindest in der Theorie.

Im Englischen ist die Zahl 10,345 für den PC eine 10345
Im Deutschen ist die Zahl 10,345 für den PC ein 10 und ein paar Zerquetschte.

Daher kann keine Lösung garantieren, dass die Zahlen korrekt interpretiert werden, wenn der Nutzer nicht darüber wacht.

...:cat:...

Ich gehe erst mal davon aus, dass Zahl mit einer 1000-er Formatierung auch mit Nachkommastellen dargestellt werden. Deshalb ah mein Ansatz, die Zeichenfolge von rechts anzugehen und je nach Position eines Zeichens, dass einem möglichen Separator entspricht, dass entweder als dezimalseparator oder Tausenderpunkt zu erkennen.

[stifflersmom]

Zitat:

Zitat von Uwe Raabe (Beitrag 1382248)

Um meinen Vorschlag mal zu konkretisieren (hoffe mal, das geht alles unter D2006):

Delphi-Quellcode:

var
  AllFormatSettings: array of TFormatSettings;

procedure InitFormatSettings;
const
  cLocales: array[0..5] of Integer
      = (
         1031, { German }
         1033, { English }
         1040, { Italian }
         1055, { Turkish }
         3082, { Spanish }
         LOCALE_USER_DEFAULT);
var
  I: Integer;

begin
  SetLength(AllFormatSettings, Length(cLocales));
  for I := 0 to Length(cLocales) - 1 do begin
    GetLocaleFormatSettings(cLocales[I], AllFormatSettings[I]);
  end;
end;

function TryStrToFloatAll(const S: string; out Value: Double): Boolean;
var
  I: Integer;
begin
  Result := True;
  for I := 0 to Length(AllFormatSettings) - 1 do begin
    if TryStrToFloat(S, Value, AllFormatSettings[I]) then Exit;
  end;
  Result := False;
end;

das werde ich gleich mal ausprobieren.

[stifflersmom]

Zitat:

Zitat von Neutral General (Beitrag 1382246)

Wer oder was generiert denn die Dateien?
Bzw.. falls ihr das Format festlegt, dann könnt ihr auch den Dezimalseparator bestimmen.
Dann muss jeder Kunde nur schauen dass er es richtig abspeichert und ihr könnt ohne Probleme alles lesen ohne 353 verschiedene Sprachen/Notationen unterstützen zu müssen.

In dem Sinne gibt es da keine einheitliche Definition.
Unsere Disponenten bekommen halt in den unterschiedlichsten Art und Weisen ihre Preislisten von den Lieferanten zugeschickt. Mal als Excel, mal als CSV.
Diejenigen, die diese Dateien definieren, sind meistens nie die IT-Abteilung sondern Kaufleute, und Formate mit denen abzusprechen funktioniert meist nicht.

[stifflersmom]

Zitat:

Zitat von stifflersmom (Beitrag 1382274)

Zitat:

Zitat von Uwe Raabe (Beitrag 1382248)

Um meinen Vorschlag mal zu konkretisieren (hoffe mal, das geht alles unter D2006):

das werde ich gleich mal ausprobieren.

Toller, kompakter Code!!

Jo, funktioniert auch in 2006.
Nur ist das Problem der 1000-er Formatierung damit nicht erschlagen.
Eine Test mit 1.024,23 ergibt dann ein False mit einer 0 als Ergebnis.

[Uwe Raabe]

Zitat:

Zitat von stifflersmom (Beitrag 1382277)

Nur ist das Problem der 1000-er Formatierung damit nicht erschlagen.
Eine Test mit 1.024,23 ergibt dann ein False mit einer 0 als Ergebnis.

Ah ja, ich vergaß! Nein, dann funktioniert das so nicht. Dann muss man erst den Dezimalseparator ermitteln und dann die Tausendertrenner eliminieren. Ist dann allerdings nicht mehr so kompakt:

Delphi-Quellcode:

function TryStrToFloatAll(const S: string; out Value: Double): Boolean;
var
  sep: set of Char;
  dez: Char;
  I: Integer;
begin
  Result := False;

  { collect possible decimal separators }
  sep := [];
  for I := 0 to Length(AllFormatSettings) - 1 do begin
    Include(sep, AllFormatSettings[I].DecimalSeparator);
  end;

  { determine current decimal separator }
  dez := #0;
  for I := Length(S) downto 0 do begin
    if S[I] in Sep then begin
      dez := S[I];
      Break;
    end;
  end;
  { no decimal separator => wrong input. Try StrToInt instead. }
  if dez = #0 then Exit;

  Result := True;
  for I := 0 to Length(AllFormatSettings) - 1 do begin
    { try all formatsettings with found decimal separator }
    if dez = AllFormatSettings[I].DecimalSeparator then begin
      { eliminate thousand separator before conversion }
      if TryStrToFloat(StringReplace(S, AllFormatSettings[I].ThousandSeparator, '', [rfReplaceAll]), Value, AllFormatSettings[I]) then Exit;
    end;
  end;
  Result := False;
end;

Wenn sicher ist, daß nur Punkt und Komma als Separatoren auftreten können, dann ließe sich der Code natürlich auch etwas schlanker gestalten. Ich habe mir aber jetzt die Settings der einzelnen Länder nicht angeschaut.

[stifflersmom]

Hallo Uwe,

von dem Code bin ich auf jeden Fall erst Mal beeindruckt.
Den werde ich mir gleich mal genauer zu Gemüte führen.

Danke erst mal

[nahpets]

Mal 'ne etwas altertümliche Idee:

Es gibt doch die Prozedure VAL. Könnte man damit nicht "austesten"?

Delphi-Quellcode:

var 
  I : Float; // oder sowas
  Code: Integer;
begin
  { Text aus Zeichenfolge übernehmen }
  Val(Zeichenfolge, I, Code);
  { Fehler bei der Konvertierung in Zahl? }
  if Code <> 0 then begin
    // In Code haben wir jetzt die Position des Zeichens, 
    // dass eine Konvertierung in eine Zahl verhindert.
    // Dieses Zeichen könnte man jetzt auswerten, um zu erfahren
    // ob es der Tausendertrenner oder der Dezimalseparator ist.
    // Einen derartigen Test müsste man dann (hoffentlich nur) für die erste Zeile
    // einer CSV-Datei machen und könnte damit ermitteln, welche Zeichen
    // zu tauschen sind.
  end;
end;

[stifflersmom]

Zitat:

Zitat von nahpets (Beitrag 1382282)

Mal 'ne etwas altertümliche Idee:

Es gibt doch die Prozedure VAL. Könnte man damit nicht "austesten"?

Delphi-Quellcode:

var 
  I : Float; // oder sowas
  Code: Integer;
begin
  { Text aus Zeichenfolge übernehmen }
  Val(Zeichenfolge, I, Code);
  { Fehler bei der Konvertierung in Zahl? }
  if Code <> 0 then begin
    // In Code haben wir jetzt die Position des Zeichens, 
    // dass eine Konvertierung in eine Zahl verhindert.
    // Dieses Zeichen könnte man jetzt auswerten, um zu erfahren
    // ob es der Tausendertrenner oder der Dezimalseparator ist.
    // Einen derartigen Test müsste man dann (hoffentlich nur) für die erste Zeile
    // einer CSV-Datei machen und könnte damit ermitteln, welche Zeichen
    // zu tauschen sind.
  end;
end;

Hab ich jetzt mal kurz ausgetestet.
ein Test mit 1.024,15 ergibt die Fehlerposition '6', das bedeutet dann, erst alle Punkte zu entfernen und anschließend eine Umwandlung des Kommas in einen Punkt.
Ja, auch as funktioniert dann.

[stifflersmom]

Zitat:

Zitat von Uwe Raabe (Beitrag 1382279)

Zitat:

Zitat von stifflersmom (Beitrag 1382277)

Nur ist das Problem der 1000-er Formatierung damit nicht erschlagen.
Eine Test mit 1.024,23 ergibt dann ein False mit einer 0 als Ergebnis.

Ah ja, ich vergaß! Nein, dann funktioniert das so nicht. Dann muss man erst den Dezimalseparator ermitteln und dann die Tausendertrenner eliminieren. Ist dann allerdings nicht mehr so kompakt:

Delphi-Quellcode:

function TryStrToFloatAll(const S: string; out Value: Double): Boolean;
var
  sep: set of Char;
  dez: Char;
  I: Integer;
begin
  Result := False;

  { collect possible decimal separators }
  sep := [];
  for I := 0 to Length(AllFormatSettings) - 1 do begin
    Include(sep, AllFormatSettings[I].DecimalSeparator);
  end;

  { determine current decimal separator }
  dez := #0;
  for I := Length(S) downto 0 do begin
    if S[I] in Sep then begin
      dez := S[I];
      Break;
    end;
  end;
  { no decimal separator => wrong input. Try StrToInt instead. }
  if dez = #0 then Exit;

  Result := True;
  for I := 0 to Length(AllFormatSettings) - 1 do begin
    { try all formatsettings with found decimal separator }
    if dez = AllFormatSettings[I].DecimalSeparator then begin
      { eliminate thousand separator before conversion }
      if TryStrToFloat(StringReplace(S, AllFormatSettings[I].ThousandSeparator, '', [rfReplaceAll]), Value, AllFormatSettings[I]) then Exit;
    end;
  end;
  Result := False;
end;

Wenn sicher ist, daß nur Punkt und Komma als Separatoren auftreten können, dann ließe sich der Code natürlich auch etwas schlanker gestalten. Ich habe mir aber jetzt die Settings der einzelnen Länder nicht angeschaut.

Auf jeden Fall ist das für mich großes Kino!
Klasse Code.
Wo stehen eigentlich genau diese

Delphi-Quellcode:

  cLocales: array[0..5] of Integer
      = (
         1031, { German }
         1033, { English }
         1040, { Italian }
         1055, { Turkish }
         3082, { Spanish }
         LOCALE_USER_DEFAULT);

Länderkosntanten?

[nahpets]

Ok, das Problem ist aber, dass man dann zwar weiß, wo der erste Fehler ist, aber das andere Zeichen quasi erraten muss.

Konkret: bei 1.024,15 und Fehler beim , sagt ja nicht, dass wir nach 'nem . suchen müssen, um ihn vorher zu entfernen. Hier ist ja irgendwie auch noch raten angesagt.

So gut war meine Idee dann auch wieder nicht, da immernoch interpretierbare Unwägbarkeiten übrigbleiben :-(

Das ginge nur dann verlässlich, wenn man definitiv weiß, das nur . und , als Problemfälle in Frage kommen, man nur nicht weiß, in welcher Reihenfolge.

Kann man sicherstellen, dass immer dann, wenn der Fehler bei einem , auftritt, der . zu entfernen ist und das , durch einen . zu ersetzen und im umgekehren Fall bei einem Fehler bei einem . das , zu entfernen ist und der . durch ein , zu ersetzen ist, mag das angehen. Können aber auch noch andere Alternativen (wobei mir keine einfällt) bestehen, wird's schon wieder unsicher.

[stifflersmom]

Zitat:

Zitat von nahpets (Beitrag 1382288)

Kann man sicherstellen, dass immer dann, wenn der Fehler bei einem , auftritt, der . zu entfernen ist und das , durch einen . zu ersetzen und im umgekehren Fall bei einem Fehler bei einem . das , zu entfernen ist und der . durch ein , zu ersetzen ist, mag das angehen. Können aber auch noch andere Alternativen (wobei mir keine einfällt) bestehen, wird's schon wieder unsicher.

Magst Du diesen Satz mal aufnehmen und als Anhang einfügen... :-)

Gruß

[nahpets]

Nö, lieber nicht, das ist so eine meiner tückischen Formulierungen, die dabei rauskommen, wenn ich vergeblich versuche, mich präzise auszudrücken. Man merkt daran, dass ich mich über viele Jahre mit Juristerei rumschlagen musste. Da muss dann in einem Satz alles Mögliche so sicher und korrekt und widerspruchsfrei formuliert werden, dass es am Ende doch wieder nur unverständlich ist. Oder kurz: Beamtendeutsch :-(

Und bei 'ner Aufnahme würd' ich vermutlich sehr arg ins Stottottottottotteren kommen ;-)

[Uwe Raabe]

Zitat:

Zitat von stifflersmom (Beitrag 1382287)

Wo stehen eigentlich genau diese

Delphi-Quellcode:

  cLocales: array[0..5] of Integer
      = (
         1031, { German }
         1033, { English }
         1040, { Italian }
         1055, { Turkish }
         3082, { Spanish }
         LOCALE_USER_DEFAULT);

Länderkosntanten?

https://msdn.microsoft.com/en-us/lib...edded.10).aspx

[Uwe Raabe]

Der Code soll natürlich nur als Richtlinie dienen. Natürlich muss man die ganze Sucherei nach den richtigen FormatSettings nicht bei jedem Wert machen. Einmalig am Anfang der Datei genügt. Danach sollte sich das ja nicht mehr ändern. (Hat Stephan ja in einem der Code-Comments schon erwähnt)

[stifflersmom]

Klar, nach Möglichkeit einmal feststellen und dann ab dafür.
Vielleicht müssen zuerst ein paar Werte geprüft werden, man stelle sich vor es steht eine 1,000 in der ersten Zeile. Da kann jetzt wirlich nicht sicher festgemacht werden, ob ein amerikanisches Zahlenformat ohne Nachkommastelle oder eine deutsche 1 mit drei Nachkommastellen vorliegt.
Aber grundsätzlcih, sollte schon in den ersten paar Zeilen eine mehr oder weniger eindeutige Identifikation möglich sein.

[mensch72]

wir gehen das per DoubleParse und "statistisch" an:
1. Harte Regel: in einem Zahlenfeld werden alle Leerzeichen elliminiert
2. Harte Regel: sobald in einem Zahlenfeld eine "nicht Ziffer" doppel auftaucht wird dies als 1000er Trennung behandelt und nun stets "eliminiert"
3. Harte Regel: wenn in einem Zahlenfeld verschiedene "nicht Ziffern" gefunden werden, gilt das Zeichen am weitesten rechts als "Komma" und alles andere als "Tausendertrennung" wird nun stets "eliminiert"
4. Weiche Regel: wenn in den Zahlenfeldern nach einer "nicht Ziffer" stets 3 weitere Ziffern folgen, gilt dieses SeparatorZeichen als "TausenderTrennung" und wird nun stets "eliminiert"
5. Harte Regel: wenn jetzt noch mehr wie eine "nicht Ziffer" als Separator übrig ist, UND da 'Komma" + "Punkt" noch vorhanden sind, bricht die Autoformaterkennung ab, dann geht muss manuell der KommaSeperator festgelegt werden
6. Weiche Regel: nach "Rule5" gilt "Punkt" ODER "Komma" als DezimalSeparator und bleibt erhalten, alle anderen "nicht Ziffern" werden nun stets "eliminiert"

Wir arbeiten so mit dem Aufwand der ersten nur vollen Importdatenanalyse und dann folgendend erst dem eigentlichen Import seit zig Jahren mit einer voll automatisierten Erfolgsquote von 98..99%.
Unser "RuleSet" ist nur anfällig oder nicht eineindeutig, wenn es Werte mit 3stelliger Genauigkeit und "Tausendertrennung" geben kann... zum Glück haben wir im Finanzbereich nur sinnvolle Werte mit 1,2,4,6,8 Kommastellen:)

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1382296)

Einmalig am Anfang der Datei genügt. Danach sollte sich das ja nicht mehr ändern. (Hat Stephan ja in einem der Code-Comments schon erwähnt)

Ein Fehlschluß, der auf der Annahme Beruht, der Datenerfasser wüßte was er tut. Die Praxis zeigt leider das Gegenteil. Ich würde auf jeden Fall jede Zeile/Datensatz überprüfen.

Gruß
K-H

[Rollo62]

Vielleicht wäre das auch eine Option per RegEx ?

Das könnte man z.B. erweitern so das am Ende nur '.' Decimals für alle Sprachen rauskommt,
und es dann nur mit einem Default-FormatSetting in eine Zahl konvertiert.
Ist vielleicht ein bischen mit Kanonen auf Spatzen, aber diese Konvertierungsfragen sollte man womöglich ein für alle Mal lösen.

Auch wäre es nicht schlecht wenn man nach einer Konvertierung auch wüsste was es nun war,
damit man das Ergebnis evtl. wieder zurückwandln kann.

Das würde vielleicht auf eine separate "Converter" Klasse hinauslaufen, so das man die internen Funktionen nicht mehr benutzen muss/darf.

Rollo

[p80286]

Noch ein Gedanke am Rande:
Ist eigentlich sicher, daß es sich bei den Zeichenketten um Numerische Werte handelt?
Es wäre nicht das erste Mal, das Seriennummern, Aktenzeichen und ähnliches zu numerischen Werten konvertiert werden und eine Prüfziffer, die dann zu einem Dezimalbruch wird ist nicht so genial.

Gruß
K-H