Windows 10: Unicode UTF-8 Einstellung verwenden

[Scurra]

Hallo zusammen,

wir haben schon länger Probleme mit unserer Software bei einigen unserer Kunden und haben letzte Woche herausgefunden, dass es mit der Unicode UTF-8 Unterstützung von Windows zusammenhängt. Wenn die Einstellung "Beta: Unicode UTF-8 für die Unterstützung weltweiter Sprachen verwenden" aktiviert ist, erzeugt unsere Software Fehler. Hier mal ein Beispiel, was zu einem Fehler führt:

Unsere Software benutzt eine Fremdkomponente zum Einlesen von png-Dateien. Darin enthalten ist folgender Code (ich habe den Code etwas angepasst, um ihn auf das Wesentliche zu beschränken):

Delphi-Quellcode:

...
type
  TChunkName = array [0..3] of AnsiChar;
...

procedure LoadFromStream(Stream: TStream); // der Stream enthält den Inhalt der png-Datei
var
  name: TChunkName;
begin
  Stream.Read(name, 4);
  if name <> '‰PNG'
    then raise Exception.Create('Ungültiges PNG');
  ...
end;

Ist die Unicode UTF-8 Einstellung in Windows deaktiviert, funktioniert alles wunderbar.

Wegen dem Problem habe mich in den letzten Tagen etwas ausführlicher mit Zeichensätzen und Zeichencodierung auseinander gesetzt, mir ist aber immer noch nicht ganz klar, was da passiert (vor allem auch in Windows) und wie man das Problem denn nun eigentlich lösen kann.

Ich habe mir mal ein Tool geschrieben, das den erwarteten String (also ‰PNG) und den tatsächlich eingelesenen String in einer Datei speichert, wenn man die ersten 4 Zeichen eines gültigen PNGs einließt. Wenn die Windows Einstellung aktiviert ist, dann werden in der Datei folgende Zeichen gespeichert (kodiert mit UTF-16 (LE)):

Code:

Erwartet (‰PNG): 30 20 50 00 4E 00 47 00
Tatsächlich:      FD FF 50 00 4E 00 47 00

Nun zu meinen Fragen:

1. Warum wird für das erste Zeichen FD FF eingelesen/in die Datei geschrieben?
2. Wie lässt sich das Problem lösen, so dass der Code keinen Fehler mehr liefert, egal, ob die Windows Unicode UTF-8 Einstellung aktiviert oder deaktiviert ist?

Ich habe da an eine Winapi Funktion gedacht, mit der man die Unicode UTF-8 Einstellung für die eigene Anwendung deaktivieren kann, habe bisher aber nichts in dieser Richtung gefunden. Meine aktuelle Befürchtung ist, dass alle Code-Stellen, die explizit AnsiString benutzen, irgendwie umgeschrieben werden müssen, da ich jedoch davon ausgehe, dass es einige Stellen gibt, hoffe ich, dass es eine praktischere Lösung gibt.

[jfheins]

Also, was da passiert:
Dein String '‰PNG' wird als Unicode interpretiert und dort ist das Promillezeichen U+2030.
Bevor die Software mit Unicode kompiliert wurde, wurde der String vermutlich mit Windows-1252 kodierung gespeichert, sodass dort 0x89 stand.

Zitat:

Warum wird für das erste Zeichen FD FF eingelesen/in die Datei geschrieben?

Weil das ungültige UTF-8 Zeichen beim einlesen durch einen REPLACEMENT CHARACTER ersetzt wird.

Lösung für das Ganze: Wirf die Strings an der Stelle raus, die haben da nix zu suchen. Die Magic number am Anfang der Datei ist (hexadezimal)

Code:

89, 50, 4e, 47, 0d, 0a, 1a, 0a

Einfach diese Bytes in ein Byte-Array schreiben und vergleichen. Zur Not kannst du das auch als 2 32bit Zahlen (Cardinal?) oder eine 64bit Zahl zusammenfassen.

[TigerLilly]

Über das stolpert auch der MSSQL Server 2017 - man kann ihn installieren, aber er starte nicht, weil er über den Zeichnsatz stolpert. Erst wenn man diese Option abdreht, startet er wieder. Ich würde daher meinen, dass du das problem löst, indem du diese Option abdrehst +ü wartest, bis MS das gefixt hat.

[TurboMagic]

Naja, bei eigener SW kann man nicht unbedingt auf einen Fix von Microsoft warten, die können das in dem Fall eher nichts tun. Wenn das bei Interpretation als UTF8 als falsches Zeichen gewertet wird müsste ja MS wissen dass das ein umzucodierendes Zeichen ist.

[Redeemer]

Problem könnte sein, dass es zwar RawByteString gibt, aber kein RawByteChar. Man kann es auch nicht analog mit Codepage $FFFF deklarieren. Jetzt könnte man sich fragen, was

Delphi-Quellcode:

rbs: RawByteString[4]

wäre und was konvertiert wird, wenn man

Delphi-Quellcode:

Stream.Read(rbs[1], 4);

aufruft.
Außerdem kann man sich fragen, was passiert wenn man

Delphi-Quellcode:

const Header: RawByteString = '‰PNG';

deklariert.
Und die beiden Geschichten kann man jetzt noch mit den beiden Zuständen der HIGHCHARUNICODE-Direktive probieren.

Mich wundert übrigens, dass

Delphi-Quellcode:

Stream.Read(name, 4);

geht und das nicht

Delphi-Quellcode:

Stream.Read(name[0], 4);

heißen muss. Aber gut, das wäre einem anders um die Ohren geflogen.

[Frickler]

Das Problem hatten wir neulich auch. Stellte sich heraus: bei neuen DELL-PCs ist die Einstellung "Beta: Unicode UTF-8 für die Unterstützung weltweiter Sprachen verwenden" defaultmäßig eingeschaltet.

[Uwe Raabe]

Zitat:

Zitat von Redeemer (Beitrag 1461559)

Mich wundert übrigens, dass

Delphi-Quellcode:

Stream.Read(name, 4);

geht und das nicht

Delphi-Quellcode:

Stream.Read(name[0], 4);

heißen muss.

Das geht deswegen, weil

Delphi-Quellcode:

name

ein statisches Array ist und damit

Delphi-Quellcode:

name

und

Delphi-Quellcode:

name[0]

auf denselben Speicherbereich zeigen.

Delphi-Quellcode:

type
  TChunkName = array [0..3] of AnsiChar;

[Scurra]

Danke erst einmal für die zahlreichen Reaktionen :)

Zitat:

Ich würde daher meinen, dass du das problem löst, indem du diese Option abdrehst +ü wartest, bis MS das gefixt hat.

Die Option ist nicht auf meinem Rechner aktiv sondern auf den potententiell Tausenden unserer Software-Nutzer. Warten ist für uns leider auch keine Option.

Zitat:

Einfach diese Bytes in ein Byte-Array schreiben und vergleichen.

So habe ich es jetzt gelöst. Bleibt nur zu hoffen, dass es sonst keine Stellen im Code von uns oder von unseren eingebundenen Komponenten gibt, die solche Dinge mit Strings machen.

Zitat:

Dein String '‰PNG' wird als Unicode interpretiert und dort ist das Promillezeichen U+2030.
Bevor die Software mit Unicode kompiliert wurde, wurde der String vermutlich mit Windows-1252 kodierung gespeichert, sodass dort 0x89 stand.

Kann mir noch einmal jemand genau erklären, was da Schritt für Schritt passiert, angefangen beim Speichern der .pas Datei bis hin zur falschen Interpretation auf dem Client-Rechner? Für mich ist denke ich jetzt der Zeitpunkt gekommen, an dem ich mich ausführlich mit Zeichenkodierungen beschäftigen muss und auch möchte, denn wenn man mal beginnt, sich mit dem Thema auseinanderzusetzen, ist es ganz interessant, wie aus ein paar Bytes ein lesbarer Text wird und umgekehrt.

Für alle, die auf dem Gebiet ebenso blutige Neulinge sind wie ich: Hier gibt es eine meiner Meinung nach schöne Einführung in die Grundlagen der Zeichensätze und Zeichenkodierungen: hier. Im Prinzip könnte man sagen, dass ich mich aktuell auf diesem Wissensstand befinde, wobei ich inzwischen schon viel mit meinen Kollegen über das Thema diskutiert habe. Falls jemand hier andere gute Links o. ä. hat, gerne her damit :)

Also mein bisheriges Verständnis reicht soweit:
1. Ich speichere den String '‰PNG' in der .pas-Datei. Beim Speichern verwendet die IDE die Kodierung, die in meinem System eingestellt ist, also wahrscheinlich die ANSI-Kodierung mit Codepage Windows-1252 für westeuropäische Sprachen. In der .pas-Datei steht dann das Byte 89 (hex).
2. Bei der Kompilierung auf unserem Build-Server (Windows) wird die 89 (hex) (wieder über die ANSI-Kodierung mit Codepage Windows-1252) als das Unicode-Zeichen U+2030 interpretiert.

Ab hier wäre es für mich Rätselraten, wie es weiter geht.
3. Wie wird der String beim Kompilieren in die .exe-Datei eingebettet?
4. Wie interpretiert der Client das Zeichen in der .exe-Datei (abhängig von der Unicode UTF-8 Einstellung?)?
5. Wie wird der Beginn der .png-Datei beim Kunden-Rechner ausgelesen (evtl. auch abhängig von der Unicode UTF-8 Einstellung?)?