Datenaustausch TIdUDPClient/TIdUDPServer

[Hobbycoder]

Hi,

ich tausche Daten zwischen 2 Anwendungen per UDP aus.
Gesendet wird per IdUDPClient:

Delphi-Quellcode:

procedure TSendDataThread.SendMessage(msg: TMsg);
var
  b: TIdBytes;
begin
  SetLength(b, length(msg.Msg));
  b:=TIdBytes(msg.Msg);
  FUDPClnt.SendBuffer(msg.IP, FPort, b);
end;

im Server soll das mit RecStr:=BytesToString(AData); wieder umgesetzt werden.

Was bisher mittel FUDPClnt.Broadcast(...) super funktionierte, klappt mit SendBuffer nicht.

Wenn ich "test" sende, dann kommt beim Server "T#0e#0s#0t#0" an.

Ich möchte aber im Server für Broadcast-Messages und direkte Messages die gleiche Routine verwenden.
Wie kann ich SendBuffer verwenden, damit das gleiche ankommt wie bei Broadcast?

[Redeemer]

Du sendest einen WideString (UTF-16LE, wie man sieht), sagst aber dem Empfänger, er erwarte einen AnsiString. Das klappt natürlich nicht, denn da solltest du dich auf ein und dasselbe einigen.

WideString ist besser, da auf jedem Windows seit 2000 immer als UTF-16LE definiert (davor war es UCS-2LE), AnsiString ist abhängig von der Region und fliegt dir auf Rechnern mit MBCS komplett um die Ohren.

Delphi-Quellcode:

function BytesToWideString(const AData: TBytes): WideString;
var
  i: Integer;
begin
  Result := '';
  for i := 0 to Length(AData) div 2 - 1 do
  Result := Result + WideChar(Word(AData[i shl 1 + 1]) shl 8 + AData[i shl 1]);
end;

Sollte eine Umstellung des Empfängers nicht möglich sein, stelle den Sender auf AnsiString um. Das geht so:
b:=TIdBytes(AnsiString(msg.Msg)); Implizite Typumwandlungen von Strings sind in Delphi nicht implizit!
Wie gesagt, auf Rechnern mit MBCS fliegt dir das Programm um die Ohren, aber egal.

[Hobbycoder]

Zitat von Redeemer:

Wie gesagt, auf Rechnern mit MBCS fliegt dir das Programm um die Ohren, aber egal.

Das die Anwendung nur auf einer überschaubaren, begrenzten Anzahl an Rechner laufen wird (die auch noch alle bei mir stehen ) kann ich mit dem Risiko leben.

Aber danke für die Antwort und danke für den Hinweis.

Dem zur Folge wäre es ja eigentlich ratsam generell nur noch mit Widestring zu arbeiten? Da könnte man ja unter Delphi im Grund auf alle anderen Stringtypen verzichten, bzw. sie alle intern als Widestring behandeln. Warum macht Emba das nicht? Um Speicher einzusparen?

[Redeemer]

Emba macht das. Seit Delphi 2009 ist alles WideString, solange man nicht ausdrücklich etwas anderes erzwingt. Auch string ist ab hier WideString, davor war es AnsiString.

Indys BytesToString macht das offenbar nicht. Obwohl es einen WideString zurückgibt, unterstützt es WideStrings offenbar nicht. Hat sich vermutlich aus Abwärtskompatibilitätsgründen so erhalten. Unicode-Unterstützung in Indy ist grausam.

[Hobbycoder]

Danke für eure Unterstützung. Jetzt ist mir das klar.

[Bernhard Geyer]

Zitat von Redeemer:

Seit Delphi 2009 ist alles WideString

[Klugscheißermodus=On]
Nicht ganz. Ab D2009 ist es ein Unicodestring und nicht mehr der (von Windows speichertechnisch verwaltete) Widestring.
Ruft man Windows-API-Methoden auf, so stört das nicht, das die Speicherverwaltung an den Widestring angelehnt ist und der Unicodestring immer noch (wie auch früher der Ansistring) ein Abschließendes #0-Zeichen hat um WinAPI-Komaptible zu sein.
Vorteil: Speicherverwaltung mit Unicodestring ist viel schneller als mit Widestring
[Klugscheißermodus=off]

[p80286]

Hallo Klugscheißer, was sind denn die genauen Unterschiede?

Gruß
K-H