Delphi XE, Utf8 in Textdatei

[FrankJ28]

Hallo Forum,
hat jemand eine Tip für mich, wie ich einen String als Utf8-Zeichenkette in ein Textfile bekomme.

Code:

writeln(TextDatei,AnsiToUtf8(MeinString));

funktionierte bis Delphi 2007 prima. Da MeinString nun Unicode ist und writeln offensichtlich nur noch ANSI ausliefert ....

Danke für jeden Tip
Ciao
Frank

[himitsu]

{TStringList}.SaveToFile(..., TEncoding.UTF8)

[FrankJ28]

soll heißen den ganzen "Schmonz" (ist ja leider nicht nur eine Zeile) zunächst in eine StringList schreiben und dann das gesammelte Werk auf Platte? Probiere ich nachher einmal aus, glücklich macht es mich aber nicht.
Trotzdem Dank für die Mühe/Idee
Ciao
Frank

[Deep-Sea]

Sofern die zu schreibenden Daten nicht die Kapazität des Arbeitsspeichers überschreiten geht das wohl, ja.
Falls es jedoch mehr ist, kann man natürlich auch mit einem TFileStream arbeiten

[Bbommel]

Hi Frank,

müsste auch so gehen:

writeln(textDatei,utf8encode(meinString));
Hatte ich bis vor kurzem hier problemlos im Einsatz, um Dateien mit UTF8-Codierten Strings auszugeben. Mittlerweile mache ich das auch mit einer TStringList, aber das hat andere Gründe.

Bis denn
Bommel

[shmia]

Keine Ahnung, wieso es immer noch Programmierer gibt, die an ReadLn und WriteLn kleben wie Politiker auf ihren Stühlen.
read, readln, write, writeln, AssignFile, rewrite, usw. sind steinalte Funktionen aus der Pascal-Ära.
Hätte Pascal damals schon Objekte gekannt, dann hätte Prof. Niklaus Wirth die Dateifunktionen niemals in den Sprachumfang von Pascal aufgenommen.
Aus heutiger Sicht war es jedenfalls ein Fehler die Funktionen in Pascal aufzunehmen.

[Bbommel]

Hallo shmia,

hm, readln/writeln für die Datei-Ausgabe zu verdammen, nur weil sie aus der Pascal-Ära stammen, ist dann aber auch ein bisschen einfach. Viele andere Elemente in Delphi stammen auch noch aus Pascal-Zeiten und deswegen sind sie ja nicht böse - und umgekehrt ist ja eine Lösung nicht sofort toll, nur weil sie objektorientiert umgesetzt ist.

Wie geschrieben habe ich bis vor kurzem auch noch oft auf readln und writeln gesetzt und das erst gelassen, weil es da im Zusammenhang mit irgendwelchen Einstellungen vom Samba-Servern diverser Kunden spürbare Perfomance-Probleme gab, die es bei der Art wie die modernen Stream-Operationen die Daten einlesen, offensichtlich nicht gibt.

Aber der Grund, warum ich (und wahrscheinlich auch die meisten anderen, die es noch immer tun) readln/writeln bis vor kurzem eingesetzt habe, ist, dass es so schön einfach ist, seit Jahrzehnten funktioniert und man trotz der Einfachheit eine recht gute Kontrolle hat, was eigentlich passiert.

Gerade das Beispiel von UTF8-kodierten Text-Dateien ist ein sehr schönes:

Wenn ich diese mit TStringList und TEncoding.UTF8 lesen möchte, dann zickt die StringList rum, sobald in der Datei Zeichen vorkommen, die nicht sauber UTF8-kodiert sein. Die StringList schmeißt dann kurzerhand einfach alles weg und das ist natürlich total ärgerlich. Wenn ich mich selber um das Einlesen via readLn kümmere, dann kann ich mir im Programm selbst überlegen, wie ich mit solchen Fällen umgehe: ich könnte eine ordentliche Fehlermeldung ausgeben oder die einzelne Zeile einfach mit UTF8Decode ausgeben, was dann zwar zu einer unsauberen Textausgabe führt, aber allemal besser ist als nix (so sehen es zumindest die meisten Benutzer).

Klar, das kann ich auch mit einem TFileStream lösen, müsste mich dann aber selber um das zeilenweise Einlesen der Daten kümmern. Oder ich versuche die TStringList davon abzuhalten, die Daten im richtigen Format einzulesen.

Irgendwie geht das also alles, aber mit raedLn/writeLn ist es halt schön einfach, und deswegen wird es wohl auch noch immer so oft genutzt.

Bis denn
Bommel

[FrankJ28]

Zitat von shmia:

Keine Ahnung, wieso es immer noch Programmierer gibt, die an ReadLn und WriteLn kleben wie Politiker auf ihren Stühlen.

@Andreas: weil diese Programmierer einer speziellen Aufgabenstellung/Plattform gerecht werden müssen.

@Bommel: Danke, klappt.

Ciao
Frank