UTF8 als WideString an ActiveX (LPCTSTR)

[himitsu]

Und du bist dir wirklich sicher, daß LPCSTR bei dir als UTF-8 verwendet werden kann, bzw. kann man irgendwo den verwendeten Charset einstellen?

Wenn es unter D6 mit LPCSTR nur ANSI verarbeitet wurde, dann wird es, bei gleicher Schnittstelle auch jetzt immernoch nur als ANSI arbeiten.


Wie sieht den die TLB aus?

[taveuni]

Hallo himitsu,

Ich bin mir insofern sicher als dass in anderen Programmiersprachen dieses so dem ActiveX als Array of Char
übergeben kann und dieses (das ActiveX) dies richtig verarbeitet. Allerdings habe ich natürlich die Sourcen des ActiveX nicht.

Auszug aus der TLB

Delphi-Quellcode:

// *********************************************************************//
// DispIntf:  _DGeheimeFirmaActiveXControl
// Flags:     (4112) Hidden Dispatchable
// GUID:      {EC277D05-8AA2-41F5-91AA-8EE7DBD55C77}
// *********************************************************************//
  _DGeheimeFirmaXControl = dispinterface
    ['{EC277D05-8AA2-41F5-91AA-8EE7DBD55C77}']

    function DlmXBackup(ulCameraFilter: Integer; ulStartTimeStampSec: Integer; 
                        ulStartTimeStampMillis: Integer; ulStopTimeStampSec: Integer; 
                        ulStopTimeStampMillis: Integer; const strFilename: WideString; 
                        const strFormat: WideString): Integer; dispid 21;

    function DlmXConfig(const strConfigXML: WideString): Integer; dispid 25;

Bei der Funktion DlmXBackup gehts hier um den Parameter strFilename.
In der Funktion DlmXConfig kann/muss ich vorgängig dieses XML mitgeben:

Code:

<DlmSDK><DlmConfig><Display CodePage=“utf-8” /></DlmConfig></DlmSDK>
<DlmSDK><DlmConfig><Display CodePage=“ISO-8859-1” /></DlmConfig></DlmSDK>
<DlmSDK><DlmConfig><Display CodePage=“windows-1251” /></DlmConfig></DlmSDK>

Wird damit vielleicht das Charset eingestellt?

[himitsu]

Hmmm.

Also ein Problem ist ersmal, daß seit mindestens Delphi 2009 (hab nie im 2007er nachgesehn) die Delphi-Strings (AnsiString, RawByteString, UTF8String, also alle AnsiString-Nachfahren und natürlich der neue UnicodeString) über eine CodePage-Information verfügen.

Anhand dieser CodePage wird notfalls eine Convertierung vorgenommen.
Delphi erkennt also, daß du einen UTF-8-kodierten String (AnsiString+CP_UTF8) an einen Unicode-String (WideString) übergeben willst und wandelt den enthaltenen Text "korrekt" um ... macht also aus dem UTF-8 wieder Unicode.

Das andere Problem ist, daß wir nicht wissen wie Windows das, bzw. deren Code, intern aus dem WideString/PWideChar einen PAnsiChar/LPCSTR macht.
(das müßtest du mal erdebuggen oder eben ausprobieren)

Versuch es mal so:

Delphi-Quellcode:

function WUConvert(const S: string): WideString;
var
  A: UTF8String;
begin
  A := UTF8Encode(S);
  SetCodePage(A, CP_ACP, False);
  Result := A;
end;

// und falls es doch nicht geht, dann eventuell so?

function WUConvert(const S: string): WideString;
var
  A: UTF8String;
begin
  A := UTF8Encode(S);
  SetCodePage(A, $FFFF, False);
  Result := A;
end;

// oder

function WUConvert(const S: string): WideString;
var
  A: UTF8String;
  i: Integer;
begin
  A := UTF8Encode(S);
  SetLength(Result, Length(A));
  for i := 1 to Length(A) do
    Result[i] := A[i];
end;

PS: Dein <DlmSDK><DlmConfig><Display CodePage="..." /></DlmConfig></DlmSDK> ist eh nur ASCII, drum kann man sich dort alles sparen und kann es problemlos direkt übergeben.

PPS: Sicher daß “ und ” korrekt sind und nicht eigentlich " dort hingehört?
Ein korrektes XML ist das so jedenfalls nicht.

[taveuni]

Hallo himitsu,

SetCodePage erwartet einen RawByteString.
Ich habe bei den ersten zwei Funktionen den UTF8String durch diesen ersetzt.
Die letzte lässt sich nicht kompilieren.

Mit der ersten Variante funktionierts!
Es ist mir noch nicht ganz klar weshalb.
Kannst Du mich aufklären?

UTF8Encode(s) hatte ich ja schon gemacht.
Nun ist "nur" noch das SetCodePage hinzugekommen.

Auf jeden Fall danke ich Dir vielmals. Du hast meine Woche gerettet.
Ich hoffe Du kannst Dein profundes Wissen auch beruflich angemessen einsetzen.

[himitsu]

UTF8Encode setzt als Codepage CP_UTF8, was eigentlich auch richtig so ist.
Mit SetCodePage wurde die Codepage nun auf $FFFF gesetzt, was einem RawByteString entspricht.
Wenn man jetzt diesen AnsiString/RawByteString an einen UnicodeString oder WideString zuweist, dann nutzt Delphi die Codepage für die Convertierung.
Es macht also implizit paraktisch ein UTF8Decode, da in den WideString Unicode reingehört.
Über den RawByteString, welcher nun dein UTF-8 enthält, aber über SetCodePage+CP_ACP gesagt bekommen hatte er enthält "angeblich" ANSI, wird nun bei der Umcodierung nicht von UTF8 nach Unicode, sondern von ANSI nach Unicode umgewandelt, also so als wenn es ANSI-Zeichen währen.

Intern wird anscheinend ebenfalls immer nur von Unicode nach ANSI umgewandelt, egal was du als Setting vorgegeben hast.
Da hätte die Entwicklerin selber für eine korrekte Konvertierung sorgen müssen.

PS: Bis mindestens Delphi 7 hat Delphi alles in einem AnsiString auch als ANSI angesehn, selbst wenn man vorher ein UTF-8 dort reingeschoben hatte.
Dort gab es die CodePage an jedem String noch nicht und somit hätte man damals UTF-8 problemlos nutzen können, ohne soeinen Krampf durchzumachen.

Aber eigentlich ist die Entwicklerin Schuld, denn wenn die den WideString auch als Unicode nutzen und dann intern korrekt umwandeln würde, dann müßte man nicht versuchen in dem Unicode-String ein verstümmeltes UTF-8 mitgeben zu müssen.


Und du mußt aufpassen, denn wir in Deutschland haben kein MultiByte im ANSI, sondern nur eine SingleByte-Codepage ... jedes Byte ist ein Zeichen.
Die Asiaten haben ein paar mehr Zeichen, drum nutzen sie eine richtige MultiByte-CodePage.

Außerdem gibt es für einige Unicode-Zichen mehrere/verschiedene ANSI-Darstellungen.
Es könnte also Probleme bei der Rückumandlung geben, da das UTF-8 implizit ein gemapptes über ANSI umgeleitet wird, mit Hin- (ANSI>Unicode) und Rückübersetzung (Unicode>ANSI), vobei das UTF-8 eventuell zerstört werden könnte.


So, ich hoffe mal, ich hab jetzt keinen Knoten im Hirn.