Unicode strings

[himitsu]

Entweder du benutzt einen Send-Befehl, welcher keinen String verwendet.
=> Buffer (VAR ohne Typ), TBytes, einen TStream oder einzeln Byte für Byte

Oder du speicherst deinen Text in einem AnsiString.
Bei Übergabe wird der dann nach Unicode konvertiert und vom IdTextEncoding, hoffentlich mit der richtigen CodePage (0 = CP_ACP) wieder in zurück Ansi,
wobei dann hoffentlich alle Bytes wieder so sind, wie sie waren/sollen.

Oder du probierst es mit einem RawByteString. Vor Übergabe sicherheitshalber nochmal mit SetCodePage die CodePage auf $ffff setzen.
Und dann beim Senden ein IIdTextEncoding mit der CodePage $ffff verwenden. (ich hoffe die können damit umgehen)

[Whookie]

Ich habe auch eine uralte serielle Library beim Umstieg auf Delphi XE konvertiert und intern dafür AnsiString/AnsiChar/PAnsiChar verwendet, was ohne großen Aufwand über die Bühne ging (konvertieren auf TBytes hätte eine Menge mehr Arbeit bedeutet). Bei mir geht das problemlos weil intern Strings verwendet werden von außen aber Daten (Bytes/Word/DWord/Float) angeliefert werden.

Dein Problem liegt aber wohl darin, dass du diese Trennung nicht machen kannst weil du direkt im Programm mit den Strings arbeitest. Aus meiner Sicht gibts daher nur zwei Möglichkeiten:

1. Hardcast über AnsiString und AnsiChar für alles was mit dem Protokoll zu tun hat:

Code:

Const
  ETX = AnsiChar(2); //stellvertretend für alle Steuercodes....
  CHeader: AnsiString = #230'vorne'#231;

procedure TForm4.Button1Click(Sender: TObject);
Var
  Header: AnsiString;
begin
  Send(CHeader+AnsiString('Meine Daten'#$F3#$EE'hinten')+ETX);
end;


procedure TForm4.Send(AString: AnsiString);
begin
  //hier sollte alles passen
end;

2. Konvertieren vor dem Senden.
Das ist einwenig "riskant", abhängig von den Daten (siehe weiter unten)

Code:

Const
  ETXu = #2;
  CHeaderu = #230'vorne'#231;


procedure TForm4.Button2Click(Sender: TObject);
Var
  Header: String;
begin
  Sendu(CHeader+'Meine Daten'#$F3#$EE'hinten'+ETX)
end;

procedure TForm4.Sendu(AString: String);
Var
  iSend: AnsiString;
  i: Integer; // könnte auch TByte sein...
begin
  // konvertieren in AnsiString
  SetLength(iSend, Length(AString));
  for i := 0 to Length(AString) do
  begin
    iSend[i] := AnsiChar(AString[i]);
  end;
  // jetzt kann iSend übertragen werden...
end;

Probleme bringt diese Version immer dann wenn du Zeichen ausserhalb des Ansi-Bereichs senden möchtest also etwa:

Code:

CHeaderu='öÖäß...'

denn in deinem Code darfst du nur Zeichen bis 127 zwischen den Anführungszeichen verwenden, alles andere muss in der Form #xxx angegeben werden. Auch eine Wandlung von Unicode nach Ansi ist in Sendu() nicht möglich.

[Bernhard Geyer]

Zitat:

Zitat von Patito (Beitrag 1268020)

Als ich früher solche Fragen gestellt habe, lagen die Statements von diversen Delphi-Leuten
irgendwo zwischen "So etwas sollte man nicht machen" und grobem Unverständnis.

So wie oben macht man es ja auch nicht. Hier wäre sinnvoll das was man als OSI-Modell kennt auch entsprechend auf Klassen aufzuteilen und nicht den ganzen Packetaufbau so zusammenzufassen.
Hat man entsprechende Klassen/Helperunits muss man sich um Charactercodierung nur an wenigen Stellen Quellcode Gedanken machen.

Zitat:

Zitat von Patito (Beitrag 1268020)

Ein Problem hier kann z.B. sein, dass Konstanten wie #$01 nich das liefern, was Du erwartest.
So etwas wird schon mal stillschweigend in andere Char-Codierungen umgewandelt.

Eigentlich nicht. $01 ist immer $01. Egal welche Codierung. Jedoch kann es sein wenn man sowas an WinAPI-Funktionen übergibt die Strings erwarten das hier diese Sonderzeichen verstümmelt werden weil die Funktion nur Druckbare Zeichen erwartet. Hatte erst vor kurzen den Fall das ein Unicodezeichen kein richtiges Zeichen war und UTF8-Codiert eine defekte XML-Datei produziert hatte.

Zitat:

Zitat von Patito (Beitrag 1268020)

Mein Tip: Mach einen Bogen um die XEs.

Mein Tipp. Ist nicht nötig. Die XEs sind sehr gut zu verwenden.

Zitat:

Zitat von Patito (Beitrag 1268020)

Mit etwas Geduld und Gewalt kriegt man soetwas bestimmt irgendwie hin.

Da braucht man keine Gewalt. Man muss nur verstehen wie Strings Funktionieren und schon funktioniert es in 99% aller Fälle auf Anhieb.

Zitat:

Zitat von Patito (Beitrag 1268020)

Aber Arbeitszeit aufzuwenden um die ganzen Absonderlichkeiten von einem Tool zu verstehen,
dessen Entwickler es für eine tolle Idee halten den Support für AnsiStrings einzuschränken
(bzw. planen ihn in Zukunft auch mal ganz zu entfernen) ist einfach nicht sinnvoll.

Wenn Du meinst. Man brauche eigentlich in 99% der Fälle keine AnsiStrings. Man muss nur Wissen wie man Daten einlist (Stichworte BOM, Konvertierungsfunktionen, ...) und wie man Sie ausgibt.
Glücklicherweise hat Emba/Delphi den Weg genommen mit Unicodestrings zu arbeiten statt hier eine Krückenlösung ala FreePascal mit UTF8 zu realisieren.
Da wo man sich Delphi XEx keine Gedanken mehr machen muss bezüglich Dateizugriff und Sonderzeichen in Dateinamen, muss man bei Freepascal noch überlegen ob man nun die Funktion mit oder ohne UTF8/native im Namen verwendet.

[p80286]

Zitat:

Zitat von Patito (Beitrag 1268020)

Als ich früher solche Fragen gestellt habe, lagen die Statements von diversen Delphi-Leuten
irgendwo zwischen "So etwas sollte man nicht machen" und grobem Unverständnis.

Das kannst Du gerne haben. Char/String ist im 8-Bit Bereich oft eine Frage der Interpretation, einzig 0..9,A..Z und a..z und das Blank sind überall (soweit ich weiß) gleich. Sonderzeichen und Umlaute sind mehr oder weniger frei verteilt, ganz zu schweigen von den TTY-Steuerzeichen. Wenn man schon mit Char/String arbeiten will/muß dann sollte man schon wissen, was die Umgebungsvariablen (Codepage, Zeichensatz, Font) sind. Im Zweifel sollten immer numerische Werte (Byte) übergeben werden. Nicht umsonst werden z.B. die PCL-Steuersequenzen als Byte-Folgen angegeben.

Gruß
K-H