AW: AW: [Allegro] Avanti: Konvertierungen

[Thomas Fischer]

Lieber Herr Eversberg,

ich habe die Umkodierung immer noch nicht im Griff.

Zunächst noch einmal ein Versuch der Zustandsbeschreibung:

Ich habe in meinem Index (in Register FIN 2 "Search") stehen:
103   l├╝cke
(Das ist das, was aus "Lücke" geworden ist.)

Ich frage bei Avanti an:
&
find STP>2
find (FIN l├╝cke )
list internal
write n
@ DB=jfm ID=opac/OPAC
AVANTI:EOJ

und bekomme:

N:<E130> kein Ergebnis bei: ( FIN l├╝cke )

(Entsprechend für
find (|2 lücke )
)
Ich kann mir das nur so erklären, dass irgendwo eine Umkodierung stattfindet.
Die Umkodierung für die Register (hier: #-2) habe ich in der Indexparameterdatei deaktiviert.
Die Nummern der Zeichen sind übrigens 195 und 188, falls das eine Bedeutung hat.
Da hier gar keine Skripte vorkommen und keine Datenfelder ausgegeben werden, kann die von Ihnen beschriebene Umkodierung damit nichts zu tun haben.


Nun zu Ihrem Brief:

> Wir haben ebenfalls UTF-8, aber es funktioniert.
Aber nicht im Index, soweit ich sehe.
 
> Der Vorgang ist dieser:
> 1. Man tippt  xyz  ein, das ist UTF-8 und wird so an den Server
>     gesendet, ohne Änderung.

Ich denke, dass man normalerweise nicht UTF-8 eintippt, sondern (z.B. vom Browser) das Eingetippte in UTF-8 konvertiert wird.

> 2. Skript (z.B. rset.php) nimmt xyz und steckt es in #u1. Dabei werden
>     die UTF-8-Codes durch die u-Tabelle gejagt und es wird der intern
>     verwendete Code draus gemacht. Normalerweise ASCII, aber wenn man
>     intern UTF-8 hat, darf hier eben nichts verwandelt werden.
>     Die u-Tabelle wird aber nur aktiv, wenn vor dem  ins #u1  im
>     Skript steht:  set U1  und danach  set U0

Wie gesagt: bei mir sind kein Skript, kein U1 und soweit ich sehe auch keine u-Tabelle in Sicht. Oder könnte die noch irgendwo stecken?
Allerdings würde es mich wundern, wenn rset.php eine u-Tabelle einsetzt: Das PHP-System weiß doch gar nichts von der Datenbank außer dem Namen, den es an Avanti weitergibt, oder?
Wenn ich das recht verstanden haben, ruft rset.php grec(i) (in rset.php) auf, dieses dann grec.php, dieses dann av_grec.php. Dort wird ein Avanti-Jobtext vorbereitet, der schließlich in sendjob von av_ini.php aufbereitet und an Avanti geschickt wird, das Ergebnis wird dann zurückgegeben. (Muss das so kompliziert sein?) Jedenfalls ist die Darstellung "steckt es in #u1" etwas verkürzt.
Ich kann mir nur vorstellen, dass von Avanti ein Umkodierung stattfindet, schließlich wird der Befehl U1 ja auch dorthin gesandt.
 
> 3. Der avanti-Zugriffsbefehl arbeitet dann mit dem Code, der
>     in der Datenbank vewendet ist! Dieser wird dann noch den p- bzw.
>     q-Codes unterworfen, als hätte man denselben Befehl bei a99
>     von Hand eingetippt.

Wo kommt die p/q-Umkodierung her? Ich meinen Indexparametern habe ich keine p/q-Befehle aktiviert. Ich glaube, an dieser Stelle muss noch etwas anderes passieren, s.o. Greifen noch irgendwelche anderen Tabellen ein (z.B. s1)?

 
> > Ich habe Порты in den Titelwörtern gesucht und nichts gefunden, 
> Wenn ich das auf der Startseite
> eingebe, kommt:
> 
> porty
> posobie (6)
> ...

> Denn die Indexeintraege sind mit Hilfe von P- und Q-Befehlen
> transliteriert. (nicht p und q, denn es handelt sich ja um
> Sequenzen, die da ersetzt werden müssen! Das war ja eine andere
> der Neuerungen, die fuer UNICODE nötig wurden.)

Wie gesagt, ich transliteriere derzeit gar nicht. Ich möchte
Порты
eingeben und 

Порты
posobie (6)

finden.

Mit freundlichen Grüßen
Thomas Fischer