[Allegro] Gibt es DEN ULTIMATIVEN UTF-8-Font??

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

> Das Microsoft-Entwicklungssystem VisualC++ kann zwar Unicode, aber nur
> in der 2Byte-Variante. Jedes Zeichen hat dann intern 2 Byte, auch
> die unteren ASCII-Zeichen. Notgedrungen müßte man unter dieser Option
> dann auch 2 Byte je Zeichen speichern. Schlimmer noch, die String-

Es ist bekannt, dass /Windows/ seit 1996 Unicode so umsetzt, dass die UCS-2-
Repraesentation genommen wird (evtl. auch UTF-16, soo genau weiss ich das
nicht). Aber selbst Notepad unter NT 4.0 konnte bereits beide Unicode-
Repraesentationen lesen und schreiben.

Es duerfte Systemfunktionen geben, die Daten in bekannter Codierung
aus Datei(buffer)n in die interne String-Repraesentation einlesen
und umgekehrt wegschreiben. Die reichen aber moeglicherweise nicht
aus, weil Alt-Datenbanken und Parameterdateien traditionell Zeichen
benutzen, die jenseits der in Windows-Systemen jemals genutzten
Zeichencodierungen realisiert sind (Ostwest, PICA, CP 437).


> Funktionen wie z.B. strcpy(), strcmp() usw. usf. müssen dann alle
> in der "wide character"-Version verwendet werden, d.h. überall
> müßte man statt dessen  wstrcpy() bzw. wstrcmp() schreiben.

Sie meinen wcscpy() bzw. wcscmp()?

> Die Masse der dadurch erzwungenen Änderungen ist leider prohibitiv,

... aber sowieso faellig: Wenn es schon keinen eigenen Datentyp
fuer "Nutzdaten" gibt, dann sollte man die Operationen an diesen
zumindest durch Makros herausarbeiten. Die koennen dann irgendwann
ausgetauscht werden.

Das interne Abbilden ist ja nur ein erster Schritt, allenthalben
werden die verglichen, regular expressions unterworfen, normalisiert,
sortiert, zur Anzeige gebracht etc. und bei einer derart textlastigen
Anwendung wie es die bibliothekarischen Daten einmal sind, muss
man entweder die diesbezueglichen Funktionen des jeweiligen Betriebssystems
als Grundlage nutzen (aber mit selbstimplementierter "RAK"-collation) oder
die komplette Funktionalitaet von Null an neu entwickeln, also quasi ein
UTF-8 nutzendes Gegen-Windows aufbauen...


> und auch die Daten selbst wären betroffen, alte Datenbanken
> würden's nicht mehr tun mit einer Unicode-Version. Beim Index ginge es

sie muessten immerhin sagen, wie sie codiert sind. D.h. der
Anwender muesste einmal diese Aussage zu seiner Datenbank machen
und schauen, was herauskommt.

viele Gruesse
Thomas Berger