Umlaute aus Textdatei in TStringList

[baba]

Aber was steht denn nun Byte-mässig in der Datei?
Kann sie gelesen werden, wenn du sie in Notepad nach Latin1 bzw. UTF-8 umwandlest?

Wenn ich sie mit dem Editor als UTF-8 speichere, bekomme ich statt der Umlaute die entsprechende Kodierung. Für das ä eine Art A und ein Kreis mit einem kleinen Strich, jeweils bei 2, 4, 8, 10 Uhr.

Dies war zu erwarten, da das Programm nun ANSI erwartet, dieses beim Einlesen in UTF-8 umwandelt, mit UTF-8 arbeitet und beim Speichern wieder in ANSI konvertiert.

Gruß
Baba.

[Christian]

Was ich nicht verstehe ist folgendes:

Code: Alles auswählen

StringList.Add('Erwin Müller'); // Ist Müller nun UTF8
          StringList.SaveToFile('TEST.TXT'); // (Editor: Eine Zeile, Erwin Müller)
          StringList.Clear;
          StringList.LoadFromFile('TEST.TXT');
          ShowMessage(StringList.Strings[0]); // Anzeige leeres Fenster
 

Deine SourceDatei ist nicht utf-8 encoded dadurch geht die zuweisung in die hose und es wird nichts angezeigt.
Rechte maustaste im Quelltexteditor->Dateieinstellungen->Kodieren->UTF-8 hilft.

[mschnell]

Rechte maustaste im Quelltexteditor->Dateieinstellungen->Kodieren->UTF-8 hilft.

Wird dem Compiler dadurch mitgeteilt, dass die Source-Code-Datei im uft-8-Format vorliegt, oder wird die Datei umcodiert und neu abgespeichert ?

-Michael

[theo]

afaik umcodiert.

[Christian]

Nein die datei wird einfach in UTF-8 gewandelt wodurch der compiler nichts umwandeln braucht.

[marcov]

Wie ich es verstanden habe:

StringList.Add('Erwin Müller'); // Ist Müller nun UTF8

 
'Erwin Mueller' wird nach mit den compiler encoding in einen ansistring umgewandelt, folgen -Fc parameter. (oder den default Encoding, typisch ISO-8859-1 oder -15, also mit high ascii, aber nie utf-8, eben wann der Linux Konsole UTF-8 ist.).
 

StringList.SaveToFile('TEST.TXT'); // (Editor: Eine Zeile, Erwin Müller)

 
Das wird dan binaer in test.txt geschrieven.
 
(bin SEHR vorsichtig mit den Editor. Editoren konvertieren oft Dateien und das kann den ganzen Test korrumpieren!)
 

StringList.Clear;
StringList.LoadFromFile('TEST.TXT');

 
Und wieder aufgeholt.
 

ShowMessage(StringList.Strings[0]); // Anzeige leeres Fenster

 
und showmessage (ein Lazarus Bibliotheken mit handcodierter UTF-8 Support erwartet ein Ansistring mit UTF8 darin und nicht ISO8859-1 -> Problem.
 
Also richtig:
 

Code: Alles auswählen

 
showmessage (utf8encode(StringList.Strings[0]);
 

 

[Christian]

'Erwin Mueller' wird nach mit den compiler encoding in einen ansistring umgewandelt, folgen -Fc parameter. (oder den default Encoding, typisch ISO-8859-1 oder -15, also mit high ascii, aber nie utf-8, eben wann der Linux Konsole UTF-8 ist.).

Wenn der Surce Code wie vorgeschlagen in UTF-8 kodiert ist wird logischerweise auch der String in UTF-8 in die Stringlist geaddet.

[marcov]

'Erwin Mueller' wird nach mit den compiler encoding in einen ansistring umgewandelt, folgen -Fc parameter. (oder den default Encoding, typisch ISO-8859-1 oder -15, also mit high ascii, aber nie utf-8, eben wann der Linux Konsole UTF-8 ist.).

Wenn der Surce Code wie vorgeschlagen in UTF-8 kodiert ist wird logischerweise auch der String in UTF-8 in die Stringlist geaddet.

Wenn der Kompiler sich nicht verschluckt. Source im UTF-8 Format konnte funktionieren, ist aber nicht garantiert. Also das ist einen Hack, und eben ein dreckige Hack.

Also der Kompiler kennt kein UTF-8 (oder das hat sich erst kurz her geändert), aber man kann versuchen ihm zu täuschen.

Ich kann mich aber irren, ich habe das ganze Encodings Teil eine weile nicht verfolgt.

[mschnell]

Wenn der Surce Code wie vorgeschlagen in UTF-8 kodiert ist wird logischerweise auch der String in UTF-8 in die Stringlist geaddet.

Das ist sicherlich wahr.

Ich finde es aber überhaupt nicht logisch/wünschenswert, dass der binäre Wert in einer Variablen, der eine Konstante zugewiesen wird, von der Kodierung der Source-Datei abhängt.

-Michael

[mschnell]

Ich kann mich aber irren, ich habe das ganze Encodings Teil eine weile nicht verfolgt.

Wüste Diskussionen aud fpc-devel .
Mit UTF-8 kommt man auf keine sinnvolle, der ein einfaches rekompilieren von alten Code ohne massive Einschränkungen/Inkompatibilitäten erlaubt. Deshalb ist in D2009 ein String auch immer ein WideString.

Es wird anscheinend gerade eine vollkommen andere Implementierung fertig

-Michael

[marcov]

Ich kann mich aber irren, ich habe das ganze Encodings Teil eine weile nicht verfolgt.

Wüste Diskussionen aud fpc-devel .
Mit UTF-8 kommt man auf keine sinnvolle, der ein einfaches rekompilieren von alten Code ohne massive Einschränkungen/Inkompatibilitäten erlaubt.

Mit keiner Encoding schaft man das. Menschen die glauben das dass functioniert mit zb tunicodestring Betrugen nur sich selber.

Unicode es einfach anders. UTF-8 hat als vorteil das es als ein-byte encoding ASCII kompatible ist wen Programme nur Strings durch geven. UCS-2 ist einfacher wenn mann ein Westerescher Sprache mit ein par Akzente hat, und nicht zu kritisch ist. Beide haben so ihre Probleme un Starken. Das ist auch warum manche OSen UTF-8 gewählt haben, und einige UTF-16.

> Deshalb ist in D2009 ein String auch immer ein WideString.

Quatsch. Borland folgt immer Microsoft slavisch, und hat sowieso Komptabilität mit ihre eigene UTf-16 .NET Versuchen zu berücksichtigen. Die hatten keiner Wahl. Borland hat nie etwas mit portabler Perspektiv gemacht. (*)

Siehe zb hier: http://dannythorpe.com/2007/10/21/on-leaving-borland/" onclick="window.open(this.href);return false; wo ich Danny nach die Grunde frag, weshalb Kylix so nicht Portabel nach andere Unixen ist, und eben nach nicht standard Linuxen.

> Es wird anscheinend gerade eine vollkommen andere Implementierung fertig

Das schon, aber das war schon immer die Absicht. Mann kann nie eine Encoding wählen die ein Target ganz fremd ist. Und *nix setzt meistens auf UTF-8.

Deshalb ist der ganze Diskussion im FPC-devel quatsch. Die Pläne sind schon in April/Mai gemacht, und zweimal Korrigiert als wir erfuhren das was Tiburon macht, weil anders, sich etwas vereinigen ließ mit FPC's originale Plane. (UTF-8 war original auf TUnicodestring gemultiplext, und es gab auch ein UTF-32 Encoding in TUnicodestring in die orignal Plane. Weil Tiburon alle 1 byte typen auf ansistring multiplex, tun wir das auch, wir hatten das original nicht Vorsehn, weil Ansistring unmodifiziert bleiben sollte für Delphi Komptabilität)

Es soll eben jemand geben der tatsächlich etwas tut. Yuri versucht gerade System + Sysutils zu modificieren fuer unicode, und vielleicht ist Florian schon mit

(*) und eben aus nicht portabler Ansicht ist Borland ein bisschen from native Delphi Territorium entfernt. Set of char funktioniert nicht mehr, TEncoding/TCharacter ist ein class. (Warum?)

[Christian]

Wenn der compiler einen utf8string unterstützen würde und auch entsprechend kodiert und die kodierung der Source Datei erkennen kann (sofern ein bom gesetzt ist) sollte sich die unicode diskussion zumindest im Lazarus weitestgehend verflüchtigen. UTF-8 ist für Lazarus die beste Möglichkeit. Die meissten Widgetsets arebiten nativ mit UTF-8 und es ist abwärtskompatibel zu ANSI. Das hauptproblem ist das der fpc nicht selbst entscheiden kann wann eine UTF-8 zuweisung gemacht werden muss und wann ein utf8 pos oder copy oder ä. gemacht werden muss. das würde mit einem eigenen stringtypen gehn. Damit würden sich also die meissten probleme verflüchtigen.

[mschnell]

Hatte ich auch gedacht. Ist aber leider sehr viel komplizierter. Siehe die Diskussionen in fpc-devel. Da wurde ih wegen ebendieser Meinung gerade ziemlich fertiggemacht. Ergebnis:

Wer als Programmiere UTF8 einsetzen will, muss sich wirklich genau mit Unicode auskennen. Mit Widestrings (in Europa reicht da die UCS2-Codierung) ist das für den Programmiere viel einfacher und der Code bleibt kompatibel zum Code für 1-Byte ANSI-kodierte Strings. KLeider Zwingt uns Lazarus momentan die utf8-Kodierung auf.

-Michael

[mse]

Siehe die Diskussionen in fpc-devel. Da wurde ih wegen ebendieser Meinung gerade ziemlich fertiggemacht

Trag's mit Fassung.
Als Pascal Diskussionsteilenehmer braucht man einen breiten Rücken.

Martin

[theo]

Wer als Programmiere UTF8 einsetzen will, muss sich wirklich genau mit Unicode auskennen.

Schon wieder falsch. Es muss heissen "Wer Unicode einsetzen will, muss sich mit Unicode auskennen"
UTF-8 oder UTF-16 ist da nur ein marginaler Aspekt.
Aus Compiler Sicht, haben beide gemeinsam, dass ein sichtbares Zeichen keine fixe Länge im Source hat, deshalb kann man dafür auch keinen fixen Char-Typen definieren. Was sollte MyUTF8String[1] denn zurückgeben? Einen String? Ein Cardinal?
Genauso mit UTF-16. Word? Cardinal?
Das wäre erst mit UCS-4 auf die herkömmliche Weise möglich.
Aber da gibt's noch viele andere "Schmankerl" in Unicode, welche mit den Speicher-Arten nix zu haben:
http://unicode.org/" onclick="window.open(this.href);return false;