String in einem Stream schreiben

[reef]

Hallo zusammen,

bin neu hier und habe ein paar Fragen zu "String in einem TFileStream schreiben". Die Datei wird zwar geschrieben, nur steht in dieser Datei nicht das, was ich möchte, sondern merkwürdige Zeichen. Ich nutze Delphi XE 2. Hängt das mit dem Unicode zusammen? Was mache ich da falsch?

Delphi-Quellcode:

procedure TForm4.Button1Click(Sender: TObject);
begin
  //comport1.CustomBaudRate := 57600;
  comport1.Open;
  Fstream := TFilestream.Create(ExtractFileDir(ParamStr(0)) + '\test.dat', fmcreate);
  timer1.Enabled := True;
end;

procedure TForm4.Button2Click(Sender: TObject);
begin
  timer1.Enabled := False;
  comport1.close;
  if assigned(FStream) then
  begin
    FStream.Free;
  end;
end;

procedure TForm4.ComPort1RxChar(Sender: TObject; Count: Integer);
var
  Str: String;
begin
  ComPort1.Readstr(Str, Count);
  Fstream.WriteBuffer(Str, Count);
end;

procedure TForm4.Timer1Timer(Sender: TObject);
var
  Str: String;
begin
  Str := '1234';
  ComPort1.WriteStr(Str);
end;

Schönen Dank für Eure Hilfe.

Gruß
Ralf

[mkinzler]

Vermutlich. Deklariere ml str als AnsiString.

[CCRDude]

Wäre nicht RawByteString passender als AnsiString?

[Bummi]

@CCRDude im Zusammenhang mit einem Comport dürfte AnsiString wahrscheinlicher sein...

[CCRDude]

Soweit ich verstanden habe, verwendet RawByteString keinerlei codeseitenspezifische Konvertierung bei Zuweisungen, AnsiString schon.

Gerade bei einer seriellen Schnittstelle würde ich nicht zwingend reine Textdaten erwarten, sondern auch Steuerzeichen.

Ich hatb neulich mal länger an einem Problem gesessen, wo eine teure Fremdkomponente Binärdaten in einen AnsiString gelesen und mit einer AnsiString-Konstante verglichen hat. Lief super - nur nicht auf z.B russischen oder japanischen Systemen, da ist der String-Vergleich bei gleichen Bytes (in Roh-Ansicht zeigte der Debugger das) in die Hose gegangen, weil sie im AnsiString als andere Zeichen interpretiert wurden als in der Konstante.

[mjustin]

Zitat von CCRDude:

Soweit ich verstanden habe, verwendet RawByteString keinerlei codeseitenspezifische Konvertierung bei Zuweisungen, AnsiString schon.

RawByteString oder TBytes bevorzuge ich bei Binärdaten und strings, deren Encoding noch nicht bekannt ist, auch. Über RawByteString schrieb Allen Bauer, es sei ursprünglich nur als Codepageloser Datentyp für Prozedur- und Funktionsparameter gedacht gewesen ("RawByteString was intended to be used only as a function parameter"). - http://stackoverflow.com/questions/6...-vs-ansistring
Was zu der Frage führt ob die Verwendung von RawByteString für anderes als "bad practice" angesehen wird.

[Bummi]

@CCRDude Du hast Recht, sorry ich war falsch abgebogen ....

[p80286]

Solange da nichts interpretiert (angezeigt) wird ist das doch Pott wie Deckel oder nicht?

Gruß
K-H

[mjustin]

Zitat von p80286:

Solange da nichts interpretiert (angezeigt) wird ist das doch Pott wie Deckel oder nicht?

Interpretiert wird nicht nur bei der Anzeige, sondern schon bei der Zuweisung z.B. an string / AnsiString Variablen. Dann erscheinen "Fragezeichen" für nicht interpretierbare Zeichen/Zeichenfolgen.

[SirThornberry]

Der Grund dürfte sein das du nicht den Inhalt des Strings schreibst sondern den String selbst:
Fstream.WriteBuffer(Str, Count); Wenn du ein SizeOf(Str) aufrufst wirst du sehen das der String immer 4 Bytes groß ist. Wenn du den Inhalt des Strings schreiben willst musst du Str[1] übergeben (die Referenz auf das erste Zeichen)