Inhalt eines dynamischen Array in einen String kopieren

[Uwe Raabe]

Zitat von oki:

FReceiveData setze ich 0 um die empfangenen Daten zu löschen (hole sie mit Sdata ab). SData ist ein string, den ich mit den Daten als String hochreichen möchte. Manchmal empfange ich nur ASCII.

Das beantwortet leider nur einen Teil meiner Fragen - insbesondere nicht, welche Delphi-Version du einsetzt. Sollte das Ganze nämlich unter Delphi 2009/2010 laufen, funktioniert das Move eines ByteArray in einen String nämlich nicht, da die einzelnen Zeichen im String jeweils 2 Byte groß sind! Das würde auch deinen Müll erklären.

[himitsu]

Zitat von Medium:

Nur so am Rande: Move ist intern meine ich auch nichts weiter als eine Schleife über Bytes.

Nein, Move wurde in "neueren" Delphis durch etwas aus'm FastCodeProjekt ersetzt und kopiert jetzt etwas optimaler.

[oki]

Hallo Leute!

Erst mal Dank für die vielen Antworten während meiner Abwesenheit. Ich möchte gleich mal Stück für Stück antworten.

Zitat von p80286:

Ich hab's mal für mich umgesetzt, so klappt es:

Delphi-Quellcode:

var
  i : integer;
  a1: array of byte;
  s1: string;
begin
  setlength(s1,50);
  setlength(a1,50);
  for i:=0 to 49 do a1[i]:=$20+i;
  move(a1[0],s1[1],50);
  showmessage(s1);

Gruß
K-H

Joop, genau das funzt nicht. Da ich etwas weiter gelesen habe denke ich, dass könnte mein Ansi-Problem sein. Sorry, hatte nicht dran gedacht Bescheid zu sagen, dass ich das grad unter D2010 teste.

@himitzu: Den Ansatz mit dem Casten werd ich mal testen. Ja, ich hab das mit dem Müll echt im Debugger geprüft. Aber auch hier wird mir sicher das D2010-Thema auf die Füße gefallen sein.

@Medium: Da Move mit asm-Code gestrickt ist hab ich einfach unterstellt, dass es schneller als eine eigene Schleife ist. Haben sich ja einige zu geäußert. Kann ich selber aber wenig zu sagen.

@Uwe Raabe: Danke für deinen Hinweis. Ich denke, da liegt der Hund begraben. Ich habe erst seit 1 Monat D2010 auf dem Rechner und hier jetzt gar nicht mehr an das UniCode-Thema gedacht. Ich glaube jetzt echt das ist der Fehler. Werde mal testweise SData als AnsiString definieren und den Move noch mal testen.

Ich mach jetzt mal meine Tests und sag dann Bescheid.

Dank und Gruß oki

[oki]

Joop, da war das Problem: Delphi2010 mit UniCode nicht beachtet. Hier der Code der klappt:

Delphi-Quellcode:

procedure TListenerThread.DoReceivedData;
var SData : AnsiString;
begin
  SData := '';
  if Assigned(FOnReceivedData) then begin
    if (FReceivedData <> nil) and (Length(FReceivedData) >= 200) then begin
      SetLength(SData, Length(FReceivedData));
      system.Move(FReceivedData[0], SData[1], Length(FReceivedData));
      SetLength(FReceivedData, 0);

      FOnReceivedData(self, SData);
    end;
  end;
end;

Hätte ich auch dran denken können.

Dank und Gruß an alle, die mir geholfen haben.

oki

[himitsu]

tja, das Böse Unicode

Zitat:

Den Ansatz mit dem Casten werd ich mal testen

Ein AnsiString ist auch "nur" ein erweitertes Array of Byte, mit einem zusätzlichen Feld (die #0) hinten drann.

Drum auch das UniqueString, wobei man hier auch ein Copy hätte nutzen können.
Anderrum String auf Byte-Array geht auch so (ohne UniqueString), da hier ein "zuviel" nicht stört.

[oki]

Hi himitzu, hatte das Casten getestet, aber die #0 in der Eile vergessen und damit erst mal verworfen. nach dem Casten hatte der String eine Länge 0 Ich denke mal das lag an der #0. Move funzt, ich denke, dass reicht mir. Hänge schon wieder in der nächsten Thematik

Dank und Gruß oki

[himitsu]

Nimm ab Delphi 2009 statt dem AnsiString lieber den RawByteString für soetwas, denn dort wurde unter Anderem eine automatische CodePageUmwandlung eingeführt, welche für diesen String-Typen deaktiviert ist.

[oki]

Zitat von himitsu:

Nimm ab Delphi 2009 statt dem AnsiString lieber den RawByteString für soetwas, denn dort wurde unter Anderem eine automatische CodePageUmwandlung eingeführt, welche für diesen String-Typen deaktiviert ist.

Und wieder was gelernt

Gruß oki

[himitsu]

Arg, beim Test hab ich jetzt noch festgestellt, daß die Typeninfos von einem String auf einen Anderen übertragen werden können
(das macht überhaupt keinen Spaß )

z.B. würde man hinter R (also dem UTF8-String genannt "R(UTF)") auch UTF8-kodierte Zeichen vermuten/erwarten

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
type
  PStrRec = ^StrRec;
  StrRec = packed record
    codePage: Word;
    elemSize: Word;
    refCnt: Longint;
    length: Longint;
  end;

type
  TMyString = type AnsiString(28597);  // ISO-8859-7 aka CodePage:28597
var
  R: RawByteString;
  A: AnsiString;
  M: TMyString;
  S1, S2, S3, S4, S5: String;

begin
  R := UTF8Encode('ÈÒú');
  A := 'ÈÒú';
  //M := 'ÈÒú';
  //M := #200#210#250;
  SetLength(M, 3);  M[1] := #200;  M[2] := #210;  M[3] := #250;

  S1 := R;
  S2 := A;
  S3 := M;
  UniqueString(AnsiString(R));
  PStrRec(Integer(R) - SizeOf(StrRec)).codePage := CP_NONE;
  UniqueString(AnsiString(M));
  PStrRec(Integer(M) - SizeOf(StrRec)).codePage := CP_NONE;
  S4 := R;
  S5 := M;

  ShowMessage(Format('R(UTF) = %s'#10'A          = %s'#10'M(ISO) = %s'#10
    + 'R          = %s'#10'M          = %s', [S1, S2, S3, S4, S5]));
end;

Vielleicht erkennt man auch, was man für einen Aufwand hat, wenn man sich selber um die Kodierung oder Nicht-Kodierung kümmern möchte.

Gut, dafür kann man diese Automatik auch ausnutzen

früher (vor D2009) sah es so aus

Delphi-Quellcode:

Var S: WideString;
  D: {Ansi}String;

D := UTF8Encode(S);

jetzt (ab D2009) sieht es so aus

Delphi-Quellcode:

Var S: (Unicode)String;
  D: UTF8String;

D := S;

eigentlich würden hier ja die "asiatischen" Schriftzeichen nicht überleben:

Delphi-Quellcode:

var U: String;    // ist ein Unicode-String
  A: UTF8String;  // ist intern nur ein AnsiString

U := #23456#34567#45678;
A := U;
ShowMessage(A);