[Allegro] Frage zu P/Q-Tabelle

[Thomas Berger]

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

Lieber Herr Eversberg,

>> Hoppla. Da habe ich ja Glueck gehabt, dass meine Parameterdatei
>> zufaellig keine Akzentvertauschung durchgefuehrt hat, und daher
>>
>> 208 117
>>
>> das zu ersetzende Muster war.
> 
> In dem Befehl  pa=...  für die Akzentvertauschung stehen einzelne Byte-
> Codes, nur auf diese kann also das Programm bei der Durchführung Bezug
> nehmen. Das bedeutet:
> Die Akzentvertauschung kann nur funktionieren, wenn die Akzente einzelne
> Bytes sind, also gerade nicht dann, wenn man intern UTF-8 hat und das
> Ergebnis dann aber OstWest oder sonst ein ASCII- oder ANSI-Code sein
> soll. In solchen Fällen würde nur ein zweiter, nachgelagerter Export
> helfen mit einer i-1.apr und darin eingebauter Akzentverlagerung. Erst
> dieser Export würde also den ersten Export mit P/Q, der ja dann nicht
> mehr UTF-8 ist, in die erwünschte Form umsetzen.
> (Anders gesagt, die Akzentvertauschung NACH der P/Q-Wandlung

Ich bin nicht sicher, ob ich Ihnen da folgen kann:

Der Standardweg fuer die Konversion von UTF-8 nach OSTWEST ist beim
Import, IMPORT.EXE wendet automatisch die pa-Liste in den Export-
Parametern an und automatisch die u-Tabelle in den Exportparametern.

Fuer SRCH.EXE hingegen (auch acon?) ist eine u-Tabelle ohne
Belang und Akzentvertauschung benoetigt nicht nur die pa-Liste,
sondern auch #da (lassen wir mal beiseite, dass dieses auch "aussen",
also im eventuell aufrufenden Flex bzw. Job durchgefuehrt werden
kann)

Bei einem Export einer Unicode-codierten Datenbank in einen
anderen Zeichensatz kann man bereits kontrahiertes natuerlich
explizit ueber den Export definierende VS-Sequenzen (Methode 1)
oder die P/Q-Tabelle abhandeln, die fuer den Rest ggfls. notwendige
Akzentvertauschung (etwa beim Export nach ISO5426 oder ANSEL),
und/oder die vorbereitende Kontraktion von Zeichen plus Diakritika
zu kombinierten Zeichen ist aber nicht direkt leistbar, man muss
also (etwas anders als von Ihnen beschrieben) einen vorgelagerten
Export durchfuehren, der allegro-Kategorien belaesst und die
Rohkonversion der Zeichen durchfuehrt, und dann einen Haupt-Export,
der die Formatumsetzung sowie die Akzentvertauschung durchfuehrt,
aber im Wesentlichen schon auf dem (byteorientierten) Zeichensatz
des Zielformats operiert: Das ist extrem misslich, denn Nachladungen
z.B. sind dann tabu und verwirrend ist es auch. Beim von Ihnen
skizzierten Weg ist es aber auch umstaendlich, ich kann dann nicht
direkt nach MARC exportieren, sondern nur ins Internformat des U-
Schemas, damit ich dort dann in einem akzentvertauschenden Export
das eigentliche MARC erzeugen kann. D.h. ich muss fuer jedes
Zielformat eine eigene Konfiguration vorhalten und pflegen...

Moeglicherweise ist die ganze Akzentvertauschung in ihrer derzeitigen
Form ein Irrweg (ausser evtl. bei IMPORT.EXE): #da murkst mir den
gesamten Aufnahmespeicher in einen Zustand um, der ueberhaupt keinem
definierten Zeichensatz entspricht, einziger Zweck der Uebung ist,
dass die Umcodierungen (am entgegengesetzten Ende der Verarbeitung)
erleichtert werden, dazwischen, also wo die Parameter arbeiten, kann
man nur hoffen (bzw. bei der Parametrierung drauf achtgeben), dass die
Verdrehung keine unerwuenschten Effekte / falschen Annahmen provoziert.

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

iQCVAwUBSOM7PWITJZieluOzAQJ+PwQArzaUhVO4KqQD847bh2xUchITFa+IsAge
yTp5k/xCpZ0jG54cUKscD1AOnfJXtC3gNc4K/sM2OPpAtYkHOfAIjNNxb0O9ONBI
UmQIp33uYYt2oWp2l4N1OxRcuVvLB+jSgS4tCytLvXPTiTecCV4/hod/cv92fUS6
SZGVGtTFTAU=
=Y1p2
-----END PGP SIGNATURE-----