AW: o.*pt

[Thomas Berger]

Lieber Herr Fischer,

> Ich (miss)brauche einige Zeichen jenseits der 127, um in einer URL Datenbankanfragen zu kodieren. Dafür benutze ich
>  × (= Malzeichen, wie x) für UND,
> | für ODER und
> ¬ (=Nichtsortierzeichen) für NICHT.

dann sollten Sie sie aber auch URL-Escapen.

> Diese Anfragen werden an Allegro weitergegeben, und in eine HTML-Datei eingebaut, um als Link zu weiteren Fundstellen zu dienen. Beispiel:
> http://www.HistoryGuide.de/cgi-bin/ssgfi/anzeige1.pl?db=hist&sc=(973?×(32?|35?)|(973?¬3?))×(t1:0904?|t1:0905?)&hd=
> (ein ununterbrochener Link).
> Die Links, die hinter "Results:" erscheinen sind von der beschriebenen Sorte.
> Und hier wird dann das × (= Mal) durch ž (z mit Hacek), und das ¬ (nicht)  durch ª (erhöhtes unterstrichenen a)  ersetzt, wenn ich in meiner AAC.gpi die o-Umsetzung durch ein to aktiviere.
> (Das sieht man so nicht mit den neuen Netscape-Browser, weil da noch Unicode dazwischen kommt.)
> 
> Da ich dachte, dass Export von Indexparametern unabhängig sein sollte, hat es etwas gedauert, bis ich das gefunden habe. Aber es ist genau die DOS--> ANSI Umsetzung, die bei o.gpt stattfindet. Und es passiert genau dann, wenn ich to in AAC.gpi aktiviere, und verschwindet, wenn ich es deaktiviere.

grundsaetzlich gilt, dass avanti mit seinen Clients in
"allegro-Windows", also mit zwischengeschalteter o-Tabelle,
kommuniziert. Ausser im Fall parametrierter Ausgabe, also
bei "download". D.h. positiv sowohl bei Jobs, insbesondere
Suchbegriffen und auch bei Indexabschnitten und Kurztitel-
Zeilen und eigentlich auch bei "write" (zu aktuellen Problemen
mit "write" siehe jedoch: <
http://www.gymel.com/bugzilla/show_bug.cgi?id=234 >).

Inwieweit jedoch avanti oder aber Ihre Perlskripte ueber
Umcodierungen stolpern, kann ich Ihrer URL nicht ansehen.

viele Gruesse
Thomas Berger