AW: [Allegro] Indexparameter zum dritten

[Fischer, Thomas]

Hallo Herr Berger,

> 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

Ich habe bei mir
Ps=20000
stehen, das sollte eigentlich reichen.
Ps=100000
hat auch keine Besserung gebracht.

> > 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)

Das wäre seltsam, weil die P/Q-Umkodierung ja explizit für die Indexierung vorgesehen ist (siehe iu.apt), und da sollen ja vielleicht durchweg Groß- in Kleinbuchstaben und UTF-8 in ASCII umgesetzt werden.
Jedenfalls sind beide in iu.apt enthalten.
Oder meines Sie das nur auf das einzelne Zeichen bzw. die Zeichenkombination bezogen?

> > 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.

Aus
Über die Bevölkerung Siebenbürgens
macht #u1 y2
Über die bevölkerung siebenbürgens.
Das kommt mir eindeutig vor, und heißt, dass
P 195 156 220
und nicht
Q 195 156 252
benutzt wird.

> 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.

Bei mir ist das aus dem Versuch entstanden, einen Eintrag umzukodieren und dann seine Bestandteile in die entsprechenden Register zu schreiben, in diesem Fall die einzelnen Wörter des Titels und der Beschreibung. Da kommt man um Variablen nicht herum. Meiner Meinung nach sollte die Umkodierung idempotent sein, so dass etwaige zusätzliche Umkodierungen keinen Schaden anrichten.

> > 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.


> 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).

Das kommt mir unnötig aufwändig vor.
Ich habe ca. 1000 UTF-8-Zeichen in meiner Tabelle und müsste für diese dann die entsprechenden Entitäten bereitstellen. Nehme ich die Braunschweiger Vorlagen, habe ich Angst, dass ich wieder mit OSTWEST-Zeichen infiziert werde...

Zum Beispiel wird
Ó szelence - Magyar barokk költészet
in UTF-8:
Ó szelence - Magyar barokk költészet
mittels
#u1 y2 dsu asu
#usu y2
in
o szelence - magyar barokk költeszet
umgewandelt. Hier steht allerdings nach der ersten Umwandlung auch noch
O szelence - magyar barokk költeszet
es wird also wiederum mit P statt Q umcodiert.
(Das ist mir bei zunächst bei meinen Umlauten aufgefallen, weil andere Zeichen mittels des zusätzlichen y2 in Kleinbuchstaben gewandelt werden.)

Herr Eversberg muss also mal der P/Q-Konvertierung bei #uxy, !uxy, y1 und y2 nachgehen.
Ziel wäre m.E. ein Verhalten wie bei p/q: Es gilt immer die letzte Definition, und p/P bei #uxy und y1 und q/Q bei !uxy und y2.
Außerdem muss klar sein, dass p/q und P/Q gleichzeitig angewandt werden, also beide auf den aktuelle Arbeitstext (wie es jetzt schon der Fall ist). Was passiert, wenn das Ergebnis eine P-Umkodierung wieder von p umgewandelt werden könnte, sollte beschrieben werden.

Mit freundlichen Grüßen
Thomas Fischer