Lazarus Fehler beim lesen einer Textdatei

[himitsu]

Zitat:

Buchentschlüsslung

Vonwegen keine Umlaute und so. :roll:

[JamesTKirk]

Zitat:

Zitat von himitsu (Beitrag 1127867)

Zitat:

Zitat von JamesTKirk (Beitrag 1127379)

Das einzig interessante war, dass ich das erste Mal die Datei, welche ich per Notepad++ auf c:\ angelegt hatte, nicht öffnen konnte; die Datei war auch im Explorer nicht sichtbar, aber im Öffnen-Dialog von Notepad++.

Ein normales Programm hat in C:\ und C:\Programme, C:\Windows, ... usw. eigentlich keine Schreibrechte, darum hat Windows diesen Schreibzugriff des Notepad++ virtuell umgeleitet.
Stichwort: VirtualStore

Da dein/dieses Programm scheinbar "schrottig" programmiert wurde, weil es versucht in Verzeichnisse zu schreiben, wo es nicht reinschreiben darf und da es nicht als Vista/Win7-Kompatibel deklariert ist, versucht Windows dennoch diese Schreibzugriffe virtuell (nur für dieses) zu erlauben, damit es nicht verreckt, wie z.B. viele andere Programme, welche dämlicher Weise immernoch versuchen in C:\Programme reinzuschreiben und damit eigentlich nicht mehr funktionieren würden, obwohl man ja eigentlich schon seit WinNT/2000 dort nicht reinschreiben sollte. :angle2:
(Ob du absichtlich oder das Programm "ausversehn" diesen Speicherplatz ausgesucht hat, ist für Windows ja nicht erkennbar)[/delphi]

Danke für die Erklärung, aber mir war durchaus bewusst, dass der Virtual Store existiert und was er bewirkt (ich hatte dem ja sogar bereits die Schuld in die Schuhe geschoben). Ich war zu dem Zeitpunkt nur etwas überrascht, dass er auch tatsächlich angeschlagen hat. :mrgreen:

Zitat:

Zitat von foerster7892 (Beitrag 1127892)

C:\Users\MeinName\Desktop\Buchentschlüsslung\Zahle nfolgen\zahlenfolge3.txt

Nutze

Delphi-Quellcode:

Utf8ToAnsi

bzw.

Delphi-Quellcode:

Utf8ToSys

, wenn du einen String von der LCL an eine Funktion/Methode in der RTL bzw. FCL übergibst, dann passieren dir solche Probleme nicht (umgekehrt gilt das übrigens auch, da musst du jedoch

Delphi-Quellcode:

AnsiToUtf8

bzw.

Delphi-Quellcode:

SysToUtf8

verwenden).

Gruß,
Sven

[himitsu]

TStringList nutzt doch hoffentlich CreateFileW und wandelt seine UTF-8-Strings selber um?

Statt dem älternen AssignFile könnte/sollte man sich dann vielleicht doch mal mit TStringList anfreunden.

[JamesTKirk]

Zitat:

Zitat von himitsu (Beitrag 1127945)

TStringList nutzt doch hoffentlich CreateFileW und wandelt seine UTF-8-Strings selber um?

Statt dem älternen AssignFile könnte/sollte man sich dann vielleicht doch mal mit TStringList anfreunden.

Selbst wenn

Delphi-Quellcode:

TStringList

Delphi-Quellcode:

CreateFileW

nutzen würde (tut es nicht, am Ende der Kette steht ein

Delphi-Quellcode:

CreateFileA

), würde das nichts nutzen, da per Definition die Units aus der RTL und der FCL die systemspezifische Kodierung verwenden. Unter Linux kann dies durchaus UTF-8 sein, aber zum Beispiel auf einem deutschen Windows ist dies CP1252. Das würde also bei der hypothetischen Verwendung von

Delphi-Quellcode:

CreateFileW

bedeuten, dass irgendwo in der Aufrufkette von

Delphi-Quellcode:

LoadFromFile

hinunter zu

Delphi-Quellcode:

CreateFileW

eine Ansi -> UTF-16 Konvertierung stattfinden würde und dann wären deine UTF-8-Zeichen nur noch Müll.

Gruß,
Sven