Unicode-Unterstuetzung i.Vb.
Thomas Berger
ThB at gymel.com
Mi Jan 15 11:50:00 CET 2003
Lieber Herr Eversberg, liebe Liste,
> > UTF-7 ist folgendes:
> > http://www.landfield.com/rfcs/rfc2152.html
> > Was Sie meinen ist "ASCII-Text mit Unicode-Entitaeten" (keine Ahnung,
> > ob es einen offiziellen Namen dafuer gibt),
>
> Korrekt, aber wir sagen einfach mal UTF-7 und meinen damit in unserem Kontext
> ausschliesslich "Entitaeten" der Form &#N; mit einer Dezimalzahl N. Wir wollen
> nicht die unter "UTF-7" insgesamt zulaessigen Dinge alle ausschoepfen, das ist in
> unserem Kontext einfach unnoetig.
Kein Kommentar (wobei ich hier nicht Kommentar meine, sondern
in diesem Kontext etwas anderes, unaussprechliches :-)
Jedenfalls ist UTF-7 nicht etwas ueber &#N; herausgehendes,
sondern etwas fundamental anderes:
>>>
Example. The Unicode sequence "A<NOT IDENTICAL TO><ALPHA>."
(hexadecimal 0041,2262,0391,002E) may be encoded as follows:
A+ImIDkQ.
<<<
> > > ... wird es ein Export-Unterprogramm geben, das die Diakritika mit den
> > > nachfolgenden Zeichen vertauscht bzw. umgekehrt. (Zu beachten ist dabei, dass
> > > auch zwei oder mehr Diakritika aufeinander folgen koennen...)
> >
> > Auf jeden auszugebenden Text anwenden:
> >
> > #nr dCx dcX Z
> > ...
> Man staunt immer mal wieder, was unsere Exportsprache alles kann...
> Solche trickreichen, nur fuer Fortgeschrittene durchschaubaren Abhilfen, deren
> Einbau in vorhandene Parameter vergleichsweise sehr aufwendig ist, sollen aber
> durch ein relativ simples Unterprogramm unnoetig gemacht werden!
Meinen Sie mit Unterprogramm etwas parametriertes
#(X
...
#)X
oder etwas festverdrahtetes wie bei IMPORT?
> > > Mit V23.0 wird es dann schon P-UTF7.APT und P-UTF8.apt geben sowie das besagte
> > > Export-Unterprogramm, damit man bequem Exporte herstellen kann, vor allem
> > > solche, die fuer Web-Angebote einsetzbar sind. Denn Browser koennen UTF-7 und
> > > UTF-8 darstellen.
> >
> > Ich habe eine .cpt-Datei, die beides kann: Wird SRCH mit -UTF8
> > aufgerufen,
> > so wird UTF-8 erzeugt, sonst ASCII mit &#nnn;-Entitaeten :-)
> >
> Sehr schoen, fuer den Normalverbraucher wollen wir aber 2 Tabellen, die
> ohne weitere Handgriffe und Kenntnisse eingesetzt werden koennen.
Sie werden merken, dass mit "Tabellen" beim Export nach UTF-8
fast ueberall der Phrasenspeicher ueberlaufen wird, zumindest
wenn Sie versuchen, die Zeichen zu kombinieren, die in
OSTWEST nicht kombiniert vorhanden sind.
> > Mittelfristig, so finde ich, sollte man auch im Hinblick auf Importe
> > eine Unicode-Unterstuetzung einbauen: Anwendungen koennten dann mittels
> > einer hypothetischen u-Tabelle das Mapping zwischen dem benutzten
> > Zeichensatz und Unicode deklarieren, die allegro-Module machen dann
> > den Rest...
> >
> Derartiges wird noch durchdacht werden muessen, soweit sind wir noch nicht.
> In Fremddaten der Zukunft wird womoeglich eine bunte Vielfalt der diversen
> Unicode-Realisierungen vorzufinden sein...
Fremddaten der Zukunft werden viel mit XML zu tun haben, d.h.
es werden nur UTF-8 und ISO 8859-1 relevant sein, jeder XML-
Parser kann nach UTF-8 umwandeln (weil UTF-8 die einzige
Zeichencodierung ist, die lt. Standard zwingend(!) beherrscht
werden muss).
viele Gruesse
Thomas Berger
Mehr Informationen über die Mailingliste Allegro