"Sicheres" Umwandeln von Zeichenkette in Zahl

[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ß