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:

Zitat von Shark99 (Beitrag 1313112)

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).

[Shark99]

Ich merkte schon vor paar Stunden dass die Verwendung von AnsiString, UTF8String oder sogar RawByteString ab Delphi 2009 sehr gefährlich ist weil Delphi diese Datentypen anscheinend nie in Ruhe lässt und je nach Lust und Laune PageCode-Konvertierungen damit macht. Siehe z.B. hier: http://stackoverflow.com/questions/2...oke-utf8decode

Ich habe es schon mal mit TBytes versucht.

Ich will folgendes haben.

Input ist string (=UnicodeString, also UTF16).

Ich will diesen Ziplib komprimieren (möglichst ohne UTF8 Konvertierung, schaffe es aber nicht ohne) und dann nach Base64 (nicht im Beispielcode) wandeln um in eine Datenbank zu speichern.

Delphi-Quellcode:

  s: TBytes;
...
  s := TEncoding.UTF8.GetBytes(aText);
  strInput:= TStringStream.Create(s);
  strOutput:= TStringStream.Create;

Ich komme aber danach nicht weiter, weil strOutput.DataString ein AniString ist und kein TBytes. Es verhält sich also je nach Windows-Version anders.

[Sir Rufo]

Hier mal ein korrektes Beispiel (mit XE8). Das Prinzip sollte aber klar werden.

Delphi-Quellcode:

unit Forms.MainForm;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TForm1 = class( TForm )
    InputEdit: TEdit;
    CompressedEdit: TEdit;
    DecompressedEdit: TEdit;
    CompressButton: TButton;
    DecompressButton: TButton;
    procedure CompressButtonClick( Sender: TObject );
    procedure DecompressButtonClick( Sender: TObject );
  private
    function CompressString( const AStr: string ): string;
    function DecompressString( const AStr: string ): string;
  public

  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

uses
  System.NetEncoding,
  System.ZLib;

procedure TForm1.CompressButtonClick( Sender: TObject );
begin
  CompressedEdit.Text := CompressString( InputEdit.Text );
end;

function TForm1.CompressString( const AStr: string ): string;
var
  LInput      : TStringStream;
  LZipper     : TZCompressionStream;
  LOutput     : TBytesStream;
  LOutputBytes: TBytes;
begin
  LInput  := nil;
  LOutput := nil;
  try

    LInput := TStringStream.Create(
      AStr,
      TEncoding.UTF8,
      False );
    LOutput := TBytesStream.Create;
    LZipper := TZCompressionStream.Create(
      TCompressionLevel.clMax,
      LOutput );
    try
      LZipper.CopyFrom(
        LInput,
        0 );
    finally
      LZipper.Free;
    end;

    LOutputBytes := LOutput.Bytes;
    SetLength(
      LOutputBytes,
      LOutput.Size );

    Result := TNetEncoding.Base64.EncodeBytesToString( LOutputBytes );

  finally
    LInput.Free;
    LOutput.Free;
  end;
end;

procedure TForm1.DecompressButtonClick( Sender: TObject );
begin
  DecompressedEdit.Text := DecompressString( CompressedEdit.Text );
end;

function TForm1.DecompressString( const AStr: string ): string;
var
  LInputBytes: TBytes;
  LInput     : TBytesStream;
  LZipper    : TZDecompressionStream;
  LOutput    : TStringStream;
begin
  LInput  := nil;
  LOutput := nil;
  try

    LInputBytes := TNetEncoding.Base64.DecodeStringToBytes( AStr );

    LInput  := TBytesStream.Create( LInputBytes );
    LOutput := TStringStream.Create(
      string.Empty,
      TEncoding.UTF8,
      False );
    LZipper := TZDecompressionStream.Create( LInput );
    try
      LOutput.CopyFrom(
        LZipper,
        0 );
    finally
      LZipper.Free;
    end;

    Result := LOutput.DataString;
  finally
    LInput.Free;
    LOutput.Free;
  end;
end;

end.

[Shark99]

Danke sehr, TNetEncoding gibt es aber leider erst ab XE7.

[Sir Rufo]

Zitat:

Zitat von Shark99 (Beitrag 1313119)

Danke sehr, TNetEncoding gibt es aber leider erst ab XE7.

Und? Das wandelt doch nur eine Bytefolge in einen Base64-String um.

Wohin du es umwandelst spielt keine Geige, nur kannst du die Bytefolge eben nicht direkt als

Delphi-Quellcode:

string

interpretieren.