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.