[Allegro] Import und Unicode

Do Dez 12 08:45:35 CET 2013

Lieber Herr Eversberg, liebe Liste,

das hatten wir vor Jahren hier schon diskutiert (spaetestens
nach der GND-Einfuehrung im Sommer 2012?) und sicher und sauber
ist Weg 3:

Solche Importe in zwei aufsplitten, also aus

import -f5 -ixyz -eabd/...

die Sequenz

import -f5 -ixyz -ei-1/...
import -f5 -ialg -eabc/...

machen.

Zu beachten bleibt in Bezug auf "Unicode" noch eine weitere
Besonderheit: Import geht beim Abarbeiten von Exportparametern
mit pa sowie #da/#dA davon aus, dass UTF-codierte Daten ins
Internformat zu wandeln sind, d.h. die Standard-Akzentvertauschung
ist "von hinten nach vorne". Alle anderen allegro-Module hingegen
gehen von einem "Export" aus dem internen Zeichensatz aus und
tauschen hingegen "von vorne nach hinten".

Insofern liefert

import -f5 -ikat -eabc/...

nicht immer dasselbe Ergebnis wie

srch -f6 -eabc/...

viele Gruesse
Thomas Berger

Am 12.12.2013 08:03, schrieb Bernhard Eversberg:
> 
> Uns treibt um, daß beim Import die Umwandlung von Unicode in den
> Interncode nicht absolut glücklich gelöst ist.
> 
> Es funktioniert so:
> Wenn in den Exportparametern u-Befehle eingebaut sind, z.B.
> mittels des Befehls
> 
> tucodes
> 
> die Liste ucodes.apt inkludiert wird, dann werden diese Befehle
> automatisch ausgeführt, und zwar jedesmal am Ende eines Paragraphen.
> Sagen wir, es steht geschrieben:
> 
> #20
> s 0 "4000 "
> ...  evtl. Manipulationsbefehle
> 
> in einer  pica.aim  oder so, dann wird der Fremdsatz nach der
> angegebenen Sequenz durchsucht und der gefundene Inhalt nach
> Abarbeitung der M-Befehle durch die u-Liste gejagt, also jeder
> darin stehende UTF-8-Code ersetzt durch das dazu angegebene
> interne Codezeichen. Beispiel: Wenn in der u-Liste steht:
> 
> u 195 164 132    ...
> 
> dann wird in besagtem Inhalt überall die Kombination  195 164 gewandelt
> in das DOS-ä.
> 
> Was nun aber, und darum geht's uns, wenn hernach diese Paragraphen
> kommen:
> 
> #39
> k20
> b" / "
> 
> #20
> k20
> e " / "
> 
> um den Inhalt von #20 nochmal zu zerlegen in #20 und #39?
> 
> Das macht meistens kein Problem, aber es macht genau dann eines,
> wenn in dem umgewandelten Text von #20 ein Code oberhalb 191 vorkommt.
> Wie z.B. der Code 225  für das scharfe s.
> Denn alle UTF-Codes sind solche, und wenn einer davon nicht in
> der Liste steht, wird eine Sequenz der Gestalt  &#nnn;  draus
> gemacht (nnn = dezimale Unicode-Nummer) , unter Hinzunahme des einen
> oder der zwei nachfolgenden Codes, was in diesen Fällen immer falsch
> ist.
> 
> Was also tun?
> Auch hier geht es darum, wie so oft, einen Bruch der Kontinuität
> zu vermeiden, damit alte Parameter dann nicht versagen,
> Zwei Ansätze drängen sich auf:
> 
> 1.
> Wir haben erst gedacht, die Lösung könnte ganz einfach so aussehen,
> daß das Programm den gesamten Fremdtext direkt nach dem Einlesen
> umwandelt, so daß bei den einzelnen Feldern dann nichts mehr
> zu tun ist in der Hinsicht, der oben beschriebene Vorgang also
> entfällt. Was aber, wenn dann in einem Paragraphen ein s-Befehl
> oder auch ein b-Befehl eine Unicode-Sequenz sucht, z.B.
> 
> #47
> s "Übersetzer: "
> 
> wobei dann bisher das Ü eben ein Unicode-Ü zu sein hätte, nach der
> genannten Änderung aber ein DOS-Ü, d.h. der s-Befehl tät's nicht mehr.
> 
> 2.
> Ein anderer Weg, gleichfalls naheliegend und wie wir jetzt denken
> besser, wäre:
> Wenn in einem Paragraphen mit einen k-Befehl ein Inhalt eines anderen,
> schon umgewandelten Felds herangezogen wird, dann entfällt die
> automatische u-Wandlung des Inhalts.
> Auch hier sind aber Problemfälle denkbar, etwa sowas wie dieses:
> 
> #123
> s "ABC: "
> k345
> w" / "
> 
> Dann würde das, was im Fremdtext hinter "ABC: " steht, nicht
> umgewandelt, weil ja dann noch ein k-Befehl kommt und die
> Umwandlung erst am Ende des Paragraphen stattfindet.
> 
> Was wäre besser, 1. oder 2.? Vielleicht ist das unter 1.
> genannte Problem sehr viel seltener zu erwarten?
> 
> Nachwort
> Im Prinzip recht, aber nur im Prinzip, hätten jetzt die, die
> nun sagen wollten, "Ja Himmelherrgott, stellt endlich alles um
> auf Unicode, dann brauchen wir über solche Quisquilien kein
> Wort mehr zu verlieren."
> Denn erstens ist hier eine 100%-Lösung momentan unrealistisch,
> zweitens wollen wir ja eine Konfiguration mit internem UTF-8
> noch erstellen (ansatzweise ist sie schon da und auch unter
> a35 schon einsatzfähig und mit im a35-Paket drin), und drittens - falls
> einem das nicht weit genug geht - sind die Quellen offen und jedem
> anheimgestellt, sein Können zu erproben oder, viertens, ein neues
> System mit 100% Unicode aus dem Boden zu stampfen. Was wir uns,
> zugegeben, nicht zutrauen oder nicht versuchen wollen, denn vielleicht
> kommt sowas schon morgen oder bald heraus, z.B. unter dem Namen
> Kuali oder als nächste Version von Koha oder als cloudbasierte
> Endlösung für alle und alles.
> Aber das nur nebenbei.
> 
> B.E.
> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro
> 