AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Delphi Programm verhält sich anders unter Windows 10 (DE) und Windows 10 (KOR)

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

Ein Thema von Shark99 · begonnen am 23. Aug 2015 · letzter Beitrag vom 23. Aug 2015
Antwort Antwort
Seite 1 von 2  1 2   
Shark99

Registriert seit: 16. Mai 2007
403 Beiträge
 
#1

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

  Alt 23. Aug 2015, 00:28
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).
Miniaturansicht angehängter Grafiken
cmjwwzr.png   lp2cfca.png  
Angehängte Dateien
Dateityp: zip CompressionTest.zip (386,0 KB, 1x aufgerufen)

Geändert von TBx (23. Aug 2015 um 12:08 Uhr) Grund: verlonkte ilder angehängt, sonst wird der Post unvollständig, wenn es das externe Ziel mal nicht mehr gibt.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.169 Beiträge
 
Delphi 10.4 Sydney
 
#2

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

  Alt 23. Aug 2015, 09:09
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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Shark99

Registriert seit: 16. Mai 2007
403 Beiträge
 
#3

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

  Alt 23. Aug 2015, 09:24
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.

Geändert von Shark99 (23. Aug 2015 um 09:30 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#4

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

  Alt 23. Aug 2015, 09:31
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Shark99

Registriert seit: 16. Mai 2007
403 Beiträge
 
#5

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

  Alt 23. Aug 2015, 09:45
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.
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
10.934 Beiträge
 
Delphi 12 Athens
 
#6

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

  Alt 23. Aug 2015, 10:05
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).
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Shark99

Registriert seit: 16. Mai 2007
403 Beiträge
 
#7

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

  Alt 23. Aug 2015, 10:31
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.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#8

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

  Alt 23. Aug 2015, 10:36
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)

Geändert von Sir Rufo (23. Aug 2015 um 11:15 Uhr)
  Mit Zitat antworten Zitat
Shark99

Registriert seit: 16. Mai 2007
403 Beiträge
 
#9

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

  Alt 23. Aug 2015, 10:53
Danke sehr, TNetEncoding gibt es aber leider erst ab XE7.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#10

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

  Alt 23. Aug 2015, 10:58
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 string interpretieren.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:46 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz