Programm verhält sich anders unter Windows 10 (DE) und Windows 10 (KOR)

[Shark99]

Ich komprimiere Daten mit der ZLib unter Delphi 2009. Das Problem ist dass sich das Program auf asiatischen PCs komplett anders verhält, es kommen also andere Daten heraus. Hab das Projekt angehängt.

Der Code:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ZLib, JclStringConversions;

type
  TForm2 = class(TForm)
    Edit1: TEdit;
    Edit2: TEdit;
    Edit3: TEdit;
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form2: TForm2;

  function Compress(aText: string; aCompressionLevel: TZCompressionLevel=zcMax): UTF8String;
  function Decompress(aText: UTF8String): string;

implementation

{$R *.dfm}

function Compress(aText: string; aCompressionLevel: TZCompressionLevel=zcMax): UTF8String;
var
  strInput,
  strOutput: TStringStream;
  Zipper: TZCompressionStream;
  s: UTF8String;
begin
  Result:= '';
  if aText = '' then Exit;

  s := WideStringToUTF8(aText);

  strInput:= TStringStream.Create(s);
  strOutput:= TStringStream.Create;
  try
    Zipper := TZCompressionStream.Create(strOutput, aCompressionLevel);
    try
      Zipper.CopyFrom(strInput, strInput.Size);
    finally
      Zipper.Free;
    end;
    Result := strOutput.DataString;
  finally
    strInput.Free;
    strOutput.Free;
  end;
end;

function Decompress(aText: UTF8String): string;
var
  strInput,
  strOutput: TStringStream;
  Unzipper: TZDecompressionStream;
  s: AnsiString;
begin
  Result:= '';
  if aText = '' then Exit;

  strInput:= TStringStream.Create(aText);
  strOutput:= TStringStream.Create;
  try
    Unzipper:= TZDecompressionStream.Create(strInput);
    try
      strOutput.CopyFrom(Unzipper, Unzipper.Size);
    finally
      Unzipper.Free;
    end;
    Result := UTF8ToWideString(strOutput.DataString);
  finally
    strInput.Free;
    strOutput.Free;
  end;
end;

procedure TForm2.Button1Click(Sender: TObject);
begin
  Edit2.Text := Compress(Edit1.Text);
end;

procedure TForm2.Button2Click(Sender: TObject);
begin
  Edit3.Text := Decompress(Edit2.Text);
end;

end.

Im Edit1 steht ein koreanischer Text. Der erste Button wandelt diesen von UTF16 auf UTF8 und komprimiert den Text mit der ZLib. Ergebnis landet im Edit2. Button2 nimmt den Text aus Edit2, dekomprimiert ihn und wandelt von UTF8 auf UTF16.

Das Problem:

Unter englischem Windows 7, englischem Windows 10 (neu installierte VM), oder einem Windows 10 mit einem koreanischen Sprachpaket schaut das Ergebnis so aus:

Anhang: CMjWwZR.png

Unter einem nativen koreanischen Windows 10 (neu installierte VM) schaut das Ergebnis so aus:

Anhang: lP2Cfca.png

Wo ist mein Fehler?

p.s.

Liegt nicht speziell an dem koreanischen Windows 10, da ich Userberichte habe dass es auf anderen asiatischen Windows 10 Versionen sich genauso verhält. Es liegt auch nicht am Edit-Feld, die Länge von Result beim Compress() ist immer anders (47 bei westlichen Windows, 28 bei asiatischen Windows).

[Bernhard Geyer]

Hab jetzt kein Delphi zur Hand um das einzeln nachzustellen, ich vemute aber das dein UTF8-String an einigen Stellen nach (Unicode-)String gecastet wird und somit die Sonderzeichen im UTF8-String kaputt gehen.
Auch kannst du einen Komprimierten Stream nicht einfach in einem Editfeld anzeigen. Hier fehlt mindestens eine Base64 oder Hex-Codierung damit die (versuchte) Anzeige nicht auch noch zu Datenänderung führt.

[Shark99]

Danke für die Antwort.

Am Edit-Feld liegt es auch nicht, weil noch in der Compress() Funktion die Länge von Result im Englischen Windows 10 mit koreanischen Languagepack 47 Bytes hat, im original koreanischen Windows 10 jedoch 28 Bytes.

Zeige ich nun so an:

Delphi-Quellcode:

function Compress(aText: string; aCompressionLevel: TZCompressionLevel=zcMax): UTF8String;
var
  strInput,
  strOutput: TStringStream;
  Zipper: TZCompressionStream;
  s: UTF8String;
begin
...
    Result := strOutput.DataString;
    Form2.Caption := IntToStr(Length(Result));
...
end;

edit:

Bin nun nicht mehr so sicher ob WideStringToUTF8() aus JclStringConversions auf jedem System gleich arbeitet. Hier könnte wirklich der Fehler sein.

Hab statt dessen nun die Delphi 2009 native UTF8Encode() Funktion versucht. Die macht aber rein gar nichts, Output ist immer gleich Input.

[Sir Rufo]

Es können nur Bytefolgen komprimiert werden und erhält eine Bytefolge.

Ein String kann man (mit einer bestimmten Kodierung) in eine Bytefolge überführen um diese dann zu komprimieren. Diese komprimierte Bytefolge dann als String zu interpretieren ist gelinde gesagt grober Unfug.

Eine Interpretation als Hex-String oder Base64 wäre ja noch korrekt.

Ob das jetzt wirklich der Auslöser ist, weiß ich nicht, aber erst macht man alles richtig, was schon mal falsch ins Auge fällt und schaut dann, was für ein Fehler übrig bleibt.

[Shark99]

Nach mehr Debugcode sehe ich dass es an der string (=UnicodeString) nach UTF8 Konvertierung liegt.

AText ist immer 123축하합니다abc

Unter englischen Win 10 mit koreanischen Languagepack ergibt sich

s: UTF8String;
...
s := WideStringToUTF8(aText); // Length(s) = 25

Unter original koreanischen Win 10 ergibt sich

s: UTF8String;
...
s := WideStringToUTF8(aText); // Length(s) = 41

Damit ist WideStringToUTF8() aus JclStringConversions.pas nutzlos.

UTFEncode() aus System.pas macht rein gar nichts. Muss mich also nach neuer UTF8 Funktion umsehen.

[Uwe Raabe]

Zitat von Shark99:

UTFEncode() aus System.pas macht rein gar nichts. Muss mich also nach neuer UTF8 Funktion umsehen.

Ich habe jetzt zwar gerade kein D2009 zur Hand, aber dafür gibt es heute doch TEncoding. Dann würde ich auch nicht mit AnsiString arbeiten, da das ja per default auf die aktuelle Codepage eingestellt ist, sondern direkt mit TBytes (wie ja bereits empfohlen wurde).