RawByteString in Exe modifizieren

[himitsu]

Zitat:

Zitat von himitsu (Beitrag 1456926)

Sowas wie TEncoding.ANSI.xyz ist sowieso das Schlimmste, was man einer Binärdatei antun kann.

Was soll man dazu noch weiteres sagen?

ASCII?

Nee, Binärdateien gehören binär behandelt ... jegliche Behandlung mit irgendwelche Texten und vor allem irgendwelches Umrechnen/Umcodieren in Unicode über Codepages hat hier einfach garnichts zu suchen.

ANSI ist bei uns und den Amis zugfällig 1 Byte pro Zeichen, aber das ist nicht überall so. (nur leider erfinden gerade die dann sowas Krankes, wie Binärdaten in Textstrings)
PS: UTF-8 ist ein gutes Beispiel dafür, was jeder verstehen können dürfte, wo also ein Index im Unicode nicht die selbe Position ist, wie in der Codierung.

[DieDolly]

Zitat:

Was soll man dazu noch weiteres sagen?

Irgendwie muss man die paar Bytes die man von Position X bis Y (maximal 48 wie gesagt, nicht die ganze Datei) ausliest ja lesbar machen.

Zitat:

ANSI ist bei uns und den Amis zugfällig 1 Byte pro Zeichen

Die Bytes die ich auslesen und umwandeln möchte ergeben mit absoluter Sicherheit immer Zeichen A bis Z und 0 bis 9.
Welche Möglichkeit gibt es denn sonst noch diese paar Bytes lesbar zu machen? Das ergeben am Ende ziemlich sicher rund 48 Zeichen.
Sonst hätte ich noch StringOf aus den System.SysUtils im Angebot. Ich denke das ist besser als selbst mit TEncoding zu spielen.

[himitsu]

ASCII, also das Ursprüngliche hat nur 7 Bit
EASCII (das was aktuell alle als ASCII bezeichnen) ist auch nur eine der vielen 8-Bit-Codepages.

und Default = ANSI

Zitat:

Zitat von DieDolly (Beitrag 1456995)

Die Bytes die ich auslesen und umwandeln möchte ergeben mit absoluter Sicherheit immer Zeichen A bis Z und 0 bis 9.

Aber der Rest nicht, somit ist es unmölich damit sicher die Position im Unicode zu bestimmen und dann 1:1 auf die Bytes der Datei umzurechnen.

Also egal was du machst, sobald auch nur irgendwie etwas mit Unicode im Spiel ist, war es dass, also im Prinzip ist alles mit Codepage und Encoding der falsche Weg.
Man kann zwar den Inhalt einer Datei 1:1 im einen AnsiString alle AnsiString, RawByteString usw. kopieren (SetLength+Stream.Read) und dann ANSI-Pos und Dergleichgen benutzen, aber der kleinste Fehler und schon gibt es massivr Probleme, sobald auch nur irgendwie ausversehn eine Umcodierung der Zeichen alles durcheinander bringt.

Darum ist es immer besser direkt bei ByteArrays bzw. ByteStreams zu bleiben.

[DieDolly]

Zitat:

Darum ist es immer besser direkt bei ByteArrays bzw. ByteStreams zu bleiben.

95% dieses Codes sind auf Basis von ByteStream und alles ist gut. Ich benutze StringOf(bytes) und danach Pos() um an die Positition von ein paar bestimmten Zeichen zu kommen. Das funktioniert auch auf allen Systemen scheinbar. Dann lese ich von dieser Position aus 48 weitere Zeichen (Bytes) mit ByteStream.Read aus aus und forme es am Ende in einen String um.
Das scheint jetzt augenscheinlich auch auf dem Problem-Windows zu funktionieren.

Delphi-Quellcode:

ByteStream.Position := RawBytePos - 1;
ByteStream.Read(ByteStream.Bytes[0], 48);
Str := StringOf(ByteStream.Bytes);

Das Ergebnis ist das was ich in der Exe suche.
Ist hier StrOf() oder RawByteString() besser? Dass TEncoding.ANSI wegfällt ist klar.