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