AnsiString zu String und umgekehrt

[DangerDistel]

Hallo Leute,

ich habe nur kurz eine Frage und zwar die Umwandlung von AnsiStrings zu Strings und umgekehrt.

es kommt bei Delphi ja die Meldung "Implizite String-Umwandlung von 'AnsiString' zu 'string'"

ich habe mir folgende Routine gedacht

Delphi-Quellcode:

  Function ChangeAnsiStringToString(S:AnsiString):String;
  begin
    Result:=EmptyStr;
    if S <> EmptyAnsiStr then
    begin
      Result:= String(S);
    end;
  end;

kann mir dann diese Routine sozusagen in die Suppe spucken oder macht diese dann eher keine Probleme?

[himitsu]

Sorum sollte es keine Probleme geben.

Delphi-Quellcode:

  Function ChangeAnsiStringToString(const S: AnsiString): String; inline;
  begin
    Result := String(S);
  end;

Ob nun implizit (

Delphi-Quellcode:

S := A;

) oder explizit (

Delphi-Quellcode:

S := string(A);

),
am Ende kommt das Selbe bei raus, nur daß beim Expliziten der Compiler nicht meckert, weil man ihm damit sagt, daß es Absicht ist.

Intern wird einfach nur MultiByteToWideChar mit CP_ACP gemacht.


PS: Man könnte solche Compilermeldungen auch "einfach" deaktiveren.

[DeddyH]

Jo, 1Byte passt immer in einen 2-Byte-Typ, aber nicht anders herum.

[himitsu]

Immer nicht unbedingt.

ANSI ist ja MultiByte ... Einheiten zu einem Byte, aber mehrere Bytes kombinierbar, was vorallem die Asiaten ausnutzen, oder z.B. auch das UTF-8

Ins UCS2 würde es also nicht immer passen, da dessen Umfang beschränkter ist, als beim UTF-8, aber beim UTF-16 ('ner Art Erweiterung des UCS2) sieht es wieder anders aus, auch wenn das UTF-16 strukturmäßig mit UFT-8 nix zu tun hat, genauso wie das UTF-7 auch nicht.

[mkinzler]

Zitat:

ANSI ist ja MultiByte ... Einheiten zu einem Byte, aber mehrere Bytes kombinierbar, was vorallem die Asiaten ausnutzen, oder z.B. auch das UTF-8

An sich ist Ansi nicht Multibyte. ANSI ist um ein Bit erweitertes ASCII (7 Bit). Natürlich kann man Ansi auch missbrauchen und etwas anderes reinschreiben. Für UTF8 würde ich aber WideString verwenden und kein AnsiString.

[DangerDistel]

Vielen Danke erstmal für die schnelle Info :-)

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1258358)

An sich ist Ansi nicht Multibyte. ANSI ist um ein Bit erweitertes ASCII (7 Bit). Natürlich kann man Ansi auch missbrauchen und etwas anderes reinschreiben. Für UTF8 würde ich aber WideString verwenden und kein AnsiString.

Widestrings ist aber keine UTF8 sondern UTF16. UnicodeString kann UTF8

[Patito]

Zitat:

Zitat von mkinzler (Beitrag 1258358)

Zitat:

ANSI ist ja MultiByte ... Einheiten zu einem Byte, aber mehrere Bytes kombinierbar, was vorallem die Asiaten ausnutzen, oder z.B. auch das UTF-8

An sich ist Ansi nicht Multibyte. ANSI ist um ein Bit erweitertes ASCII (7 Bit). Natürlich kann man Ansi auch missbrauchen und etwas anderes reinschreiben. Für UTF8 würde ich aber WideString verwenden und kein AnsiString.

Naja. UTF-8 ist Ansi mit Codepage 65001. Und z.B. die Codepage für chinesisches Ansi ist auf jeden Fall Multibyte...
Und UTF8 passt nun wirklich überhaupt nicht in einen WideString. Ein UTF-8 Charakter kann eine ungerade Anzahl Bytes haben, und das passt überhaupt nicht zu einem WideString.

[Sherlock]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1258364)

Zitat:

Zitat von mkinzler (Beitrag 1258358)

An sich ist Ansi nicht Multibyte. ANSI ist um ein Bit erweitertes ASCII (7 Bit). Natürlich kann man Ansi auch missbrauchen und etwas anderes reinschreiben. Für UTF8 würde ich aber WideString verwenden und kein AnsiString.

Widestrings ist aber keine UTF8 sondern UTF16. UnicodeString kann UTF8

Ja, in die WideString Falle bin ich auch getappt. WideString ist ja nicht der derzeitige Delphi-String sondern eben UnicodeString. Da kann bei einer (impliziten) Typumwandlung übrigens etwas verloren gehen. Und Warnungen oder Hinweise dazu kommen keine. Unschön.

Sherlock

[mkinzler]

WideString ist ein nicht von der Delphi RTL verwalteter Typ. Um den Inhalt muss sich das Programm kümmern.

[p80286]

Zitat:

Zitat von Patito (Beitrag 1258369)

Und UTF8 passt nun wirklich überhaupt nicht in einen WideString. Ein UTF-8 Charakter kann eine ungerade Anzahl Bytes haben, und das passt überhaupt nicht zu einem WideString.

Ist ja auch Äpfel mit Birnen verglichen. Wenn Du (oder jemand anderes) ein Zeichen Darstellen will, dann muß er die entsprechende Codierung übergeben. Die Basis hierfür sind 16Bit oder 8Bit Characters. Und je nach Codepage und oder sonstiger Vereinbarung werden diese Zeichen dann decodiert. Ein String ist nichts als ein besseres Array of Byte, dem noch etwas Dateninterpretation (x00,x0D0A...) dazu gepackt wird. Es ist ein gefährlicher Irrglaube, daß mit einem

Delphi-Quellcode:

MeinIrgendwasstring:=MeinetwasandereString;

alles erledigt ist.
Wenn man allerdings weiß was man tut spricht nichts gegen UTF8 in WideStrings.

Gruß
K-H

[Patito]

Zitat:

Zitat von p80286 (Beitrag 1258390)

Zitat:

Zitat von Patito (Beitrag 1258369)

Und UTF8 passt nun wirklich überhaupt nicht in einen WideString. Ein UTF-8 Charakter kann eine ungerade Anzahl Bytes haben, und das passt überhaupt nicht zu einem WideString.

Wenn man allerdings weiß was man tut spricht nichts gegen UTF8 in WideStrings.

Naja. Wenn man weiß was man tut, spricht allerdings der gesunde Menschenverstand gegen UTF8 in WideStrings.
Theoretisch kann man allen möglichen Unsinn machen, aber sinnvoll ist soetwas eben nicht.

[p80286]

Zitat:

Zitat von Patito (Beitrag 1258403)

Naja. Wenn man weiß was man tut, ...
Theoretisch kann man allen möglichen Unsinn machen, aber sinnvoll ist soetwas eben nicht.

Unbenommen, da aber viele Schnittstellen "String" in irgendeiner Ausprägung übergeben bekommen, sollte man schon wissen was man tut. Schönes Beispiel ist die Möglichkeit mit

Delphi-Quellcode:

Tstringlist.Readfromfile

Eine beliebige Datei zu lesen. Und hier geistern eine Anfragen herum, warum denn da kein lesbarer Text herauskommt. Kann ja nicht, ist ja eine Echse:stupid:
"Aber das ist doch String" ist dann die Antwort.
"String" ist eben auch nur eine Datenstruktur, die Interpretation bleibt anderen vorbehalten.

Gruß
K-H