[DEC] WideString ver/entschlüsseln

[xZise]

Hallo Mütze und Hagen,

ich glaube kaum, dass es tatsächlich am debugger liegt, dass er #0 einfügt.

Zitat von Muetze1:

Zitat von xZise:

Aber wenn ich einen WideString im Debugger beobachte hat es keine #0 im String ?!

Weil der Debugger um den Typ weiß und ihn entsprechend darstellt. Darstellung ist ungleich Ablage. Im Speicher liegt er trotzdem (bei Ansi-Inhalt) mit jedem 2. Byte als #0 vor! Wenn du einen "echten" Widestring wie unten verwendest, dann ist wird das jeweils zweite Byte ordentlich genutzt.

Jap... Aber ich meine, warum sollte er mitten drinne die Anzeige verändern?
Es ist die gleiche Variable vom Typ "WideString", also sollte der Debugger eigentlich selbstständig erkennen, dass es aus Words bzw. WideChars besteht?
Ich meine wenn man sowas macht:

Delphi-Quellcode:

var
  myWideString : WideString;

myWideString := 'Ein WideString';
myWideString := TueDasUndDas(myWideString);

Warum sollte, wenn als Ergebnis von TueDasUndDas wieder ein WideString herauskommt, aufeinmal #0 mitten im String auftauchen?

Zitat von Muetze1:

Zitat von xZise:

[edit=1]Ich habe es geradeeben getestet:
TTntEdit (namens e) auf dem Formular, und dann folgende Methode:

Delphi-Quellcode:

procedure TForm1.FormClick(Sender: TObject);
var
  t : WideString;
begin
  t := e.Text;
  Showmessage(t);
  ShowMessage(t[2]);
end;

1. Showmessage gibt den WideString korrekt an.
2. Showmessage gibt das 2. Zeichen im WideString an (==> es ist kein #0 sondern das "dritte" Zeichen!)

WideString[] gibt dir auch einen WideChar zurück, und das ist ein Word. Wie willst du dort dann die Bytes betrachten?

Der indizierte Zeichenzugriff weiß doch um die Datenorganisation. Und wenn du WideString[] schreibst, dann gibst du das Zeichen an, auf das du zugreifen willst. Bei einem AnsiString[] ist es dann ein AnsiChar und der ist 8 Byte groß. Bei WideString[] ist es ein WideChar und der ist zwei Byte groß.

Delphi-Quellcode:

procedure TForm1.FormClick(Sender: TObject);
var
  t : WideString;
  lPtr: PByte;
begin
  t := e.Text;
  lPtr := @t[0];

  Showmessage(inttostr(lptr^) + ' ' + Chr(lPtr^));
  inc(lptr);
  Showmessage(inttostr(lptr^) + ' ' + Chr(lPtr^));
  inc(lptr);
  Showmessage(inttostr(lptr^) + ' ' + Chr(lPtr^));

  // alternativ:
  ShowMessage(format('high %d low %d', [Hi(t[2]), Lo(t[2])]));   // wenn er WideChar nicht bei Hi() und Lo() akzeptiert, dann caste auf Word...
end;

Nagut, dieser "Beweis" ist nicht ganz aussagekräftig.

Zitat von negaH:

Zitat:

Aber wenn ich einen WideString im Debugger beobachte hat es keine #0 im String ?!

Doch hat er, nur du betrachtest den WideString falsch.[...]

Genau das gleiche wie oben: Warum sollte der Debugger auf einmal die Anzeige umschalten?

Nagut, selbst wenn ihr darauf einen Grund habt:
Ich habe diesmal debuggt mit Speicherauszug, und das Ergebnis seht hier:

Vor der Entschlüsselung und Verschlüsselung:

Code:

$68 $00 $74 $00 $74 $00 $70 $00 $3A $00 $2F $00 $2F $00 $77 $00 $77 $00 $77 $00 $2E $00 $67 $00 $6F $00 $6F $00 $67 $00 $6C $00 $65 $00 $2E $00 $64 $00 $65 $00

Nach der Entschlüsslung und Verschlüsselung:

Code:

$68 $00 [b]$00 $00[/b] $74 $00 [b]$00 $00[/b] $74 $00 [b]$00 $00[/b] $70 $00 $00 $00 $3A $00 $00 $00 $2F $00 $00 $00 $2F $00 $00 $00 $77 $00 $00 $00 $77 $00 $00 $00 $77 $00 $00 $00 $2E $00 $00 $00 $67 $00 $00 $00 $6F $00 $00 $00 $6F $00 $00 $00 $67 $00 $00 $00 $6C $00 $00 $00 $65 $00 $00 $00 $2E $00 $00 $00 $64 $00 $00 $00 $65 $00 $00 $00

(http://www.google.de)

Was sehen wir: 3 Byte (also genau 2 Byte zu viel) Nullen
Ich habe nur die ersten 3 falschen Zeichen markiert.

MfG
xZise

[edit=1]Ich habe mal die Antwort verbessert...[/edit]
[edit=2]Ich habe das Ergebnis des Debuggers vor und nach der "Tortur" ( ) angegeben und mal ein bisschen gehighlightet[/edit]