[Allegro] Umcodierung der Indexsuche (avanti)

Robert Fischer rfb at blinx.de
Do Nov 16 00:28:14 CET 2006


Liebe Herren Berger und Fischer, liebe Liste,

Ihre Hinweise waren recht nuetzlich, ich bin dadurch angeregt worden, tiefer
in die Chose einzusteigen.

Haette ich keine avanti.log erzeugen lassen, waere ich nicht sooo weit wie
jetzt.

Der eigentliche UTF-8-Uebeltaeter ist uebrigens ein neueres APACHE mit einem
AddDefaultCharset UTF-8
in der HTTPD.CONF.

Dadurch werden alle gesendeten Seiten, also auch die an AVANTI gesendeten
JOBTEXTe UTF-8-codiert.

Das mag die ACWWW25-Schnittstelle nicht (aber nicht nur das nicht).

Es gibt da auch noch andere Kleinigkeiten, ueber die zu stolpern grosse
Freude macht. (Der naechste Tag nach der Migraene ist bekanntlich zu den
besten Tagen des Lebens zu zaehlen!)

Es fehlt dann mal ein \n (Voodoo im JOBTEXT), ein split-Zeichen wird falsch
verstanden, ein andermal gibts noch die Kodierungs-Misskommunikation
(gibts sowas??) zu loesen.

ASCII, Ansi, UTF-8, html in mehreren Formen (hex, #dez, benannte Zeichen).
Babylon an allen Ecken!!

Lieber Herr Fischer, Ihre Zeile

$text =~ s/([À-ß])([€-¿])/chr((ord($1)-192)*64 + ord($2)-128)/ge;

hat mir geholfen (naja, mein Mailer hats natuerlich nicht so verstanden, wie
Sies gesendet haben).

Speichern als txt hat mir das Ganze erschlossen. Und siehe da, es
funktionierte an den entsprechenend Stellen.

Ihr Hinweis, Herr Fischer:
Wenn Sie damit arbeiten wollen, sollten Sie die Unicode-Tabellen von Allegro
benutzen. Die Dokumentation dazu ist (m.E.) etwas spärlich, Herr Eversberg
empfiehlt:

"Als Beispiele dienen du.apt und du-rtf.apt, daraus geht eigentlich alles
hervor.
Im Handbuch 10.2.4.7 (online: h ac10-4=10.2.4.7), der auf die anderen Texte
hinweist."

hat mich leider nicht erhellt, da in den APTs die UTF-Sequenzen nicht in der
gelieferten Hex-Darstellung sondern in der dez-Kodierung umgesetzt werden
und m.E. so keine Wirkung haben.

Es ist ja so, das z.B. der Abschnitt #-1 in der API eine Anfrage vom
avanti/qrix-Befehl  erhaelt, der eben nicht ASCII ist, und demzufolge nicht
(mueller-)verstanden wird.

Oder die STL liefert Zeilen, die ansii-kodiert sind. Doch Babylon!!

Jedenfalls darf es zur Nutzung der ACWWW25-Schnittstelle noch einige PSe
geben.
Ich finde deren Funktionalitaet eigentlich recht gut, aber die Nutzung
unter aktuellem avanti und neurem apache und perl ist es eine Krux, die
einzig _den positiven_ Seiteneffekt hat, es alles besser verstehen zu lernen
zu muessen.

Stoerend ist auch zu vermerken, dass bei anscheinend gleicher Installation
auf 2 Rechnern unterschiedliche Errors produziert werden. (Da kommt das mit
den fehlenden \n im JOBTEXT her.

Jetzt habe ich doch noch eine Faulheitsfrage (meine letzte nach einer
D-HTML.APR besserer Funtionalitaet habe ich mir dann selbst beantworten
duerfen) nach dem Wunsch, diese komischen doppelten \hex-Sequenzen von UTF-8
korelliert mit allem anderen Quatsch mal als irgendwie formatierte Liste zu
erhalten.

Also, Frage an alle, die sich auskennen:

Hat Eine(r) eine Konkordanz _aller_ gebraeuchlichen o.g. Kodierungen der
Sonderzeichen, am liebsten in ASCII.

Voraus vielen Dank.

Mit freundlichen Gruessen

Robert Fischer Berlin
rfb at blinx.de
************************************************************









Mehr Informationen über die Mailingliste Allegro