[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