Unicode strings

[eric_draven]

Hallo,

in einigen Projekten (Delphi7-2005) benutze ich strings für hardwarenahe Kommunikation. Dies hat für mich einige Vorteile gegenüber z.B. Byte Arrays, da Teilstrings als Konstanten hinterlegt werden können oder mal eben testweise schnell eingegeben, etc.
Leider führt dies durch Unicode in neuer Versionen zu Problemen, da ich bisher keinen reinen ByteString Typ gefunden hab.
Beispiel:
bisher:

...
...Send(HEADER + #$01#$02 + 'abc' + #12 + Data);
...

Hat jemand eine Idee, wie ich das mit einer aktuellen Delphi Version (XEn) ähnlich umsetzen kann ? Mit RawByteString, Codepages, etc. hatte ich bisher keinen Erfolg.

[mkinzler]

Funktioniert AnsiString?

[Der schöne Günther]

RawByteString ist doch nur ein Alias für AnsiString?

Wobei mich das wundert. Ich dachte AnsiString ist in neueren Versionen genau das, was in füheren Versionen String war?

[mjustin]

Zitat:

Zitat von eric_draven (Beitrag 1267966)

mit RawByteString ... hatte ich bisher keinen Erfolg.

Dann wurde der RawByteString wahrscheinlich irgendwo klammheimlich wieder in einen Unicodestring konvertiert, zum Beispiel bei einer Stringverkettung oder einem Methodenaufruf. Der Compiler zeigt dann aber normalerweise eine Warnung an.

[p80286]

U.U mußt Du auch auf die "ganz alten" Strings (ShortStrings)

Delphi-Quellcode:

MeinString : string[255];

zurückgreifen. Aber mit ANSI..... liegst Du erst mal nicht falsch.

Gruß
K-H

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1267969)

RawByteString ist doch nur ein Alias für AnsiString?

Wobei mich das wundert. Ich dachte AnsiString ist in neueren Versionen genau das, was in füheren Versionen String war?

String war früher ein Alias für den AnsiString
und jetzt ist es ein Alias für den UnicodeString.
Genauso, wie früher (vor Win64) der Integer ein Alias für den LongInt (Win32) und davor für den SmallInt (Win16) war, also das, was jetzt der NativeInt ist, da man bescheuerter Weise den Integer eingefrohren hat. (aus Angst vor Problemen bei der Umstellung auf 64 Bit, aufgrund von schrottig programmierten Codes)

Ein AnsiString ist mit der akuellen Codepage des Systems/Programms (CP_ACP),
RawByteString ist ein AnsiString ohne CodePage,
UTF8String ist ein AnsiString mit der CodePage CP_UTF8
und AnsiString(123) hat die CodePage 123.
Der ShortString ist immer CP_ACP. (das ist ein Rerord und kein Long-String, so wie UnicodeString, AnsiString und Co.)

Und ja, Delphi konvertiert die Strings untereinander.
Wenn man einen UnicodeString an einen UTF8String übergibt, dann wird der Inhalt nach UTF-8 konvertiert, also anhand der CodePage des AnsiString.
Umgekehrt genauso.

Darum gibt es auch den RawByteString, da dieser die "ANSI"-Zeichen, im unteren Byte-Bereich (0 bis 255) des Unicode 1:1 kopiert, ohne zu übersetzen.

[Patito]

Zitat:

Zitat von eric_draven (Beitrag 1267966)

Hallo,

in einigen Projekten (Delphi7-2005) benutze ich strings für hardwarenahe Kommunikation. Dies hat für mich einige Vorteile gegenüber z.B. Byte Arrays, da Teilstrings als Konstanten hinterlegt werden können oder mal eben testweise schnell eingegeben, etc.
Leider führt dies durch Unicode in neuer Versionen zu Problemen, da ich bisher keinen reinen ByteString Typ gefunden hab.
Beispiel:
bisher:

...
...Send(HEADER + #$01#$02 + 'abc' + #12 + Data);
...

Hat jemand eine Idee, wie ich das mit einer aktuellen Delphi Version (XEn) ähnlich umsetzen kann ? Mit RawByteString, Codepages, etc. hatte ich bisher keinen Erfolg.

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.

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.

Mein Tip: Mach einen Bogen um die XEs.

Mit etwas Geduld und Gewalt kriegt man soetwas bestimmt irgendwie hin. 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.

[himitsu]

#$01 entspricht dem #1 und alles im ASCII-Bereich (#0 bis #127) ist in allen Kodierungen gleich, womit das niemals eine Veränderung erfahren sollte.
Die #0 muß zwar beachtet werden, aber der String selber kann solche Zeichen problemlos behandeln, solange man nicht fahrlässig mit PChar-Funktionen, ohne Längenangabe, rumhantiert.

Wie ist denn das Send deklaiert? (mit String-Parameter?)


Wo man etwas aufpassen muß, ist z.B. bei #$0085 und #$85 oder #133, denn bei Erstem geht Delphi davon aus, daß es Unicode ist und beim Letzen kann es als ANSI behandelt werden und erfährt dann eventuell eine Konvertierung nach Unicode.
Rein logisch ist es zwar das Selbe, aber der Compiler achtet halt auf sowas.



Aus soeinem Grund hab ich grade eine Serial-Port-Komponente komplett neu aufgesetzt, bzw. bin noch dabei.
Die ist von der Schnittstelle der vom C# ähnlich, mit Anpassungen an Delphi und diese String-Probleme, einer internen explizit steuerbaren String-Konvertierung und mit Erweiterungen anhand der zusätzlichen Möglichkeiten der WinAPI. (und später hoffentlich auch noch für iOS und vorallem für Android)
Wobei ich absichtlich auch TBytes unterstütze, um das String-Konvertierungs-Problem ganz auszuschließen.
Wobei iOS/Android noch Spaß machen wird, denn dort gibt es keinen AnsiString mehr ... nur noch Unicode.

[eric_draven]

hmmm, AnsiStrings, Codepages, Shortstrings hatte ich schon alles probiert. Das mit dem RawByteString hört sich gut an, funktioniert aber immer noch nicht :cry: . Alles was grösser Ord(127) ist, wird in irgendeinen sinnlosen Wert gewandelt, z.B. $ff => $3f.
Im diesem konkreten Beispiel rufe ich die UDPClient.Send Funktion von Indy auf, wenn man diese verfolgt, sieht die so aus:

Code:

procedure TIdUDPClient.Send(const AData: string; AByteEncoding: IIdTextEncoding = nil
  {$IFDEF STRING_IS_ANSI}; ASrcEncoding: IIdTextEncoding = nil{$ENDIF}
  );
begin
  Send(Host, Port, AData, AByteEncoding{$IFDEF STRING_IS_ANSI}, ASrcEncoding{$ENDIF});
end;

Pseudo-Aufruf:
UDPClient.Send(RawByteString(....));
Also Encoding = nil

[eric_draven]

ah, Himitsu, Du hast mittlerweile nochmal geschrieben. Genau so ist es, 0..127 alles OK, darüber = blödsinn.
Die Bytes sind immer als zweier hex komplementäre geschrieben, z.B. #$00, #$FF, ...