[Allegro] Suche, Unicode und Internet-Explorer

Sa Mai 16 15:28:03 CEST 2015

Guten Tag Herr Maus,
danke für Ihre Nachricht.
Am Freitag, 15. Mai 2015 um 15:49 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Liebe Kollegen,

> Ich kann das Verhalten wie folgt sowohl mit dem IE als auch mit
> Firefox reproduzieren:

nun, es wurde davon gesprochen: das es in firefox keine probleme gibt. 
des kollegen bergers meinung: [gar nicht wörtlich, aber hoffentlich 
sinngemäß:] firefox ist sanftmütiger, was fehler angeht.
und die probleme gibt es nur im MSiexpl. kollege th.fischer hat 1x 
erlebt, konnte es nicht wiederholen; ich habe es jederezit wiederholen 
können.

> 1.
> http://www.biblio.tu-bs.de/db/katalog/ aufrufen
> 2.
> Im Browsermenü unter "Ansicht" die Zeichenkodierung auf
> "Westeuropäisch (ISO)" (IE) bzw. "Mitteleuropäsch (Windows)" (FF)

nein, das werde ich nicht tun. ich werde "den teufel tun" und nichts 
verändern. die kollegen in den von mir genannten (justiz-)bibliotheken 
haben kein recht, nicht mal da reinzuschauen bzw zu verändern. ;-(

> 3.
> Müller in in das Suchfeld schreiben
> 4.
> Formular durch Druck von Enter abschicken.
> Das Ergebnis ist
>   http://www.biblio.tu-bs.de/db/katalog/page.php?urG=ALL&urS=M%FCller

> Hier wird das "ü" als Latin1 kodiert.

> Es sollte hinreichend sein, dem <form>-Element ein Attribute
> accept-charset mitzugeben, in dem utf-8 als akzeptierte
> Zeichenkodierung aufgeführt ist.

> <form name="opac" action="page.php" method="get" accept-charset="utf-8">
> ...
> </form>

sie meinen die datei page.php?!
in der letzten offiziellen fassung von phpac sieht der header der 
datei so aus:
[ich finde jedenfalls keinen ausdruck, der auf "form name" lautet.]

<?php
 header('Content-type: text/html;  charset=UTF-8');
?>
<! PAGE.PHP : Seite aus dem Index anzeigen>
<html>
<head>
<?php
  include_once("av_ini.php");  // Einstellungen, Grundfunktionen
  include_once("css.php");     // style Varianten
  include_once("av_page.php"); // Funktionen zum Registerseitenaufbau
echo "<title>";
  echo $TI ." -- Register";
echo "</title>";
?>

<script src="av_func.js" language="JavaScript"></script>
</head>

<body onUnload="if(Fenster!=0) Fenster.close()">

es wird dort av_page.php erwähnt!
ist ihre vorgeschlagene änderung DORT zu tätigen?
naja, in der mitte der datei ist sowas zu lesen:
//  Link fuer neue Suche
// zum Umblaettern:
"wri '<form name=\"regs\" action=\"page.php\" method=post>' n",
"wri '<input type=\"hidden\" id=\"REG\" value=\"' #urG '\"></input>' n",

"wri '<table><tr><td><font face=\"$font\">Register: </td>' n",
"wri '<td><SELECT name=\"urG\" size=\"\" value=\"abc\">' n",
//  vorher ausgewaehltes Reg. steht in #urG (z.B. DIS 1D )
"wri '<OPTION value=\"' #urG '\">    </option>' n",

> Wenn ich auf der besagten Seite den Quelltext entsprechend ändere und
> das Formular abschicke, dann wird das ü richtig als %C3%BC kodiert
> übertragen.

> Vielleicht hilft das ja in den betreffenden Fällen?
sie müssen eine andere datei haben.

???

gruß k.lehmann

> Mit besten Grüßen,
>   -- David Maus

> On Fri, 15 May 2015 15:04:14 +0200,
> Thomas Berger wrote:
>> 
>> Am 15.05.2015 um 13:51 schrieb Fischer, Thomas:
>> > Lieber Herr Eversberg,
>> > 
>> > wenn das veränderte Verhalten nicht an Ihnen liegt, so wird es wohl an meine Windows-Einstellung hängen.
>> > Nachdem ich es einmal deaktiviert hatte, gelingt es mir nicht mehr, den Internet Explorer dazu zu bringen, nicht-prozent-kodierte URLs  mit der einfachen Suchfunktion zu versenden. Warum das so ist, kann ich nicht sagen, allerdings löst das das Problem für die Menschen nicht, die gezwungenermaßen vor einem nicht-konfigurierbaren IE sitzen (siehe Brief Lehmann, dessen Argumentation zur Zeitfrage ich mich im übrigen anschließe).
>> > 
>> > In gewisser Weise war das Problem ja ein doppeltes:
>> > 
>> > 1. page.php produzierte eine nicht %-kodierte URL:
>> >     http://www.biblio.tu-bs.de/db/katalog/page.php?urG=PER&urS=Müller
>> 
>> das ist neu: Warum diskutieren wir zwei Tage ueber das Thema
>> und Sie verraten das nicht? Wo taucht /dieses/ Problem auf?
>> (wenn ich die von Ihnen angegebene URL anklicke, gibt es auf
>> der dann kommenden Seite keine problematische URL - zumindest
>> auf den ersten Blick. Also wollen Sie wohl sagen, dass eine
>> URL wie oben in einer falschen (welcher?) Codierung - in irgendeinem
>> Kontext von page.php produziert wird?
>> 
>> 
>> > 2. page.php konnte eine solche URL mit Internet Explorer nicht korrekt auswerten.
>> 
>> Ja, wenn man sie korrekt auswerten koennte, waeren illegale URLs
>> auch kein Problem. Bzw. ich erinnere mich daran, dass ich in den
>> (spaeten) 1990ern tatsaechlich Code gestrickt habe, der sehr tolerant
>> gegenueber der Uebergabe von Muell war, aber ich gehe davon aus,
>> dass php-Skripte heutzutage das Auswerten gar nicht mehr selber
>> unternehmen sondern auf Library-Funktionen zurueckgreifen.
>> 
>> Hilfsweise war es da ganz nuetzlich, bei den selbst konstruierten
>> URLs darauf zu achten, dass sie bereits URL-encodiert sind, damit
>> diese Aufgabe nicht vom User Agent uebernommen werden muss, der
>> evtl. querschlaegt.
>> 
>> 
>> viele Gruesse
>> Thomas Berger
>> 
>> _______________________________________________
>> Allegro mailing list
>> Allegro at biblio.tu-bs.de
>> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?

Am Freitag, 15. Mai 2015 um 15:49 schrieben Sie:
> Liebe Kollegen,

> Ich kann das Verhalten wie folgt sowohl mit dem IE als auch mit
> Firefox reproduzieren:

> 1.

> http://www.biblio.tu-bs.de/db/katalog/ aufrufen

> 2.

> Im Browsermenü unter "Ansicht" die Zeichenkodierung auf
> "Westeuropäisch (ISO)" (IE) bzw. "Mitteleuropäsch (Windows)" (FF)

> 3.

> Müller in in das Suchfeld schreiben

> 4.

> Formular durch Druck von Enter abschicken.

> Das Ergebnis ist

>   http://www.biblio.tu-bs.de/db/katalog/page.php?urG=ALL&urS=M%FCller

> Hier wird das "ü" als Latin1 kodiert.

> Es sollte hinreichend sein, dem <form>-Element ein Attribute
> accept-charset mitzugeben, in dem utf-8 als akzeptierte
> Zeichenkodierung aufgeführt ist.

> <form name="opac" action="page.php" method="get" accept-charset="utf-8">
> ...
> </form>

> Wenn ich auf der besagten Seite den Quelltext entsprechend ändere und
> das Formular abschicke, dann wird das ü richtig als %C3%BC kodiert
> übertragen.

> Vielleicht hilft das ja in den betreffenden Fällen?

> Mit besten Grüßen,
>   -- David Maus

> On Fri, 15 May 2015 15:04:14 +0200,
> Thomas Berger wrote:
>> 
>> Am 15.05.2015 um 13:51 schrieb Fischer, Thomas:
>> > Lieber Herr Eversberg,
>> > 
>> > wenn das veränderte Verhalten nicht an Ihnen liegt, so wird es wohl an meine Windows-Einstellung hängen.
>> > Nachdem ich es einmal deaktiviert hatte, gelingt es mir nicht mehr, den Internet Explorer dazu zu bringen, nicht-prozent-kodierte URLs  mit der einfachen Suchfunktion zu versenden. Warum das so ist, kann ich nicht sagen, allerdings löst das das Problem für die Menschen nicht, die gezwungenermaßen vor einem nicht-konfigurierbaren IE sitzen (siehe Brief Lehmann, dessen Argumentation zur Zeitfrage ich mich im übrigen anschließe).
>> > 
>> > In gewisser Weise war das Problem ja ein doppeltes:
>> > 
>> > 1. page.php produzierte eine nicht %-kodierte URL:
>> >     http://www.biblio.tu-bs.de/db/katalog/page.php?urG=PER&urS=Müller
>> 
>> das ist neu: Warum diskutieren wir zwei Tage ueber das Thema
>> und Sie verraten das nicht? Wo taucht /dieses/ Problem auf?
>> (wenn ich die von Ihnen angegebene URL anklicke, gibt es auf
>> der dann kommenden Seite keine problematische URL - zumindest
>> auf den ersten Blick. Also wollen Sie wohl sagen, dass eine
>> URL wie oben in einer falschen (welcher?) Codierung - in irgendeinem
>> Kontext von page.php produziert wird?
>> 
>> 
>> > 2. page.php konnte eine solche URL mit Internet Explorer nicht korrekt auswerten.
>> 
>> Ja, wenn man sie korrekt auswerten koennte, waeren illegale URLs
>> auch kein Problem. Bzw. ich erinnere mich daran, dass ich in den
>> (spaeten) 1990ern tatsaechlich Code gestrickt habe, der sehr tolerant
>> gegenueber der Uebergabe von Muell war, aber ich gehe davon aus,
>> dass php-Skripte heutzutage das Auswerten gar nicht mehr selber
>> unternehmen sondern auf Library-Funktionen zurueckgreifen.
>> 
>> Hilfsweise war es da ganz nuetzlich, bei den selbst konstruierten
>> URLs darauf zu achten, dass sie bereits URL-encodiert sind, damit
>> diese Aufgabe nicht vom User Agent uebernommen werden muss, der
>> evtl. querschlaegt.
>> 
>> 
>> viele Gruesse
>> Thomas Berger
>> 
>> _______________________________________________
>> Allegro mailing list
>> Allegro at biblio.tu-bs.de
>> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro

> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro