Zitat:
MIt einem HEXeditor habe ich schon geschaut es sollten die richtigen zeichen ersetzt werden.
In der Datei vielleicht noch, bevor DU falsch es eingelesen und kaputt germacht hast. (natürlich fehlen hierzu sämtliche Infos von dir)
Rate mal wofür der Debugger ist ... damit kann man nachsehn, was in der Variable steckt,
aber auf einem anderen Rechner, mit anderer ANSI-Codepage, würde das dann auch nichts mehr helfen, da diese Werte nicht vor sodern nach der Konvertierung liegen.
Zitat:
OEM Konvert bringt auch nix ...
Rausfinden welches die richtige Codepage ist?
Ja, weil deine Strings bereits
Unicode sind, also bereits falsch von "
ANSI" aus konvertiert wurden und somit die Zeichen nun andere Codes besitzen.
Sei froh, dass wir keine MultiByteCodepage haben, so wie Chinesen und Co.
Denn wie beim UTF-8 können
falsche ungültige Zeichenpaare zu Fehlern führen, was auch gern die komplette Übersetzung vernichtet und z.B. einen Leerstring oder manchmal auch eine
Exception liefert.
Finger weg von String/WideString/UnicodeString, beim einlesen.
AnsiString ... nja, eigentlich RawByteString oder dirtekt AnsiString(CP_OEMCP).
Delphi-Quellcode:
#132
Chr($84)
Char($84)
AnsiChar($84)
WideChar($84)
#$84
#$0084
ist nicht immer das Selbe, vor allem die letzten Beiden nicht.
Rein logisch mögen die letzten Beiden den "gleichen" Wert haben, bezogen auf ein Char aka WideChar, aber der Compiler interpretiert es unterschiedlich.
Das eine ist
ANSI und wird mit der aktuellen Codepage übersetzt und das Andere ist direkt
Unicode.
Einmal kann man direkt im Windows spielen, aber nur wenn mit
ANSI-APIs gearbeitet.
SetFileApisToOEM
RawByteString, bzw. ein AnsiChar-Array bzw. aber besser ein Byte-Array (TBytes)
und dann
TEncoding.GetString
TEncoding.Convert
Oder bei sowas wie TStringList, TStringStream oder sonstwas die
richtige Codepage bzw.
TEncoding.
TMBCSEncoding.Create(CP_OEMCP