[Allegro] acon: Magische Umcodierung

Thomas Berger ThB at Gymel.com
Fr Dez 19 18:51:47 CET 2014


Lieber Herr Eversberg,

hier ist unbedingter Handlungsbedarf:

http://d-nb.info/gnd/118585525/about/marcxml enthaelt in datafield 670
eine Wikipedia-URL mit einem korrekt codierten Umlaut:

<datafield tag="670" ind2=" " ind1=" ">
 <subfield code="a">Wikipedia</subfield>
 <subfield code="b">Stand: 11.12.2012</subfield>
 <subfield code="u">http://de.wikipedia.org/wiki/Gabriele_M%C3%BCnter</subfield>
</datafield>


fuehre ich in acon folgenden Job aus,

acon -jtest.job -bdemo2/cat  > otto.txt

wobei test.job:

>>>
new 0
var "fetching Muenter" newline
Write iV

var "http://d-nb.info/gnd/118585525/about/marcxml"
get I

write

Write "hallo?" newline
<<<

(so faellt am Rande auf, dass "Write iV" /nicht/ wie die anderen
"Write"-Formen nach STDERR schreibt)

in otto.txt steht dann die URL als

http://de.wikipedia.org/wiki/Gabriele_M*3*Cnter

dabei ist das "*" in Wirklichkeit ein ASCII-1

das "%C" und "%B" aus den gelesenen Daten ist also irgendeiner
Magie unterzogen worden, die erstens nicht erwuenscht ist und
zweitens wohl ziemlich entgleist.

Das passiert bereits beim Einlesen, wie man durch ergaenzen von

ins _%_XXX_
ins _^A_YYY_

hinter dem "get I" verifizieren kann (und sowohl die iV als auch
die Kopie in der iV2 haben das Problem).


2.
write Fhttp://d-nb.info/gnd/118585525/about/marcxml

oder

var Fhttp://d-nb.info/gnd/118585525/about/marcxml
write iV

holen zwar die Daten von der URL, wie ich von der Laufzeit
schliessen kann, schreiben aber nichts in die Ausgabe

(etwas ungluecklich ist, dass dieser spezielle cString
auch noch in xwrite.rtf aufgefuehrt ist, als sei es
eine Kommando-Variante wie "write ^" oder "write external"

3.
open http://d-nb.info/gnd/118585525/about/marcxml

ist fuer acon nicht implementiert (auch so dokumentiert), die
Frage ist allerdings, warum: Immerhin ist das die zwar umstaendlichste
Methode fuer den Zugriff auf Daten, im Zweifelsfall aber die
kontrollierbarste und in Job-Dateien, die erfahrungsgemaess seltener
und weniger laessig als Flex-Dateien programmiert werden, lohnt
sich der Aufwand sauberster Loesungen durchaus manchmal...

viele Gruesse
Thomas Berger




Mehr Informationen über die Mailingliste Allegro