ASCII(cp850)ToUTF8 ?

[lichtwicht]

ASCII To UTF8:
nach (etlichem) Suchen habe ich nichts dergleichen gefunden...
1. Gibt es sowas schon? (wenn ja, wo?)

2.
gefunden habe ich die "unit LConvEncoding"
da gibt's russisch(866) und Thai(874) aber kein Latin-I(850) !?!?
also habe ich mal damit angefangen...(siehe Anhang("neue" Sachen in 2 REM-Zeilen(// lw-a und // lw-e) eingepackt))
EDIT 6.1.09:
hier mal ein Asschnitt:

Code: Alles auswählen

zum testen ggf. hilfreich:
  hope:=#128#129#130#131#132#133#134#135#136#137#138#139#140#141#142#143#144#145#146#147#148#149#150#151#152#153#154#155#156#157#158#159#160#161#162#163#164#165#166#167#168#169#170#171#172#173#174#175#176#177#178#179#180#181#182#183#184#185#186#187#188#189#190#191#192#193#194#195#196#197#198#199#200#201#202#203#204#205#206#207#208#209#210#211#212#213#214#215#216#217#218#219#220#221#222#223#224#225#226#227#228#229#230#231#232#233#234#235#236#237#238#239#240#241#242#243#244#245#246#247#248#249#250#251#252#253#254#255;
  hop2 := ConvertEncoding (hope, 'cp850', 'utf8');
  modstats.lines.Add(hop2);

leider "funktionieren" die GrafikZeichen nicht(werden nicht korrekt in einem TMemo angezeigt)...
z.B. #176#177#178 (Schattierungen░▒▓) (UTF8?: #226#150#145, #226#150#146, #226#150#147)
EDIT 6.1.09:
ich muß dem TMemo auch eine Font geben, die die Zeichen auch darstellen kann!!!
Tips?(/EDIT)
aber die Umlaute!(üöä usw.)
...
also, wenn mir hier keiner eine Unit/Funktion rausdeuten kann(1.), "schreibe" ich die Rückkonvertierung auch noch...

grüße, lichtwicht

[theo]

Der Witz ist halt, dass Unicode bis 255 das gleiche ist wie Ansi.

Insofern müsste ein UTF8Decode / Encode dasselbe leisten.

Ausserdem sollte man bevor man das Rad neu erfindet, die schon "ewig" vorhandene Unit synachar in Synapse eines Blickes würdigen:
http://synapse.ararat.cz/doc/help/synachar.html" onclick="window.open(this.href);return false;

[mschnell]

http://synapse.ararat.cz/doc/help/synachar.html

Super ! Das sollte auch Puto's UTF-8 Frage lösen. Oder ?
-Michael

[marcov]

Unit charset?

In 2.2.4 wird es auch ein FPC iconv package geben. Die Lazarus liconvencoding unit wird dan reimplementiert

[theo]

Unit charset?

Was tut die?

[marcov]

Unit charset?

Was tut die?

Ein unit um entweder externe charmaps laden zu koennen (ziehe fpc/rtl/ucmaps), und diese Maps koennen auch in units umgewandeld werden und ingelinkt werden.

Eine Art von embedded iconv

[theo]

Ein unit um entweder externe charmaps laden zu koennen (ziehe fpc/rtl/ucmaps), und diese Maps koennen auch in units umgewandeld werden und ingelinkt werden.

Interessant. Das kannte ich noch nicht.
In welchem Verhältnis steht die zu LConvEncoding? Dürfte sich ziemlich überschneiden oder?

[lichtwicht]

Der Witz ist halt, dass Unicode bis 255 das gleiche ist wie Ansi.

Insofern müsste ein UTF8Decode / Encode dasselbe leisten.

tut es eben nicht...in ANSI(cp1250)(?) ist z.B. das ü $FC
in ASCII(cp850)(?) $81

Ausserdem sollte man bevor man das Rad neu erfindet, die schon "ewig" vorhandene Unit synachar in Synapse eines Blickes würdigen:
http://synapse.ararat.cz/doc/help/synachar.html" onclick="window.open(this.href);return false;

(wenn man weiß wo man suchen muß...danke für den Link!...allerdings bezweifle ich, daß mich das wirklich weiterbringt...)

Unit charset?

In 2.2.4 wird es auch ein FPC iconv package geben. Die Lazarus liconvencoding unit wird dan reimplementiert

heißt dann für mich: abwarten und Tee trinken
Danke schonmal im Vorraus!

[theo]

tut es eben nicht...in ANSI(cp1250)(?) ist z.B. das ü $FC
in ASCII(cp850)(?) $81

Kann sein. In /rtl/ucmaps gibt es eine Variante für cp850.
Diese kannst du wohl mit der von marcov erwähnten unit charset verwenden.

[marcov]

Unit charset?

In 2.2.4 wird es auch ein FPC iconv package geben. Die Lazarus liconvencoding unit wird dan reimplementiert

heißt dann für mich: abwarten und Tee trinken
Danke schonmal im Vorraus!

Fast alle 2.2.3's haben es auch schon. Versuche mal "uses iconvenc;"

iconvenc ist ein iconv header mit ein kleine Util Procezur "iconvert".

Siehe packages/iconvenc/examples/iconvtest.pp

[marcov]

Ein unit um entweder externe charmaps laden zu koennen (ziehe fpc/rtl/ucmaps), und diese Maps koennen auch in units umgewandeld werden und ingelinkt werden.

Interessant. Das kannte ich noch nicht.
In welchem Verhältnis steht die zu LConvEncoding? Dürfte sich ziemlich überschneiden oder?

Ja, teilweise. Aber lconvencoding ist meistens organisch hackish gewachsen denk ich, versucht zu viel in einem Unit zu Tun (eigen encoding, iconv als Bibliothek , iconv als executable via Tprocess usw).

Charset ist nur ein bisschen Logik das Tabellen laden kann die codepagesunicode (absolut also encodings-los) Mappings beschreiben. Das Tabel file Format ist aehnlich zu Unicode Konsortium eigenes Format, und das macht Maintenance einfach. Tabellen können hardcoded sein (mitgelinkt, wandelen die Tabellen um nach units mit utils/creumap) oder man kann einfach die Files mit Funktionen in der Unit lesen.

Eine Kopie von Charset wird auch durch dem Kompiler genutzt um {$codepage xxx} zu implementieren. (Das ( $codepage xxx} Direktiv ist nebenbei etwas was ich auch vermisst habe in die letzte paar ("Erkennen ob das Zeichen ein UTF8 Zeichen ist") Unicode Diskussionen. Der Kompiler nutzt charset um statisch Linkable zu bleiben). Die kompilierte version von ucmaps/* kann mann auch im Kompiler-Verzeichnis sehen als cp*.pas

Lazarus Apps (auf Unix) nutzen aber immer schon libc via GTK oder QT, oder sogar absolut immer ( OS X). Also in den Zukunft wird lconvencoding denk ich einfach immer iconv(enc) nutzen auf Unix/OS X, und Windows api auf windows. Vielleicht kan man aber iconvencoding hacken fuer Embedded targets (zb Linux-embedded ohne iconv) um Charset+ ein paar codepages (zb 437,850 und zb Ost-Europäische 8859-x ) hart ein zu linken oder nach zu laden.

Aber das ist eine Entscheidung der das Lazarus Team machen muss. Obschon In generell ich mich nur mit Lazarus (-Development) beschäftige wann es FPCLazarus betrefft, ist dies etwas dass ich tun könnte weil ich iconvenc gemacht habe, und Charset kenne.

[mse]

Das ( $codepage xxx} Direktiv ist nebenbei etwas was ich auch vermisst habe in die letzte paar ("Erkennen ob das Zeichen ein UTF8 Zeichen ist") Unicode Diskussionen.

Die {$codepage xxx} Direktive oder -Fcutf8 darf für Lazarus nicht angegeben werden, da die string Konstanten sonst zur Laufzeit von widestring auf die Systemcodierung gewandelt werden. Lazarus erwartet aber immer utf-8, auch auf Systemen die ANSI Codierung verwenden, z.B. Windows. Dies macht die Verwendung von widestrings unter Lazarus etwas schwierig.

Martin

[marcov]

Das ( $codepage xxx} Direktiv ist nebenbei etwas was ich auch vermisst habe in die letzte paar ("Erkennen ob das Zeichen ein UTF8 Zeichen ist") Unicode Diskussionen.

Die {$codepage xxx} Direktive oder -Fcutf8 darf für Lazarus nicht angegeben werden, da die string Konstanten sonst zur Laufzeit von widestring auf die Systemcodierung gewandelt werden. Lazarus erwartet aber immer utf-8, auch auf Systemen die ANSI Codierung verwenden, z.B. Windows. Dies macht die Verwendung von widestrings unter Lazarus etwas schwierig.

So fern wie ich das verstanden habe meint $codepage die codierung von literals ?

Nehme an das der Systemencodung UTF-8 ist. Kannst du dann ein Problem schildern wo literalwidestring ansistring mit utf-8 encoding ein problem gibt?

[theo]

Also du schlägst vor die iconvenc zu benutzen. Die hat aber wieder mit der unit charset und LConvEncoding nichts zu tun oder?
Funktioniert das auf allen Systemen?
Bin grade ein bisschen von den verschiedenen Varianten verwirrt.

Welches ist die empfehlenswerteste Funktion um Plattformunabhängig die Funktionalität von iconvenc.Iconvert bzw. LConvEncoding.ConvertEncoding auszuführen?

[mse]

So fern wie ich das verstanden habe meint $codepage die codierung von literals ?

Ja.

Nehme an das der Systemencodung UTF-8 ist. Kannst du dann ein Problem schildern wo literalwidestring ansistring mit utf-8 encoding ein problem gibt?

Dann gibt es kein Problem. Probleme gibt es wenn die Systemcodierung nicht utf-8 ist, beispielsweise auf Windows.
Ich bin nicht sicher, ob ich dich richtig verstanden habe, darum nochmals die ganze Erklärung:

Falls {$codepage xxx} oder -Fuxxx angegeben wird, werden string-Literale zur compile Zeit aus dem Quelltext unter Verwendung der angegebenen Codierung in widestrings gewandelt, bei Zuweisungen zur Laufzeit an ansistring wird von widestring mittels des widestringmanagers auf die aktuelle Systemcodierung gewandelt.
Werden {$codepage xxx} und -Fuxxx nicht angegeben, werden die string-Literale zur compile Zeit nicht konvertiert sondern als Bytefolge gespeichert. Zur Laufzeit wird die Bytefolge unverändert in ansistring kopiert.
Lazarus ist darauf angewiesen, dass Zuweisungen string-Literal->ansistring immer utf-8 codiert sind. Daher speichert Lazarus den Quelltext in utf-8, gibt aber kein {$codepage utf8} oder -Fcutf8 an, damit unter Windows nicht auf ANSI gewandelt wird. Dadurch funktioniert nun die FPC Zuweisung string-Literal->widestring nicht mehr, da der widestringmanager Systemcodierung erwartet und nicht utf-8.
Siehe auch
http://www.lazarusforum.de/viewtopic.ph ... &sk=t&sd=a

Martin