Konstanten-Migration auf Delphi 2009 (#1#2#3...)

[kaju74]

Hallo!

Bei der aktuellen Migration eines Delphi7-Projektes auf Delphi2009 bin ich auf folgendes Problem gestoßen: Ich habe eine Konstante, die wie folgt belegt ist (Delphi7):

CS_PWD_PREFIX = #67#12#8#9#133#201#253#15#8; Die wird unter Delphi2009 natürlich nun falsch gelesen. Aus den D2009-Migrationsanleitungen konnte ich ableiten, dass ich stattdessen folgendes schreiben kann, um das Problem zu beheben:

Delphi-Quellcode:

  CS_PWD_PREFIX =
    Chr(67) + Chr(12) + Chr(8) + Chr(9) + Chr(133) + Chr(201) +
    Chr(253) + Chr(15) + Chr(8);

Macht das Ganze jetzt nicht gerade übersichtlicher, daher meine Frage: Geht's auch eleganter?

Danke & Gruß,
kaju

[shmia]

Vielleicht als typisierte Konstante:CS_PWD_PREFIX : Ansistring = #67#12#8#9#133#201#253#15#8;

[kaju74]

...tja, das hatte ich zunächst auch gehofft, funktioniert aber nicht. Die Konstante wird als "Salz" zum Crypten eines Passworts genutzt, dass dann in eine "Altbackende"-DBF Tabelle geschrieben wird, die nur ANSI kann. Aus dieser wird der Hash dann auch gelesen und über eine Compare-Funktion (und wiederum der Konstante) geprüft. Hier hatte ich dann rausgefunden, dass der aus der Datenbank gelesene Wert (noch unter Delphi7) nicht mehr mit dem zu vergleichenden Wert (Delphi2009) übereinstimmt:

Delphi-Quellcode:

const
  //CS_PWD_PREFIX: AnsiString = #67#12#8#9#133#201#253#15#8;
  CS_PWD_PREFIX = Chr(67) + Chr(12) + Chr(8) + Chr(9) + Chr(133) + Chr(201) + Chr(253) + Chr(15) + Chr(8);
begin
  Result := xpBuildChecksum(Format('%d%s', [UserID, CS_PWD_PREFIX + Password]));
end;

Die auskommentierte Zeile funktioniert nicht, die darunterliegende geht!

Gruß,
kaju

[Assertor]

Hi kaju74,

Zitat von kaju74:

Hier hatte ich dann rausgefunden, dass der aus der Datenbank gelesene Wert (noch unter Delphi7) nicht mehr mit dem zu vergleichenden Wert (Delphi2009) übereinstimmt:

Delphi-Quellcode:

const
  //CS_PWD_PREFIX: AnsiString = #67#12#8#9#133#201#253#15#8;
  CS_PWD_PREFIX = Chr(67) + Chr(12) + Chr(8) + Chr(9) + Chr(133) + Chr(201) + Chr(253) + Chr(15) + Chr(8);
begin
  Result := xpBuildChecksum(Format('%d%s', [UserID, CS_PWD_PREFIX + Password]));
end;

Die auskommentierte Zeile funktioniert nicht, die darunterliegende geht!

D2009 interpretiert die Chr() Aufrufe wie WideChar() daher funktioniert das wieder mit dem Format, welches ja am UnicodeString arbeitet (jedenfalls für Chars im SmallInt Bereich). Bei dem auskommentierten AnsiString werden die WideChars aber explizit wieder zu einem AnsiString zusammengesetzt, dabei gehen Informationen verloren bzw. wird eine Anpassung mit Hilfe der CodePage vorgenommen. Das Ergebnis unterscheidet sich somit von dem Chr() Prefix-Versuch.

Also folgende Lösung geht:

Delphi-Quellcode:

{$HIGHCHARUNICODE ON}
procedure foo();
const
  CS_PWD_PREFIX: AnsiString = #67#12#8#9#133#201#253#15#8;
  // CS_PWD_PREFIX = Chr(67) + Chr(12) + Chr(8) + Chr(9) + Chr(133) + Chr(201) + Chr(253) + Chr(15) + Chr(8);
begin
  Result := xpBuildChecksum(Format('%d%s', [UserID, CS_PWD_PREFIX + Password]));
end;
{$HIGHCHARUNICODE OFF}

Gruß Assertor

Edit: Bessere Erklärung nachgeliefert...

[kaju74]

Ahhhh...vielen Dank. Die Direktive kannte ich noch nicht. Hier mal eine Erklärung von Dr.Bob:

Zitat:

Character literals between #128 and #255 – the so-called high ASCII values – have a specific value depending on the ANSI code page. As a result, we should not use the #128..#255 character literals, but use the actual characters themselves which will end up as Unicode characters in the source code.

(*$HIGHCHARUNICODE OFF*)

With the HIGHCHARUNICODE set to OFF, we can define the high-ASCII values without them turning into Unicode characters.

(*$HIGHCHARUNICODE OFF*)
var
C: AnsiChar;
begin
C := #128;

Without turning HIGHCHARUNICODE OFF, we would get a warning that the #128 character, actually WideChar constant #$0080 (based on the current active code page), would have to be narrowed from WideChar to AnsiChar.

Gruß,
kaju

[himitsu]

Zitat:

CS_PWD_PREFIX = #67#12#8#9#133#201#253#15#8;

Lösung:

Delphi-Quellcode:

CS_PWD_PREFIX = #67#12#8#9#$0055#$00C9#$00FD#15#8;
// oder
CS_PWD_PREFIX = #$0043#$000C#$0008#$0009#$0055#$00C9#$00FD#$000F#$0008;

siehe:
http://www.delphipraxis.net/internal...t.php?t=153308


Diese Direktive kannt ich auch noch nicht

[edit]
*grad nachgeguckt hab*
"schön", daß diese Direktive auch in der OH aufgeführt wird *bisslironischgemeint*
[/edit]

Zitat von shmia:

Vielleicht als typisierte Konstante:CS_PWD_PREFIX : Ansistring = #67#12#8#9#133#201#253#15#8;

wenn er das dann nach WideString/UnicodeString umwandelt, dann gibt's spätestens da auch Probleme (ohne diese Direktive)

die Varianten mit Chr bringen nix, da dort am Ende die selbe Zeichenkonvertirung stattfindet, wie bei #xx ... aus chr(xx) und #xx macht der Compiler ja praktisch das Selbe.

[kaju74]

Hi...

Danke auch für diese Lösung

Zitat:

die Varianten mit Chr bringen nix, da dort am Ende die selbe Zeichenkonvertirung stattfindet, wie bei #xx ... aus chr(xx) und #xx macht der Compiler ja praktisch das Selbe.

...da muss es dann aber doch einen Unterschied geben: Die Variante mit Chr funktioniert nämlich und erzeugt dann das gleiche Resultat wie noch unter D7....

Gruß,
kaju

[himitsu]

ach mensch ... früher war's das Selbe ... stimmt ja, jetzt ist Chr=WideChar und erstellt so 'nen WideString

#xx und #$xx erstellt standardmäßig einen AnsiChar (außer bei #$xxxx oder xx>255) und demnach einen WideString

nja, zumindestens muß man schön aufpassen, wie man was macht, sobald man den ASCII-Bereich verläßt

[kaju74]

...wem sagst Du das...der Teufel steckt hier echt im Detail: Streams, #-Kodierungen,...Ich krieg' hier pro zu migrierendem Projekt um die 1000 Compiler-Warnings wegen Ansi->Unicode Typecasts...naja, im Groben funktionieren Sie aber, nur an manchen Stellen happert's halt (wie eben dieser Hash-Geschichte weiter oben).

Danke & Gruß,
kaju

[himitsu]

schlimmer wird es, wenn du Code schreiben willst, welcher unter D2009 und früher laufen soll
da bekommt man schon manchma 'ne Kriese

vorallem wenn man im Code AnsiString, WideString oder gar UnicodeString mit einem "normalen" String kreuzt.



zumindestens UnicodeString hab ich jetzt so gelößt, daß ich TWideString als Typ verwende und diesen anfangs per Kompilerschalter entweder als WideString oder UnicodeString definiere ^^