[Allegro] Unicode im Schreibfeld?

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Liebe Frau Genest, liebe Liste,

> Heißt das, ich könnte z.B. eingeben "Walęsa, Lech" oder wie sähe
> die angesprochene Unicode-Eingabe aus? Was passiert damit im Index?

Verlautbarung 164 beschreibt zwei "Verfahren" fuer den Umgang mit
Unicode:

"Verfahren 2" ist eine Datenbank, die auch intern die Daten als
Unicode (genauer: UTF-8-codiert) speichert. Nachteil dieser
Methode ist, dass weder PRESTO (klarerweise) noch a99
(angekuendigterweise) *jemals* Dateneingabe erlauben werden.
Zur Unterstuetzung dieses Verfahrens wurden die P- und Q-
Tabellen eingefuehrt, sowie der Modus "U2" fuer das Einlesen
von UTF-8-codierten Daten mithilfe der neuen u-Tabelle.
Vorhandene Daten muessen klarerweise nach UTF-8 umgewandelt
werden, damit diese Methode eingesetzt werden kann.

"Verfahren 1" hingegen bedeutet, dass Zeichen "jenseits" des
Grundzeichensatzes als Entitaeten codiert werden. Ziemlich
analog zur Texel-Technik (VB 163) wurden hierfuer die VS-Sequenzen
eingefuehrt, sowie der Modus "U1" fuer das Einlesen von
UTF-8-codierten Daten mithilfe der neuen u-Tabelle.
In vorhandenen Daten muss eigentlich nur das "&" durch "&"
ersetzt werden, damit "&" freigeraeumt ist fuer die VS-Methode
(die VS-Methode ist maechtig, aus beliebigen Texten mit
frei waehlbaren Praefixen kann irgendetwas gemacht werden,
tendenziell sogar mehrstufig, die Unicode-Umwandlung mit U1
erzeugt allerdings fest "&" und Unicode-Codenummern)

In vorhandenen Parametern sind weiterhin die Zeichen des
Grundzeichensatzes so wie frueher zu behandeln, speziell
fuer HTML-und XML-Exporte ist zu beachten, dass "&" nicht mehr
escaped werden darf ("<" muss weiterhin).

Fuer uneingeschraenktes Cut&Paste ist man auch bei Verfahren 2 auf
"externes Editieren" angewiesen, das ist ohne die "Unicode-Verfahren"
allerdings auch nicht anders, ausser man nutzt CP1252 als
Windows-Codepage unter allegro (und eine solche Anwendung ist
zumindest mir nicht bekannt). Beim Cut&Paste vom Anzeigefenster ins
Schreibfeld muss man sich entscheiden: Soll das Anzeigefenster alle
Zeichen zeigen, dann verhaelt es sich wie ein "normales" Window,
Cut&Paste ins Schreibfeld geht also wegen Codierungsproblemen nur
eingeschraenkt. Schraenkt man die Anzeige so ein, dass es nicht
mehr zeigen kann als ohne Unicode-Verfahren, dann funktioniert Cut
& Paste wie bisher.

Ein Migrationspfad zu einer echten Unicode-Datenbank [Hoppla: Die
muesste auch etwas uber Collation sequences und Normalization wissen,
also: eine Datenbank, in der UTF-8 gespeichert ist] koennte so
aussehen:
1. Datenumwandlung "&" -> "&", Ergaenzen der Datenbank um VS-
   Sequenzen, Umarbeiten der Parameterdateien auf Unicode-Verfahren 1
   Beibehalten von OSTWEST als Grundzeichensatz.
   [Dieser Schritt ist ziemlich schmerzlos: Nach der eigentlichen
   Datenumwandlung kann man peu a peu alle Exporte ausprobieren und
   schematisch die zwei oder drei zusaetzlich erforderlichen Zeilen
   #dV, ia=, p & 9 eintragen.]

2. Umwandlung der Daten in einen vom Betriebssystem unterstuetzten
   Zeichensatz, etwa CP850 oder CP1252 (oder 7bit plus HTML-Entitaeten)
   Austausch (CP850) oder Verwerfen der meisten (CP1252) Codiertabellen.
   In a99 nun Arbeit mit Standard-M$-Fonts.
   [Hauptproblem hierbei: Die Standardparameter betreiben an derzeit
   19 Stellen eine Font-Umschaltung, sind also mit der konkreten
   (allegro-Font)-Belegung von disphead.rtf etc. verzahnt.]


3. Umwandeln der Daten in UTF-8
   Nutzung von P- und Q-Tabellen in den Parametern (diese koennen
   aus den VS-Sequenzen vermutlich generiert werden)
   [Hauptproblem nun: Eingabe ist nur ueber Web-Anwendungen moeglich,
   Scripte fuer eine ueberzeugende Normdatenverknuepfung in diesem
   Kontext sind mir nicht bekannt]

In meiner Mail von vorgestern hatte ich eine Zusammenfassung von
Schritt 1 und 2 beschrieben, denn in der fraglichen Datenbank waren
*alle* nicht ueber die Tastatur eingebbaren Zeichen nach einem
privaten System codiert und mussten umgewandelt werden. Insofern
konnte ich "beschliessen", dass der Grundzeichensatz CP850 und nicht
allegro-OSTWEST sei.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGe56WhKFJT0F1FsoRAmj5AJ4zkqF/hKHyTgq+Od7/bBmIKO3U+gCfUo5y
s3dP0eDUAHUPtxNZM6dzfyU=
=zQsv
-----END PGP SIGNATURE-----