[Allegro] Indexparameter zum dritten

[Thomas Berger]

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



Am 22.09.2010 16:42, schrieb Fischer, Thomas:
> Lieber KollegInnen,
> 
> ich habe eine Datenbank mit interner UTF-8-Kodierung und Probleme mit der
> für die Indexierung gewünschten Umcodierung: irgend etwas ist mit der (meiner?)
> P/Q-Umcodierung faul.

> Bei
> #u1 p'|1' P{8}
> wird der erste P- oder Q-Befehl für die gefundene UTF-8-Zeichenkombination in
> meiner Tabelle genommen, egal ob es P oder Q ist.

das ist gewiss nicht sinnvoll. Liegt das evtl. an zu klein dimensioniertem
Speicher, vgl. die Anweisung

Ps=N

> Ein zusätzliches y2 erzwingt die Anwendung der q-Befehle, scheint auf P/Q
> aber keine Auswirkungen zu haben.

codier.rtf sagt:
"Die P/Q-Befehle haben Priorität vor den p/q-Befehlen, d.h. sie werden beim
Abarbeiten einer Exportzeile zuerst ausgeführt."

unicode.rtf praezisiert:
"Wenn kein P/Q-Befehl greift, treten die p/q-Befehle in Kraft."

Ich schliesse daraus: Entweder P/Q oder p/q wird ausgefuehrt, nicht beides
hintereinander. (Unter der Annahme, dass in einer .cPI die Umcodierung
nicht anders als in einer .cPR-Datei geregelt ist)


> Ebenso wendet
> #u1 y2 =su
> die q-Tabelle und wohl den ersten passenden P/Q-Treffer an.

das "und" duerfte tendenziell nicht stimmen. Generell bewirkt aber
y2 eine explizite "Q/q" oder "q"-Umcodierung, die implizite p-Umcodierung
durch die "#" am Anfang der Anweisung bleibt unberuecksichtigt: Der
durch y2 entstehende Arbeitstext wird nicht noch einmal umcodiert.

Das Handbuch bezieht sich im Kapitel 10.2.6 zum y-Manipulationsbefehl
nur auf die p/q-Tabelle, es ist also unklar, ob die P/Q-Tabelle
Anwendung finden sollte (der Manipulationsbefehl y4 ist in ac.

Zumindest frueher war es so, dass die y-Befehle nur bestimmte Elemente
der p/q-Tabelle beruecksichtigten, naemlich die "direkten Ersetzungen",
die sogenannten "Drucker-Ersatzdarstellungen" wurden nur durch die
impliziten Umcodierungen ausgefuehrt. Das ist vor ein paar Jahren hier
diskutiert worden, ich weiss leider nicht mehr, ob das Verhalten
anschliessend veraendert wurde.

Generell ist der Versuch, einen mit P/Q-Tabelle bearbeiteten Text
in einer Anwendervariablen zwischenzuspeichern, problematisch: Man
beginnt dann ja mit auf unterschiedliche Arten codierten Texten
(UTF-8 in den Kategorien, Ascii-artiges in dieser Anwendervariablen)
zu jonglieren, das kann ziemlich unuebersichtlich werden.

Umgekehrt ist es auch in Indexparametern wichtig, etwa fuer Nachladungen
oder in Abschnitten zur Umcodierung der Benutzereingabe ausgehend von
im Zeichensatz der Datenbank vorliegenden Texten eine Umcodierung
so vorzunehmen, dass man exakt das, was auch im Register steht, in
einer Anwendervariablen hat. Vgl. etwa den Hinweis in HB 10.2.6.7:

"ACHTUNG: Vor dem Befehl  |im  muß man mit y1 oder y2 eine Umcodierung
erzwingen (per p- bzw. q-Tabelle, meistens zur Wandlung von groß in klein),
denn automatisch passiert sie in  diesem Fall nicht, d.h. das # oder ! am
Zeilenanfang hat nicht die gewünschte Wirkung. "

Weil es ja noetig ist, das beschriebene Verhalten "vorzugsweise P/Q, sonst
p/q" zu emulieren, wuerden weitere y-Varianten, die gezielt nur P/Q-
Ersetzungen durchfuehren, nicht unbedingt helfen, d.h. vermutlich sollten
also y1 und y2 erweitert (repariert?) werden und die Dokumentation angepasst.


> Bei
> !u1 p'|1' P{8}
> findet nur die q-Konvertierung statt, weder P- noch Q-Tabelle wird angewandt,

merkwuerdig.


> !u1 y1
> scheint jede q- und P/Q-Umcodierung zu deaktivieren.


> Zwischen
> #usu y2 =su
> und
> !usu y2 =su
> konnte ich keinen Unterschied feststellen.

Das war zu erwarten.


Zielfuehrender als die P/Q-Tabellen scheint mir uebrigens folgender "Umweg"
zu sein: Global mittels
#u&# ;
#dU
die UTF-8-Codes im Datensatz durch &#nnn;-Entitaeten ersetzen, und diese dann
mit V23-Methodik ("Sequenzen ohne Grenzen") ganz gezielt ersetzen lassen
(mit #dV oder ueber kontextabhaengiges Belegen des Parameters ia).

viele Gruesse
Thomas Berger



:
Das hat zumindest vor einigen Jahren schon funktioniert und ermoeglicht
mittels der entsprechenden Umschaltmechanismen (
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAkyaJJQACgkQYhMlmJ6W47ON4AP+J+w+Q4xmxnGLSnxCep/lQ36m
/mv4zSlqGGuRrXKo2ylAvRGGc9PUc5B/iif7KyHv5uQcnOa+ALwVQCyqs9CVvt1w
3IKF2qLFvrAty9orAtbORSaa8m8BEBebJrEhGAdss/+T9ykdDAQB95a4CR9epHUa
Q/KQ2kzP2OUv56ngCtI=
=7zro
-----END PGP SIGNATURE-----