Adriaan van Os wrote:
egbert@seibertz.de wrote:
Moin Pascaller,
im Rahmen von systemweiten Zeichensatzumstellungen (von latin1 auf utf8) funktionieren nun erwartungsgemäß einige Pascalprogramme nicht mehr. Teilweise weil Dateinamen nicht mehr verstanden werden und teilweise weil Eingaben nicht mehr verstanden werden. Oder die Nutzer die Ausgaben nur noch erraten können ...
Sehr ärgerlich an utf8 ist, daß durch die variable Zeichenlänge der Programmieraufwand für die Erkennung überproportional ansteigt. Möglicher Weise wäre utf16 (USC2) deutlich einfacher im Aufwand ...
Nach meiner Meinung ist UTF-16 wohl die slechteste Wahl, weil auch UTF-16 eine Kodierung ist mit variabeler Länge (http://en.wikipedia.org/wiki/Utf-16), obwohl Sie oft nicht als Solches behandelt wird, was dann wiederum zu Fehlern führt !
Das stimmt, also dann besser gleich UTF-32, das ist wirklich eine 1:1-Codierung, und entspricht auch "wchar_t" (wide char) in C/C++.
egbert@seibertz.de schrieb:
Nun zur den Fragen:
A hat jemand vielleicht schon eine (gut funktionierende) Codeumsetzung von zB utf8 nach latin1 (und umgekehrt) (besser (zukunftsicherer) wäre nach utf16 oder utf32) geschrieben die man allen (!) Aus- und Eingabeoperationen voransetzen kann (also nicht eine Funktion, die bei jedem Schreiben oder Lesen im Programm explizit aufgerufen werden muß)? Gff: Wie aktiviert man das?
Ich habe nichts in fertiger Form. Mein Ansatz wäre:
- UTF-8 <-> UTF-32, also die Codierung der Zeichensequenzen (reine Rechnerei, unabhängig von der Bedeutung der Zeichen)
- UTF-32 <-> Latin1 ist dann trivial, da Latin1 per Definition eine Teilmenge (0 .. 255) von UTF-32 ist, d.h. man muss nur überlegen, was man mit höheren Zeichen macht (wegwerfen, Fehler oder teilweise umsetzen). Interessant könnte auch Latin9 sein, das sich von Latin1 nur in ein paar Zeichen (v.a. Euro-Zeichen) unterscheidet. Diese muss man dann allerdings von Hand umsetzen (z.B. Euro: $20ac in Unicode, $a4 in Latin9).
Das beides würde ich als eigenständige Funktionen schreiben, die man immer mal wieder brauchen kann.
- Um die Funktionen automatisch in Ein-/Ausgabe einzubinden, gibt es jedenfalls für Textdateien eine GPC-spezifische Lösung, nämlich AssignTFDD ("Text File Device Driver"). Das ist etwas low-level, man muss mit Funktionszeigern und Buffern hantieren. Als Beispiel s. z.B. AssignDos in dosunix.pas (das ist für automatische CR/LF-Umwandlungen zwischen Dos- und Unix-Textdateien). Prinzipiell könnte man so auch UTF-Umwandlung implementieren.
B gibt es eine einfache Möglichkeit dem GPC zu sagen, daß strings nun nicht mehr aus Feldern von char zu 8bit, sondern aus char zu 16bit bestehen? Wobei ich nicht alles händisch umschreiben möchte (Das Problem betrifft eben sehr viele Programme, die mit deutschsprachigen Wörtern umgehen können müssen ...).
Zurzeit leider nicht, alle String-Operationen sind fest auf 8-Bit-"Char" eingestellt.
Im Zuge von größeren Änderungen in GPC könnte man das irgendwann unterstützen, aber nicht auf die Schnelle.
Ich habe mir in letzter Zeit ein paar Gedanken über mögliche größere GPC-Änderungen in der Zukunft gemacht (die weit über Unicode hinausgehen), und werde vermutlich in ein paar Wochen in der englischen Liste etwas dazu schreiben. Aber wie gesagt, für eine kurzfristige Lösung ist das nicht interessant.
Frank