Arbeitet ein ungarisches Windows anders als ein deutsches/englisches?

[SneakyBagels]

Mir wurde von einem einzigen Kunden aus Ungarn schon vor ein paar Tagen mitgeteilt, dass mein Tool auf seinem PC seit meinem Update nicht mehr richtig funktioniert.
Es gibt eine Unterfunktion welche einen Hash einer Datei erstellt die in einem Stream liegt. Mit StringOf() mache ich den für den Benutzer in einer ListViewansicht sichtbar.
Mehr passiert da nicht. Stream erstellen, Datei reinladen, die Bytes mit StringOf sichtbar anzeigen.

Wieso funktioniert das auf deutschen, englischen und anderen Windows-Systemen, sogar unter Wine, nicht aber mit einem ungarischen Windows 7 ?
Was hier genau nicht funktioniert weiß ich leider noch nicht. Aber wenn er mir seine fehlerhafte Datei schickt, funktioniert sie auf meinem PC einwandfrei.

Daher die Grunsatzfrage. Was macht ein ungarisches Windows anders als die anderen Windows-e?

[nahpets]

Anderer Zeichensatz?

[TiGü]

Habe ich eine Bildungslücke?
Was ist die StringOf()-Funktion?

Zeige doch mal Quelltext zum Öffnen der Datei, das Laden in den Stream, das Hashen und diese Umwandlung des Hashes in einen String zur Darstellung in einer Listview.

[SneakyBagels]

Das mit dem Zeichensatz ist klar. Nur wird eine Windows-Datei vorzugsweise eine DLL in einen Stream geladen und berechnet. Die sind doch überall gleich.

[Der schöne Günther]

StringOf -> TEncoding.Default -> "On Windows, System.SysUtils.TEncoding.Default returns the default ANSI code page"

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1371138)

Habe ich eine Bildungslücke?
Was ist die StringOf()-Funktion?

Guckst du hier: http://docwiki.embarcadero.com/Libra...Utils.StringOf

Aber genau da steht auch Ursache des Problems:

Zitat:

Konvertiert ein Byte-Array anhand der Standardgebietseinstellung des Systems in einen Unicode-String.

Das heißt, daß die Byte-Sequenz (in diesem Fall der Hash) als Ansi-Zeichen der aktuell eingestellten Code-Page interpretiert wird - und die ist halt nicht auf jedem Windows gleich. Es kann Zufall sein, daß das bisher nicht aufgefallen ist. Der Hash hat sich vermutlich mit dem Update geändert und enthält nun Bytes, die bei der obigen Interpretation unterschiedlich sind.

Wenn man nicht garantieren kann, daß die übergebenen Bytes eine gültige Zeichencodierung darstellen, dann sollte man eine andere Form der String-Umwandlung wählen. Dazu müsste man hier aber mehr über der Hash-Algorithmus wissen.

[SneakyBagels]

Zitat:

Konvertiert ein Byte-Array anhand der Standardgebietseinstellung des Systems in einen Unicode-String.

Und ich dachte immer Byte ist Byte weltweit. Ich benutze ganz normal wie wahrscheinlich jeder andere auch die Jedis dafür.

[TiGü]

Guck an, kannte ich noch nicht.
Auch eine Suche bei Google mit "StringOf delphi" hat das nicht sofort auf der ersten Seite hingezaubert.

[Neutral General]

Zitat:

Zitat von SneakyBagels (Beitrag 1371145)

Zitat:

Konvertiert ein Byte-Array anhand der Standardgebietseinstellung des Systems in einen Unicode-String.

Und ich dachte immer Byte ist Byte weltweit. Ich benutze ganz normal wie wahrscheinlich jeder andere auch die Jedis dafür.

Byte ist Byte.
Aber String ist nicht String. Das ist das Problem ;)

[SneakyBagels]

Ich hatte gerade kurz darüber nachgedacht SetCodePage zu verwenden aber ich glaube das sind Dinge wo man sich nicht ins System einmischen sollte nehme ich an.

Zitat:

Aber String ist nicht String.

Außer Unicodestring. Der kann soweit ich weiß quasi alle Zeichen aufnehmen. Der sollte doch überall gleich sein.
Ich sehe gerade bei Wikipedia, dass die ungarische Codepage genau wie die deutsche 1250 ist.
https://en.wikipedia.org/wiki/Windows-1250

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1371145)

Zitat:

Konvertiert ein Byte-Array anhand der Standardgebietseinstellung des Systems in einen Unicode-String.

Und ich dachte immer Byte ist Byte weltweit. Ich benutze ganz normal wie wahrscheinlich jeder andere auch die Jedis dafür.

Du stellst aber eben keine Bytes dar sondern Buchstaben und die Zuordnung von Bytes zu Buchstaben ist nun mal nicht einheitlich. Wenn du auf Nummer sicher gehen willst, dann zeige die Bytes als Hex an oder verwende z.B. Base64 wenn es etwas kürzer werden soll.

[SneakyBagels]

Wie würde das denn mit Base64 funktionieren? Mit Base64 hatte ich noch nie etwas zu tun.
Würde man hier dann die Bytes des Streams in Base64 wandeln sehe ich das richtig?

Vielleicht so?

Delphi-Quellcode:

... EncodeBase64(stream.Memory, stream.Size); // TBytesStream, gefüllt mit einer binary über loadfromfile

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1371154)

Wie würde das denn mit Base64 funktionieren? Mit Base64 hatte ich noch nie etwas zu tun.
Würde man hier dann die Bytes des Streams in Base64 wandeln sehe ich das richtig?

Base64 ist eine konsistente Art, eine Byte-Sequenz als lesbaren Text darzustellen - ebenso wie die Darstellung als Hex-String, nur kürzer. In der aktuellen Delphi Version 10.2 Tokyo findest du in System.NetEncoding in TNetEncoding.Base64 eine entsprechende Hilfsklasse für diesen Zweck. Ältere Delphi-Versionen haben das auch irgendwo (weiß nur gerade nicht mehr wo).

[SneakyBagels]

Zitat:

Ältere Delphi-Versionen haben das auch irgendwo (weiß nur gerade nicht mehr wo).

Soap.EncdDecd?

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1371156)

Zitat:

Ältere Delphi-Versionen haben das auch irgendwo (weiß nur gerade nicht mehr wo).

Soap.EncdDecd?

Richtig :thumb:

[SneakyBagels]

TNetEncoding nimmt als Eingansparameter einen Stream und schreibt die Ausgabe ebenfalls in einen Stream.
Soap.EncdDecd.EncodeBase64 nimmt einen Stream und gibt einen String zurück.

Wären die Resultate denn bei beiden gleich? Falls ja, verwende ich glaube ich EncodeBase64 denn dann spare ich mir eine Stream-Variable.

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1371158)

TNetEncoding nimmt als Eingansparameter einen Stream und schreibt die Ausgabe ebenfalls in einen Stream.
Soap.EncdDecd.EncodeBase64 nimmt einen Stream und gibt einen String zurück.

Wären die Resultate denn bei beiden gleich? Falls ja, verwende ich glaube ich EncodeBase64 denn dann spare ich mir eine Stream-Variable.

Das Ergebnis sollte in beiden Fällen gleich sein. Der Stream enthält die Base64-codierten Zeichen in ASCII/UTF-8 (es werden nur Zeichen im unteren Bereich verwendet, daher ist das hier egal).

TNetEncoding hat auch eine Funktion EncodeBytesToString, allerdings nimm die keinen Stream als Parameter.

[SneakyBagels]

Zitat:

TNetEncoding hat auch eine Funktion EncodeBytesToString, allerdings nimm die keinen Stream als Parameter.

Notfalls nimmt sie dann ja stream.bytes.

Nur noch einmal zum Mitschreiben. Vorher habe ich mit StringOf (also TEncoding und Default Codepage) einen Stream in einen String geändert und dann in einen Hash.
Das ging wegen der anderen Codepage oder warum auch immer oder weil string nicht gleich string ist schief.
Den Stream mittels Base64 in Base64 zu ändern und dann diesen String den ich als Rückgabe bekomme in einen Hash das funktioniert auch bei anderen Codepages korrekt?

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1371162)

Vorher habe ich mit StringOf (also TEncoding und Default Codepage) einen Stream in einen String geändert und dann in einen Hash.

Wirklich? Ich dachte du hast erst aus dem Stream einen Hash ermittelt und den dann in einen String umgewandelt.

[SneakyBagels]

Mir wurde gerade mitgeteilt, dass diese Änderung Abhilfe geschafft hat und nun alles funktioniert wie vorgesehen.
Ich konnte das leider nie selber testen, da ich kein Windows in der nötigen Sprache hier habe.