[Allegro] Zeichenkodierung bei Avanti

[Thomas Berger]

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

Lieber Herr Fischer, liebe Liste,

> ich hab mal wieder Probleme mit der Zeichenkodierung.
> Mein Z39.50-Target soll möglichst in die Lage versetzt werden, Anfragen in UTF-8 zu verarbeiten. Da die Anfragen gegen die Register laufen, in denen sowieso nur Zeichen aus dem unteren ASCII-Bereich stehen, sollte das möglich sein, mir ist nur die Umkodierung nicht ganz klar:

Ich bin mir nicht sicher, ob das geht. Allerdings habe ich in der
Spezifikation von Z39.50 nie herausfinden koennen, was die
Zeichencodierung der Anfragen eigentlich ist...


> 1. Wird von dem Z39.50-Target eine Tabelle eingesetzt, um Zeichen umzukodieren?

m.W. nicht.




Ab jetzt kann ich dazu etwas sagen:

> 2. Wird von Avanti eine Tabelle eingesetzt?

von avanti m.W. gar nichts, von acon die invertierte o-Tabelle
(das ist einer der Unterschiede zwischen Flex und Job), es sei
denn, sie wird mit switch coding deaktiviert. Oder man sendet
UTF-8.


> 3. Wird bei der Anfrage an die Datenbank die Anfrage in jedem Fall per o-Tabelle
>    umkodiert, oder nur, wenn diese explizit in der Indexparameterdatei eingebunden ist?

Keine Ahnung. Frueher einmal(?) gab es auch heuristiken, o-Tabellen wurden
so lange gesucht, bis "ue" nicht auf sich selbst abgebildet wurde.


> 4. An der Stelle #-n (n Nummer des Registers) kann eine Umkodierung vorgenommen werden,
>    dazu wird die p/q-Tabelle benutzt, die in der Indexparameterdatei angegeben ist.
>    Passiert das *nach* der o-Umkodierung?

Ja. Und auch nach der UTF-8-Decodierung.
[Es gab allerdings einmal einen Bug in avanti-cl, der mit #-n -Abarbeitung
und/oder Umcodierung des zweiten Suchbegriffs in Konstruktionen qrix von --- bis
zu tun hatte]


> Meine Vorstellung ist jetzt:
> Der Avanti zeigt in seinem Fenster die DOS-Version der Anfrage an. Diese

Die Konsolfenster unter Windows und auch Linux sind recht schlau, was die
Interpretation der Codierung von Texten angeht, wenn man etwas korrekt oder
nicht korrekt sieht, muss man dennoch vorsichtig sein, was die Aussage
zur Zeichencodierung angeht.

> wird in Windows-Latin-1-Kodierung an die Datenbank gerichtet, dort per o-Tabelle
> umkodiert, anschließend gegebenenfalls an der Stelle #-n weiterbehandelt und
> dann im Register aufgesucht.

> Ist das so korrekt, und wenn ja, gibt es schon irgendwo Methoden, mit denen
> ein eingegebener UTF-8-Code von "ö" zum Schluss als "oe" in der Datenbank ankommt?

Populo habe ich schon vor laengerer Zeit auf Unicode umgestellt, d.h.
insbesondere die Anfragen werden als UTF-8 an avanti weitergeleitet.
Benutzt wird eine aeltere Methode hierfuer, inzwischen kann acon das
auch eleganter (ich habe leider vergessen, wie):



Vorbereitung, damit Registerauszuege und Kurzlisteneintraege als utf-8 an das
Skript zurueckgeschickt werden. e-utfpop hat an der Sprungmarke #-X die
"uebliche" UTF-8-erzwingung

#-X
#hi +- Z
#u1
#+#

(eingebunden ist eine p-Tabelle Ostwest->UTF-8, die macht die Arbeit)

  //PO?IF(LegacyCharset)?
  //PO?ELSE?
   xport param e-utfpop
   dow wX
  //PO?ENDIF?


Die eigentliche Recherche muss ueber die iV abgewickelt werden, sie ist
hier in drei Versionen eingebaut:

Original als qrix ...

  //PO?IF(LegacyCharset)?
qrix PO!PrepRV(Register, SrchVal)!


bzw. falls avanti neu genug fuer "xcode" und $-Variablen ist:

  //PO?ELSIF(CanXCode)?
set U1
$_ PO!PrepRV(Register, SrchVal)!
set U0
var $_
xcode u
switch coding 0
qrix
switch coding 1


sonst ueber den bereits seit einigen Jahren funktionierenden Umweg
ueber die echte Kategorie #u2 (als #u22 geschrieben, damit auch k3-
Formate damit klar kommen)

  //PO?ELSE?
set U1
#u22 PO!PrepRV(Register, SrchVal)!
set U0
var #u22
switch coding 0
qrix
switch coding 1
  //PO?ENDIF?


bei "find" ist das ganze recht analog.

Der Teil, der in populo dann die eigentliche Kommunikation mit
avanti abwickelt, ist nur geringfuegig angepasst: Die dort
traditionell stattgefundene Umwandlung ostwest-Windows -> Unicode muss
z.B. deaktiviert werden, wenn avanti bereits UTF-8 liefert.

Ausserdem gibt es eine aergerliche Sache, dass naemlich die Avanti-
Fehlermeldungen stets der String aus der UIF-Datei sind, also keiner
Umwandlung nach UTF-8 unterworfen sind, auch wenn sie z.B. den
Suchbegriff wiedergeben: Die ganze Meldung ist auch in der Unicode-Situation
stest in OSTWEST-Windows codiert :-(

Fazit also: UTF-8 ist fuer avanti brauchbar und inzwischen durchaus vorzuziehen,
fuer das ZTARGET mangels entsprechender Einflussmoeglichkeiten ist es kein
Weg.

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

iJwEAQECAAYFAky+yAAACgkQYhMlmJ6W47P2IgQAku+Lm19wwX51950BQBZ5HAZo
R8t486TgvRAo3CnhCuyVsGZVBDSpsD/y7jDprXCT5KLlyZEuTdi6Y2iMOgdSOd0c
rGshlBkczyIW81MfN6SfSXz/bggDcPfq+hdwAnKWNEUMXhZQJwoVs5WeAn5S8gvI
nXPbpIr48giKJZJg2yQ=
=dyKr
-----END PGP SIGNATURE-----