avanti: regsrch.pl

[Thomas Berger]

Lieber Herr Kuhn, lieber Herr Hoeppner,

> ungefähr ab Zeile 109 in regsrch.pl wird die Zeichenumcodierung
> dafür gemacht. Es fängt an mit
> 
> # In der Option 'wert' wird der Registereintrag, von dem aus die Anzeige
> # aufgerufen wird, uebergeben. Fuer Ueberschriften und Anzeigezwecke muessen
> # evtl. enthaltene Sonderzeichen in HTML-Ersatzdarstellungen umgesetzt werden
> # ACHTUNG: Hier gehen wir davon aus, dass die vorliegenden Daten im
> #          ASCII-Zeichensatz codiert sind.
> if( $in{'wert'} )
> {
>     $wert_zeige = $in{'wert'};    # fuer die Anzeige
> 
>     $wert_zeige =~ s/\\x3E/>/g;
>     $wert_zeige =~ s/\\x3C/</g;
>     $wert_zeige =~ s/\\x2D/-/g;
> 
> usw. Dort muss man anpassen. Es ist der Perl-Ersetzungsbefehl.
> (Dieser Teil ist recht alt und kann heutzutage sicherlich leichter
> durch eine entsprechende Routine aus dem aktuellen Perl-Libraries
> ersetzt werden. Fragen Sie mich bitte nicht, wie sie heißt. In Python
> wüsste ich es ;-) Evtl. lliest Herr Berger mit und kann einen heißen
> Tip)

Es ist ein einziger Sumpf!

Gedacht ist eigentlich folgendes: 
In acindex.pl gibt es ein Unterprogramm link_prep,
das zur Aufgabe hat, alle Sonderzeichen in die
sogenannte URL-encodierung zu verwandeln,
also etwa "ü" in "%81". Dies tut es nur unsystematisch
und stellenweise auch falsch (die letzten beiden
Zeilen lauten z.B. s/\AA/%AA/g: und muessten eigentlich
lauten s/\xAA/%AA/g;, ich habe leider ueberhaupt
keine Ahnung, wie sich \A auswirkt [und man muesste 
es sowieso total anders machen, aber das gehoert 
nicht hierher]

in regsrch.pl werden die uebergebenen Werte mittels
Aufruf von ReadParse nach %in transportiert, dabei
wird diese URL-encodierung bereits aufgeloest.
Der uebergebene Registereintrag wird spaeter der
Variablen wert_zeige zugewiesen und ausgegeben.
Dabei muesste nur die uebliche Vorsicht angewandt
werden, naemlich "&", ">" und "<" zu escapen, damit
sie im HTML auch sichtbar werden.

Stattdessen wird auch noch eine Codierung fuer
uebergebene Werte der Form "\x3E" etc. gemacht,
von denen ich mir ueberhaupt nur schwer vorstellen
mag, wie und wo solche zustandegekommen sein koennten,
jedenfalls gibt es keinen Hinweis darauf, dass
hier Herrn Kuhns Problem stecken koennte.
[Aus dem Register kamen wegen impliziter Umcodierung
bereits ANSI-Daten, daher wird nicht die Routine anz_prep 
aus acwww25.pl benutzt zur Vorbereitung der Anzeige des 
Suchbegriffs, soviel glaube ich zu verstehen...]


Andererseits ist das beobachtete Zeichen Â, also
\xc2 und da lohnt es sich doch, alles von Hinten
nach vorne zu verfolgen und dann doch bei der
entgleisten Ersetzung
s/\C2/%C2/g; in Zeile 489 von acindex.pl zu landen:
\C hat naemlich in den neueren Perl-Versionen die
Bedeutung als Platzhalter fuer ein "Oktet" (dies
wird in Perl 5.6 benoetigt, falls mit Unicode-
Strings gearbeitet wird). Insofern hat unter
Perl 5.6 die Anweisung die folgende Bedeutung:
Ersetze jede "2", der ein Zeichen vorausgeht,
zusammen mit diesem Zeichen durch (die Codierung
von) "Â". In aelteren Perl-Versionen wurde
dieser Ersetzungsbefehl wegen Undefiniertheit 
wohl stillschweigend uebergangen oder produzierte 
eine Warnmeldung...

Insofern sind also in acindex.pl voerdergruendig
die fehlerhaften Zeilen (mit fehlendem "x" hinter "\")
zu reparieren, eigentlich aber sollte generell auf
alle Werte, die zu Hyperlinks verwurstet werden,
einheitlich folgende Operation angewandt werden 
(geklaut aus cgi.pm):

s/([^a-zA-Z0-9_.-])/uc sprintf("%%%02x",ord($1))/eg,

also: Ersetze jedes Zeichen ausser Buchstaben, Ziffern,
"_", "." und "-" durch seine URL-encodierung.

HTH
Thomas Berger


P.S.: Der Vollstaendigkeit halber:
Die falsche Ersetzung \AA -> (Codierung von) "¬" 
betrifft alle Registerwerte, die mit "A" beginnen.
Evtl. hat also jemand im Signaturenregister schon
einmal Merkwuerdigkeiten (bzw. Nichtsortierzeichen
bei der Anzeige des Suchbegriffs) gesehen...

Warum ueberhaupt versucht wurde \xC2 gesondert zu
behandeln, bleibt aber mysterioes: Es ist der 
OSTWEST-Windows-Wert fuer r mit Hacek, ein Zeichen, 
das wohl auch als Praefix gewisser ORDER-Registereintraege
genutzt wird...