[Allegro] Suche, Unicode und Internet-Explorer

[Fischer, Thomas]

Hallo Herr Berger,

>>>> Herr Lehmann hat mich auf ein Problem mit dem Internet Explorer aufmerksam gemacht: Links der Art
>>>> http://www.biblio.tu-bs.de/db/katalog/page.php?urG=PER&urS=Müller
>>> 
>>> Das ist keine legale URL. Wenn Sie so etwas zusammenbauen, sind Sie
>>> selber schuld. Wenn phpac so etwas zusammenbaut, ist das ein Bug.
>> 
>> Wieso ist das illegal?
>> Je nach Browser wird das so oder anders (z.B. mit M%C3%BCller) in der Adresszeile angezeigt.
>> Wie soll ich wissen, was da steht?
>> Wie können Sie wissen, ob in diesem Brief Müller oder Müller steht?
>> 
>>>> Korrekt erscheint hingegen
>>>> http://www.biblio.tu-bs.de/db/katalog/page.php?urG=PER&urS=M%C3%BCller
>>> 
>>> das *ist* korrekt
>>> 
>>> 
>>>> oder
>>>> http://www.biblio.tu-bs.de/db/katalog/page.php?urG=PER&urS=Müller.
>>> 
>>> auch keine legale URL.
>> 
>> Auch hier geben Sie keinen Grund an.
> 
> Es gibt Standards, z.B. RFC 3986
> < https://tools.ietf.org/html/rfc3986 >.

mehr dazu gleich unten.

Aber um das Problem klar zu machen: es geht um die Suchfunktion in phpac.

Wenn man mit einem beliebigen Browser
http://www.biblio.tu-bs.de/db/katalog/
aufruft, bekommt man eine Feldwahl mit Suchschlitz.
Wählt man Person (…) und sucht nach "Müller", so sollte man einen entsprechenden Registerabschnitt erhalten.
Da diese Suche offenbar über einen GET-Befehl abgewickelt wird, bekommt man dazu auch eine URL im Browser angezeigt, z.B.
http://www.biblio.tu-bs.de/db/katalog/page.php?urG=PER&urS=Müller
(wie das intern verarbeitet wird, muss damit nicht identisch sein).
Der Registerabschnitt sollte mit
☐	mueller (30)
	mueller , andreas korn- --> korn-mueller , andreas
	mueller , claudia croos- --> croos-mueller , claudia
	mueller , dominique gauzin- --> gauzin-mueller , dominique
…
beginnen und im Suchfeld sollte "Müller" stehen.
(Dass die Registerauswahl verloren geht, ist wohl ein kleinerer Fehler.)

In dieser Situation liefert der Internet Explorer in der Standardeinstellung (UTF-8-URLs senden aktiv) den Registerabschnitt
☐  mzn 
☐  mzoughi 
☐  mzs 
☐  mzsg 
…
und im Suchschlitz steht "M☐ller" (oder so).

Wenn ich in Windows 7 unter Systemeinstellungen "Internetoptionen" wähle, öffnet sich das Fenster "Eigenschaften von Internet" (typisch Microsoft: völlig blödsinniger Name…), und ich kann unter dem Reiter "Erweitert", wenn ich lange genug scrolle, unter dem Punkt "International" "UTF-8-URLs senden" aktivieren und deaktivieren. Deaktiviert sendet der IE die URL
http://www.biblio.tu-bs.de/db/katalog/page.php?urG=ALL&urS=M%C3%BCller
die er korrekt verarbeiten kann, ist die Option aktiv wird
http://www.biblio.tu-bs.de/db/katalog/page.php?urG=ALL&urS=Müller
gesendet, an der er scheitert.

Auf diese unbefriedigend Situation ist Herr Lehmann bei einer Nutzergruppe gestoßen, die wegen institutioneller Zwänge nur mit dem IE arbeiten und dort auch nicht die Einstellungen ändern kann.

Was also tun?

Was darf page.php (das für die Suche zuständig ist) senden, und wie soll es gesendete URLs verarbeiten?

So kommt man wieder auf die Frage, was eine legale URL ist.

https://tools.ietf.org/html/rfc3986 ist von 2005 und ist die Überarbeitung von https://tools.ietf.org/html/rfc1738.

In RFC 1738 steht:
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used
   unencoded within a URL.

In RFC 3986 ist das viel weniger klar:
   The URI syntax provides a method of encoding data, presumably for the
   sake of identifying a resource, as a sequence of characters.  The URI
   characters are, in turn, frequently encoded as octets for transport
   or presentation.  This specification does not mandate any particular
   character encoding for mapping between URI characters and the octets
   used to store or transmit those characters.

Im Anhang A von RFC 3986 wird eine ABNF für URIs angegeben, die (unter Bezug auf https://tools.ietf.org/html/rfc2234 von 1997) als Zeichen nur Ziffern, A-Z, a-z und die Zeichen in "-._/~" zulässt.
Wenn ich das recht verstehe, sind damit auch URLs wie
http://uni-münster.de/de/
oder
http://موقع.وزارة-الاتصالات.مصر
unzulässig.

Es könnte sein, dass der Stand des RFC mittlerweile von der Entwicklung (der Browser) überholt ist und daher der RFC (3986 oder 2234?) einer Anpassung bedarf. Insbesondere ist nicht klar, ob man dies zum entscheidenden Maßstab nehmen kann, soll oder muss.

> In HTML 4.01 ist allerdings das href-Attribut vom Typ CDATA, d.h.
> technisch gesehen ist es immer noch korrektes HTML, obwohl eine
> formal unmoegliche URL darin steht. Umgekehrt werden ins href-Attribut
> haeufig nackte "&" hineingesetzt, das ist zwar URL-technisch korrekt,
> aber illegales HTML...
> 
> Insofern haben Sie recht, die Browser (bzw. andere User Agents) /muessen/
> hier staendig eingreifen, das was da steht kann nicht 1:1 ueber HTTP
> angefordert werden.

Genau, und wie soll das von page.php bearbeitet werden?

> Ihre Beschreibung aus der vorigen Mail laesst mich raten, dass in Ihrer
> Situation in ein als UTF-8 codiert deklariertes HTML-Dokument eine URL
> mit Sonderzeichen eingebettet ist, die auch in Bezug auf UTF-8 ein
> illegales Zeichen sind, anscheinend ein Latin1-codiertes ein-Byte "ü".
> Selbst diesen Doppelfehler koennen dann manche Browser noch reparieren,
> aber wohl nicht alle...

Mir ist nicht ganz klar, warum Sie in dieser Situation raten und nicht meiner Beschreibung des Problems folgen:

>> Ist aber auch egal, suchen Sie mit Ihrem bevorzugten Browser nach "Müller" im Personenregister von
>> http://www.biblio.tu-bs.de/db/katalog/
>> und sehen Sie, was dabei herauskommt.

Mit besten Grüßen und Wünschen für einen erholsamen Feiertag
Thomas Fischer