Unicode Methode 2: UTF-8 intern

[Thomas Berger]

Lieber Herr Eversberg,

> Methode 2, jetzt schon im Entwurfsstadium, geht davon aus, dass
> eine Datenbank intern auf UTF-8 umgestellt wird.
> Vorteile:
>   -- der volle Unicode wird verfuegbar
>   -- Exporte in XML-Umgebungen werden sehr einfach
>   -- alle Sonderzeichen brauchen nur je 2 oder 3 Byte
> Nachteile:
>   -- auch die deutschen Sonderbuchstaben muessen als 2-Byte-Codes
>      verschluesselt werden

kennen MAB und MARC auch nicht anders.


>   -- DOS-Programme nur noch eingeschraenkt nutzbar
>   -- Eingabe und Bearbeiten ALLER Sonderzeichen
>      auch in a99 unkomfortabel. Anzeige und Indexierung korrekt.
>      Nur mit Web-Formular (RuckZuck-avanti) könnte man ohne Probleme
>      editieren.

Wenn Win'9x nicht waere. Denn unter NT, 2000 und XP muesste
es die entsprechenden Eingabe und Listenfelder auch Unicode-
Faehig geben.
Genauere Betrachtung des Anzeigefelds ergibt uebrigens,
dass man nicht unbedingt Font-Umschaltungen benoetigt, sondern
unter XP etwa auch direkt die "Unicodes" eines Zeichens in
RTF-Konvention (die ist furchtbar, aber dafuer gibt es ja
Computer) anzeigen kann. Unter Win'98 fand ich interessant,
dass Wordpad auf dieser Plattform ebenfalls RTF-Unicode 
anzeigen kann, das a99-Anzeigefenster jedoch nicht.

 
> Methode 2 erfordert einen Mechanismus fuer den Export, der aus
> UTF-8-Codes, also 2- oder 3-Byte-Kombinationen, etwas anderes
> zu machen gestattet. Bisher erlaubte die Exportsprache nur das
> Ersetzen einzelner Zeichen durch (ein oder mehrere) andere:
> die p- und q-Befehle.
> Es muss also eine Moeglichkeit geben, in der Exportsprache zu
> sagen, welche 2- bzw. 3-Byte-Kombinationen ersetzt werden sollen
> und durch was. (Kein ganz neues Desiderat.)

Stimmt. Und die Importsprache hat es in Ansaetzen seit
immer schon realisiert.


> Die neuen u-Befehle von Methode 1 haben einen etwas anderen
> Zweck: sie wandeln eine UTF-8-Eingabe um in OstWest-Codes.
> Diese Funktion kann aber erweitert werden: Die Syntax ist
> fast dieselbe, nur mit P oder Q statt u. Solche Befehle, eingebettet
> in Export- oder Indexparameter, wirken sich dann aus an
> derselben Stelle, wo bisher nur die p- und q-Befehle wirken.
> WENN P/Q-Befehle vorkommen, dann wirken sich p- und q-Befehle
> nur noch auf Codes unterhalb 128 aus, denn Werte oberhalb
> 127 gelten dann als UTF-8 und duerfen nicht als einzelne
> Bytes behandelt werden, sie muessen immer zu zweit oder
> dritt umcodiert werden.
> Z.B. koennte in Export-Parametern stehen:
> P 208 143 65         kyr. A
> P 208 144 B          kyr. B
> P 226 130 172 "EUR"    Euro-Symbol
> Man sieht hier drei verschiedene Moeglichkeiten.
> 
> Die noetigen Listen (Dezimalcodes!) koennten mit unserem UTF-8-JavaScript-
> Prograemmchen schnell erstellt werden.

Das ist ja auch ein Desiderat: Der Offizielle Code ist entweder
dezimal oder vorzugsweise die vierstellige Hex-Ziffer fuer das
Zeichen. So enthalten in allen offiziellen Tabellen. Dass man
fuer die Nutzung in Allegro mit einem scheinbar obskuren
Online-Prograemmchen die definitiv unuebliche UTF8-Notation ausrechnen
muss und diese dann in den Parameterdateien eintragen, macht die
Sache unnoetig kryptisch und erschwert die Akzeptanz.

Im Licht des von Ihnen eben beschriebenen sehe ich nicht so
recht, wo die Einschraenkung in der Nutzung der DOS-Programme
liegen soll: Doch eigentlich nur darin, dass diejenigen Zeichen,
die ueber OSTWEST hinausgehen, ueber einen geeignet zu definierenden
Mechanismus (ewa: Eingabe des vierstelligen Hexadezimal-Unicodes :-)
etwas umstaendlich eingegeben werden muessen und die Anzeige nur
die in Ostwest enthaltenen Diakritika isoliert darstellen und *alles*
andere auf lateinische Grundbuchstaben reduzieren wird, also 
sogar mehr als bislang.

viele Gruesse
Thomas Berger