[Allegro] Umlaute bei RuckZuck-Recherche

[Bernhard Eversberg]

Klaus Lehmann schrieb:
> 
> kl>Das ist natürlich auch schwer, aber es ist im Standardpaket gelöst.
> kl>Voraussetzung in den eigenen Parametern ist, daß man in die Index-
> kl>Parameterdatei die Tabelle  ucodes.apt eingebunden hat, also
> kl>tucodes
> kl>am Ende angefügt.
> 
> hm...., wie sieht das praktisch bitte aus?
Es wird eine Zeile

tucodes     ucodes.apt laden

am Ende angefügt.

> in der cat.api, die dem aktuellen avanti2.2.9-paket für windows
> beiliegt, ist
> soetwas nicht eingebaut. keine u-zeilen am ende, und kein einbau der
> (t)ucodes.apt. diese cat.api ist vom 6.1.2006 (ca 88kb schwer)
Nehmen Sie diejenige der DemoBank des Gesamtpakets (112kb schwer), da
ist die Tabelle schon mit drin. Es sind die Zeilen, die mit u anfangen.

> 
> auuserdem verstehe ich nicht, wie das überhaupt funktionieren soll:
> die indexeinträge sind doch von natur aus IM index (also adx) in
> aufgelösten kleinen ascii-werten geschrieben. auch wenn es mir gelänge,
> eine tastatureingabe abzufangen (mit tucodes) also umzuwandeln, IM
> index würde diese eingabe auf keinen umlaut stossen. ich müsste doch
> ERSTMAL den index (=adx-datei) so umschreiben, daß umlaute drin
> vorkommen. (oder doch völlig ver(w)irrt???)
> 
Es ist schon sehr lange so, daß im Index was anderes stehen kann als was
man eingibt - Grossbuchstaben z.B. Die Eingabe wird umgewandelt, und
zwar für Reg. 1 an der Sprungmarke #-1 usw. um dann genau das finden
zu koennen, was im Register tatsaechlich steht, also mueller statt
des eingegebenen Müller. Das ist nichts neues. NEU ist beim
Web-Interface, daß die Eingabe automatisch in UTF-8 codiert ist,
was man allerdings von außen nicht sieht, da sieht man "Müller".
Damit muß also was geschehen, damit ein korrekter Zugriff möglich wird.

Ein ü hat dann intern 2 Bytes und kommt so bei avanti an. avanti
sortiert die Nutzereingabe (darin die ominoesen 2 Bytes!) in das Feld
#u2 ein. Genau an der Stelle wirken die u-Befehle und machen aus den
ominoesen 2 Byte das ASCII-Byte fuer ü, und zwar macht das genau
diese Zeile:
u 195 188 129        LATIN SMALL LETTER U WITH DIAERESIS

195 188 sind die ominoesen 2 Bytes, die vom Client kommen, und
129 ist das ASCII-ü. Danach steht also in #u2 genau das,
was intern ankäme, wenn man Müller bei a99 eingegeben hätte, also
Müller mit einem ASCII-ü.
[das mit dem #u2 ist z.B. zu sehen in av_page.php ]
Mit dem nun ASCII-Inhalt von #u2 macht dann avanti den Zugriff
zum Register. Dabei wird, wie immer in solchen Fällen, die
ASCII-Zeichenfolge dann an der genannten Sprungmarke umgewandelt
(sie erscheint dort als #u1), und dabei entsteht anhand der p/q-Befehle,
die in der cat.api stehen, das "ue". Und genau das steht im Index und
wird dann gefunden.

Die Komplikation mit den u-Befehlen mußte eingeführt werden, weil
an der internen Codierung der Daten nichts geändert werden konnte,
denn die Datenbank soll absolut unverändert von allen Plattformen
aus benutzt werden können. Es gibt also beim Web-Interface ZWEI
Umwandlungen hintereinander:

Eingabe -> u-Befehle -> #u2 -> #u1 -> p/q-Befehle -> korrekte Registerform.
(Der Schritt #u2 -> #u2 passiert intern, dafür muß man nichts tun.
Bei jedem find- oder qrix-Befehl wird die Eingabe in #u1 getan und
dann zur Sprungmarke gegangen.)

B.E.