Chr liefert Müll

[ddcool]

Hallo zusammen,

ich bin gerade dabei mit StrToHex und HexToStr hier aus dem Forum zu arbeiten. Dabei ist mir aufgefallen, dass diese Funktionen manchmal Müll zurückliefern.
Ich habe das Gefühl, sobald ich einen Hexwert mit Null am Anfang (also 00 - 09) übergebe, bekomme ich anstatt dem Zeichen ein #00 - #09 zurück.
Woran kann das liegen. Wäre über jede Hilfe dankbar.

Grüße

ddcool

[Christian Seehase]

Moin ddcool,

#00 bis #09 sind doch auch Zeichen, nur nicht darstellbar (das betrifft alle zeichen von 0-31dez bzw. $00-$1F)

[marabu]

Moin,

insbesondere sind $#0..$#9 identisch mit #0..#9 - aus dem gleichen Grund, aus dem die ersten beiden Ziffern in allen Zahlsystemen identisch sind und aus dem du eine Zahl im Oktalsystem ohne einen Hinweis nicht von einer Zahl im Dezimalsystem unterscheiden kannst.

Freundliche Grüße

[ddcool]

Hmm das ist ja doof.
Das Problem ist, dass ich einen String per Blowfish + SHA-512 verschlüssle.
Danach wird der String in Hex gewandelt, um ihn per Text vernünftig verschicken zu können.
Auf der anderen Seite wird dann der Hex-String wieder in einen normalen String gewandelt und entschlüsselt.
Da ich aber bei diesen bestimmten Zeichen (die ja nich darstellbar sind) nur ein #0 - #9 als Rückwandlung bekomme, klappt die Entschlüsselung
auch nicht mehr. Was machen?


Grüße

ddcool

[Muetze1]

Das Problem sollte nur bestehen, wenn du irgendwo nach der Rückwandlung Hex -> String diesen String als PChar() typecastest oder nutzt. Nur dann wird die #0 als Endemarkierung interpretiert, bei einem String an sich hätte er keine Bedeutung.

[ddcool]

Also ich habe jetzt hier nochmal die Funktion. So mache ich das momentan. Was muss ich denn da ändern, damit mir das korrekte Ergebnis zurückgeliefert wird?

Delphi-Quellcode:

Function HexToStr(s: String): String;
Var i: Integer;
Begin
  Result:=''; i:=1;
  While i<Length(s) Do Begin
    Result:=Result+Chr(StrToIntDef('$'+Copy(s,i,2),0));
    Inc(i,2);
  End;
End;

Danke & Grüße

ddcool

[Nuclear-Ping]

Du darfst nie Strings verwenden, wenn du mit binären Daten arbeitest, da bei diesen Schluss ist, sobald #0 drin vorkommt. Nimm PChar.

[marabu]

Genau umgekehrt, Mario.

Die Funktion HexToStr() funktioniert, wenn der übergebene Hex-String eine gerade Länge hat. Erst die unbedachte Verwendung von AnsiString in anderen Funktionen mit implizitem oder explizitem Cast nach PChar führen zum unerwarteten Datenverlust.

Freundliche Grüße

[Nuclear-Ping]

Bei der Funktion da oben, wenn er damit einen String "decodieren" will, der eigentlich ein binärer Datenstrom ist (und so klang's mir), wird er mit String als Rückgabewert imho nicht glücklich.

[ddcool]

Ja nur genau das ist eben nicht der Fall,
ich übergebe ein HexString der eine gerade länge hat und zwar: C8DCC34404C32C2C606769BE4F4201
Bekomme aber bei 04 und 01 anstatt eines Zeichens nur ein #4 und #1 in den String geschrieben (so zeigt es mir der Debugger).


Grüße ddcool

[Nuclear-Ping]

1.) Kannst du nicht garantieren, dass kein #0 drin ist. Oder doch?
2.) Ist das ja auch korrekt, da Zeichen von #0-#32 Steuerzeichen sind. -> http://www.danshort.com/ASCIImap/

[Muetze1]

Da du es hier selber umwandelst und Probleme mit den Ergebnissen hast, werfe ich nochmal die beiden von der VCL angebotenen Funktionen rein: HexToBin() und BinToHex().

[marabu]

Zitat:

Zitat von Nuclear-Ping

Bei der Funktion da oben, wenn er damit einen String "decodieren" will, der eigentlich ein binärer Datenstrom ist (und so klang's mir), wird er mit String als Rückgabewert imho nicht glücklich.

Glück ist relativ - es wird unmittelbar kein Fehler auftreten. Wenn es später irgendwann schief läuft, dann aus den von mir schon beschriebenen Gründen.

Ein AnsiString kann alles aufnehmen, da er eine Längeninformation mit sich herumträgt. Das aus Kompatabilitätsgründen zu C-Strings dahinter stehende NUL-Zeichen bleibt davon unberührt. Man muss halt wissen, was man tut.

Gute Nacht

[ddcool]

Hi,

HexToBin habe ich ebenfalls versucht. Funktioniert alles nichts. Ich verzweifel hier noch :wall:
Problem ist, dass eine Verschlüsselung halt alle ASCII-Zeichen (incl. Steuerzeichen) benutzt.

[marabu]

Zitat:

Zitat von ddcool

Ja nur genau das ist eben nicht der Fall,
ich übergebe ein HexString der eine gerade länge hat und zwar: C8DCC34404C32C2C606769BE4F4201
Bekomme aber bei 04 und 01 anstatt eines Zeichens nur ein #4 und #1 in den String geschrieben (so zeigt es mir der Debugger).

Ist doch genau richtig.

Teste mal deinen eigenen Code, indem du dir noch die Umkehrfunktion schreibst:

Delphi-Quellcode:

var
  s: string;
begin
  s := 'C8DCC34404C32C2C606769BE4F4201';
  if StrToHex(HexToStr(s)) = s
    then ShowMessage('eureka')
    else ShowMessage('rats');
end;

[Muetze1]

So, ich habe nun mal zur Veranschaulichung und aus ein wenig Langweile ein kleines Kommandozeilentool geschrieben, welches eine übergebene Datei als Hexdump in eine andere Textdatei wandelt und zurück.

[ddcool]

Okay ich habe jetzt meinen Fehler gefunden. Ich verschlüssele eine Datei per Blowfish und nehme dann die Hexwerte der Datei um diese wiederum in einen String zu wandeln und per DecryptStr zu Entschlüsseln. Blöde sache weil EncryptStream und EncryptStr arbeiten ganz unterschiedlich. EncryptStr nimmt nämlich nur darstellbare Zeichen, währen EncryptStream alles nimmt. :wall:

Danke trotzdem für die Aufklärung und Hilfe

Grüße ddcool