molily: Sonderzeichen in Ankernamen

Hallo,

In Bezug auf http://de.selfhtml.org/html/verweise/projektintern.htm#anker, </archiv/2005/8/t113673/> und http://bugs.selfhtml.org/bug.php?op=show&bugid=928:

Ich frage mich gerade, wie man einen Anker und einen Hyperlink zu einem solchen notieren muss, wenn im Anker Zeichen außerhalb von ASCII vorkommen.
Ich hatte tatsächlich einiges nicht bedacht, aber nach meinen Tests bin ich so klug wie vorher.

Wahsaga hat mich auf http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars hingewiesen. Dies empfiehlt eine UTF-8-Kodierung von solchen Zeichen innerhalb von URIs. Weiß jemand, ob das auch in irgendeinem URI-Standard so ausdrücklich vorgeschrieben wird?

Ich bin zunächst davon ausgegangen, das man einfach
  <a name="ö">..</a>
notieren kann (weil name CDATA ist usw., wie diskutiert) und dann mit
  <a href="#%C3%B6">..</a>
darauf verweisen kann.

Allerdings ist Mozilla Firefox der »einzige« Browser, der das versteht, Opera 8.02, MSIE 6 und Konqueror 3.4.2 finden den Anker nicht.

Nun besagt obige Quelle auch: »The same conversion based on UTF-8 should be applied to values of the name attribute for the A element.«

Ergo, wenn man
  <a href="#%C3%B6">..</a>
verwendet, sollte man äquivalent
  <a name="%C3%B6">..</a>
notieren.
Das verstehen alle genannten Browser, unabhängig von der Kodierung des Dokuments mit dem Anker und der Kodierung des Dokuments mit dem Link.

Das ist natürlich keine große Erkenntnis, schließlich taucht hier nirgendwo mehr ein »ö« auf, sondern letztlich nur ASCII-Zeichen, die der Browser problemlos miteinander abgleichen kann, ohne irgendwelche De- und Transkodierungen vornehmen zu müssen.

Ich lese daraus, dass besondere Zeichen in Ankernamen extrem umständlich sind - wer kann schon UTF-8-kodierte, Prozent-maskierte Zeichen lesen oder schreiben? - und dass die besagte »Faustregel« gerechtfertigt ist. Oder hat sich ein Denkfehler eingeschlichen?

Dann gäbe es noch die Möglichkeit der ISO-8859-1-Kodierung:
  <a name="ö">..</a>
  <a href="#%F6">..</a>

Opera und MSIE: Funktioniert weder in einem ISO-8859-1-kodierten, noch in einem UTF-8-kodierten Dokument. Auch nicht in Querlinks zwischen diesen.
Konqueror:
  Funktioniert innerhalb eines ISO-8859-1-kodierten Dokuments.
  Funktioniert von einem ISO-8859-1-kodierten Dokument in ein UTF-8-kodiertes Dokument.
  Funktioniert innerhalb eines UTF-8-kodierten Dokuments.
  Funktioniert von einem UTF-8-kodierten Dokument in ein ISO-8859-1-kodiertes Dokument.
Firefox:
  Funktioniert innerhalb eines ISO-8859-1-kodierten Dokuments.
  Funktioniert nicht von einem ISO-8859-1-kodierten Dokument in ein UTF-8-kodiertes Dokument.
  Funktioniert nicht innerhalb eines UTF-8-kodierten Dokuments.
  Funktioniert von einem UTF-8-kodierten Dokument in ein ISO-8859-1-kodiertes Dokument.

Ich frage mich, was ich in SELFHTML nun schreiben soll. Es geht unter anderem, ob name="ö" irgendeinen Sinn ergibt. MudGuard meinte, man müsste die Prozent-Maskierung anwenden, dann sind auch Links auf solche Anker korrekt (für name="bla#bla" und href="#bla%23bla" mag das ja gelten, ich habs nicht getestet, aber glaube es gerne). Ich weiß nicht, ob es dem theoretisch zuzustimmen ist - folgt denn irgendein oben genanntes Verhalten einem bestimmten Standard? -, auf jeden Fall ist es praktisch wenig zielführend.

Ich habe die neueste Version des Abschnitts »Wahl eines geeigneten Ankernamens« im Bugtracker gepostet. Hat jetzt noch jemand Ergänzungen?

Im Übrigen ist sowieso ziemliche Wichserei. Im Vergleich zu 8.0 steht künftig ein riesiger Haufen langweiliger und für Anfänger unverständlicher Theorie in dem Abschnitt. Vorher gab es nur eine verständliche Praxisempfehlung, die zugegebenermaßen eher empirisch und mit dem gesunden Menschenverstand als theoretisch begründet war. Jetzt gibt es nahezu haargenau dieselbe Empfehlung, dafür weniger verständlich und anhand von dutzenden Standards begründet. Naja, was tun wir nicht alles, um fachlich korrekt zu sein. ;)

Mathias

  1. hi,

    Wahsaga hat mich auf http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars hingewiesen. Dies empfiehlt eine UTF-8-Kodierung von solchen Zeichen innerhalb von URIs.

    Diese Stelle besagt, dass "non-ASCII values" in URIs nicht vorkommen - ein URI, der solche Zeichen enthält, wäre "illegal".
    Davon ab bezieht sich dieser Part aber vor allem darauf, wie ein User Agent reagieren _sollte_, falls der Autor eines HTML-Dokumentes sich nicht daran gehalten hat.

    Weiß jemand, ob das auch in irgendeinem URI-Standard so ausdrücklich vorgeschrieben wird?

    S.o. - "non-ASCII values" sollen "illegal" sein - aber der Text unter obigem URL will gar nicht so sehr auf den Standard hinweisen, sondern will eher darauf hinaus, wie ein Client sich verhalten sollte, wenn ihm sowas nichts detso trotz unterkommt.

    Ich frage mich, was ich in SELFHTML nun schreiben soll.

    Wie wär's mit der _Empfehlung_, sowas gleich von Anfang an zu vermeiden - um evtl. daraus entstehenden Problemen gar nicht erst die Stirn bieten zu müssen ...?

    Es geht unter anderem, ob name="ö" irgendeinen Sinn ergibt.

    Die allgemeine Empfehlung, Sonderzeichen in Dateinamen auf dem Server und damit auch in URLs zu vermeiden, kann man m.E. auch genauso für Anker aussprechen.

    [...] Ich weiß nicht, ob es dem theoretisch zuzustimmen ist - folgt denn irgendein oben genanntes Verhalten einem bestimmten Standard?

    Ist es sinnvoll, Selfhtml auf irgendwelche Standards diesbezüglich festzunageln - oder nicht vielleicht doch eher, einfach davon abzuraten (ein ab_raten_ hätte ja im übrigen in etwa die selbe Qualität wie ein _SHOULD_ (NOT) in irgendwelchen normativen Dokumenten) - um Probleme damit gar nicht erst entstehen zu lassen?

    Ich habe die neueste Version des Abschnitts »Wahl eines geeigneten Ankernamens« im Bugtracker gepostet.

    Also http://bugs.selfhtml.org/bug.php?op=show&bugid=1008? (Bin mir nicht sicher, ob ich jetzt um diese Zeit noch die korrekte Stelle gefunden habe :-)

    Hat jetzt noch jemand Ergänzungen?

    "Das erste Zeichen muss ein Buchstabe sein. Danach sind auch Ziffern erlaubt. Benutzen Sie als Sonderzeichen im Namen höchstens den Unterstrich (_), den Bindestrich (-), den Doppelpunkt (:) oder den Punkt (.)."

    Wenn man das noch als Empfehlung kennzeichnet - nicht also wirklich normative oder buchstabengetreu auf den Standard bezogene Aussage - sollten doch m.E. alle damit leben können?

    Im Übrigen ist sowieso ziemliche Wichserei.

    Na, na ...

    Im Vergleich zu 8.0 steht künftig ein riesiger Haufen langweiliger und für Anfänger unverständlicher Theorie in dem Abschnitt. [...] Naja, was tun wir nicht alles, um fachlich korrekt zu sein. ;)

    Da wäre vielleicht zu überlegen, ob man das irgendwie trennen kann - erst mal allgemeingültige, auch für Einsteiger verständliche und einleuchtende Erklärung - und wer's buchstabengetreu nach dem Standard haben will, für den dann ggf. noch mal eine gesonderte tiefere Betrachtung der Problematik, mit Verweis auf relevante Stellen des Standards ...?

    gruß,
    wahsaga

    --
    /voodoo.css:
    #GeorgeWBush { position:absolute; bottom:-6ft; }
    1. Hallo,

      Weiß jemand, ob das auch in irgendeinem URI-Standard so ausdrücklich vorgeschrieben wird?

      S.o. - "non-ASCII values" sollen "illegal" sein - aber der Text unter obigem URL will gar nicht so sehr auf den Standard hinweisen, sondern will eher darauf hinaus, wie ein Client sich verhalten sollte, wenn ihm sowas nichts detso trotz unterkommt.

      Das hieße ja, dass man in URIs gar keine nicht-ASCII-Zeichen verwenden dürfte und die %-Maskierung nur zur Umschreibung von ASCII-Zeichen gedacht ist. Offenbar sieht das RFC 3986 anders, der letzte Absatz von »Identifying Data« weist auf UTF-8 hin (wobei ich den Abschnitt nicht ganz verstehe).

      Ich frage mich, was ich in SELFHTML nun schreiben soll.

      Wie wär's mit der _Empfehlung_, sowas gleich von Anfang an zu vermeiden - um evtl. daraus entstehenden Problemen gar nicht erst die Stirn bieten zu müssen ...?

      Eine einfache Empfehlung, sich das alles nicht anzutun und nur lateinische Buchstaben und ._- zu benutzen, ist nach wie vor drin.
      Ich finde es eben sinnvoll, die Gründe dieser Empfehlung anzureißen, wenn wir überhaupt damit anfangen, die Frage »welche Zeichen sind erlaubt« zu behandeln. Zudem muss an dieser Stelle auch noch auf id als Anker hingewiesen werden (das steht in 8.1 gaaanz unten in den Anhängen).

      • name-Attribute in HTML haben nahezu keine Begrenzung, man könnte z.B. <a name="♠♣♥♦"> notieren, wie man lustig ist
      • URI begrenzt die möglichen Zeichen in Ankern sehr streng
      • Anker lassen sich auch mit id-Attributen lösen. id-Attribute in HTML haben eine sehr strenge Begrenzung, die gut mit der von URI harmoniert
      • In XHTML werdn Anker nur noch mit id gelöst. name- und id-Attribute in XHTML haben eine lasche Begrenzung auf »Buchstaben«, die gut mit URI und id in HTML harmoniert
      • Fazit: Selbstbeschränkung auf »a-zA-Z-._«, um kompatibel mit URI, id in HTML und id in XHTML zu sein.

      Ich habe die neueste Version des Abschnitts »Wahl eines geeigneten Ankernamens« im Bugtracker gepostet.

      Also http://bugs.selfhtml.org/bug.php?op=show&bugid=1008?

      Nein, unter der verlinkten Adresse http://bugs.selfhtml.org/bug.php?op=show&bugid=928 ganz unten in den Kommentaren.

      "Das erste Zeichen muss ein Buchstabe sein. Danach sind auch Ziffern erlaubt. Benutzen Sie als Sonderzeichen im Namen höchstens den Unterstrich (_), den Bindestrich (-), den Doppelpunkt (:) oder den Punkt (.)."

      Wenn man das noch als Empfehlung kennzeichnet - nicht also wirklich normative oder buchstabengetreu auf den Standard bezogene Aussage - sollten doch m.E. alle damit leben können?

      Das habe ich schon geändert, der Passus lautet momentan:
      »(...) Sie sollten sich daher auf wenige Zeichen beschränken, die den verbreiteten Browsern keine Probleme machen. Folgende Faustregel hat sich in der Praxis als sicher herausgestellt: Verwenden Sie lediglich die lateinischen Buchstaben, die arabischen Ziffern sowie als Sonderzeichen höchstens den Unterstrich (_), den Bindestrich (-) und den Punkt (.). Als erstes Zeichen des Namens sollten Sie einen Buchstaben wählen.«

      Da wäre vielleicht zu überlegen, ob man das irgendwie trennen kann - erst mal allgemeingültige, auch für Einsteiger verständliche und einleuchtende Erklärung - und wer's buchstabengetreu nach dem Standard haben will, für den dann ggf. noch mal eine gesonderte tiefere Betrachtung der Problematik, mit Verweis auf relevante Stellen des Standards ...?

      Gute Idee. Ich habe in die Beschreibung schon Überschriften eingefügt, sodass man den Teil gegebenenfalls über springen kann. Ich werde versuchen, die Empfehlung direkt an den Anfang des Abschnitts zu stellen und die Erklärung samt Verweis auf id und XHTML darunter zu straffen.

      Mathias

  2. Hi,

    Abschicken sollte man den Driss schon, sonst kommt er nicht an, oder? ;-)
    Wahsaga hat mir zwar die Hälfte bereits aus dem Mund genommen, aber trotzdem, dann war's nicht ganz vergeblich.

    Wahsaga hat mich auf http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars hingewiesen. Dies empfiehlt eine UTF-8-Kodierung von solchen Zeichen innerhalb von URIs. Weiß jemand, ob das auch in irgendeinem URI-Standard so ausdrücklich vorgeschrieben wird?

    Ich habe mich in RFC 3986 noch nicht so ganz eingearbeitet (ich hätte doch ein 3/4 Jahr Zeit gehabt? Ja, ihr vielleicht ;-) aber laut Changelog hat sich diesbezüglich nichts geändert: alles außerhalb der Spezifikation im Anhang A muß entspr.codiert werden.

    Ich bin zunächst davon ausgegangen, das man einfach
      <a name="ö">..</a>
    notieren kann (weil name CDATA ist usw., wie diskutiert) und dann mit
      <a href="#%C3%B6">..</a>
    darauf verweisen kann.

    Das ist so nicht korrekt, wenn das name-Attribut eines Ankers als "Fragment Identifier" dient. Auch da gelten die URI üblichen Bestimmungen.

    Ergo, wenn man
      <a href="#%C3%B6">..</a>
    verwendet, sollte man äquivalent
      <a name="%C3%B6">..</a>
    notieren.
    Das verstehen alle genannten Browser, unabhängig von der Kodierung des Dokuments mit dem Anker und der Kodierung des Dokuments mit dem Link.

    Ja, denn das ist ja auch aus o.a. Gründen korrekt, aber Du hast natürlich ganz Recht mit ...

    Das ist natürlich keine große Erkenntnis, schließlich taucht hier nirgendwo mehr ein »ö« auf, sondern letztlich nur ASCII-Zeichen, die der Browser problemlos miteinander abgleichen kann, ohne irgendwelche De- und Transkodierungen vornehmen zu müssen.

    ... es ist nicht sehr verwunderlich, das es klappt.

    Ich lese daraus, dass besondere Zeichen in Ankernamen extrem umständlich sind - wer kann schon UTF-8-kodierte, Prozent-maskierte Zeichen lesen oder schreiben? - und dass die besagte »Faustregel« gerechtfertigt ist. Oder hat sich ein Denkfehler eingeschlichen?

    Nein, ich finde keinen.
    Ich würde empfehlen sich auf keine Experimente einzulassen und die (ASCII-)Zeichen aus RFC 3986 (Anhang A) zur Nutzung empfehlen.

    Dann gäbe es noch die Möglichkeit der ISO-8859-1-Kodierung:
      <a name="ö">..</a>
      <a href="#%F6">..</a>

    Funktioniert oder auch nicht aus den gleichen Gründen wie bei dem UTF-8 Versuch weiter oben. Nur können Latin-1 wohl mehr Browser.

    Ich frage mich, was ich in SELFHTML nun schreiben soll. Es geht unter anderem, ob name="ö" irgendeinen Sinn ergibt. MudGuard meinte, man müsste die Prozent-Maskierung anwenden, dann sind auch Links auf solche Anker korrekt (für name="bla#bla" und href="#bla%23bla" mag das ja gelten, ich habs nicht getestet, aber glaube es gerne).

    Ich würde sagen, das name="bla#bla" nicht korrekt ist, da

    pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
    pct-encoded   = "%" HEXDIG HEXDIG
    fragment      = *( pchar / "/" / "?" )
    reserved      = gen-delims / sub-delims
       gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
       sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                     / "*" / "+" / "," / ";" / "="

    Das ercheint mir eindeutig. Aber kann natürlich auch sein, das es nur mir so erscheint, lasse mich gerne vom Gegenteil überzeugen. Imerhin gehe ich vom Kontext aus (URI) und nicht von der DTD (CDATA). Die DTD von XHTML machts mit NMTOKEn und der Definition desselben auch nicht gerade einfacher.

    Ich weiß nicht, ob es dem theoretisch zuzustimmen ist - folgt denn irgendein oben genanntes Verhalten einem bestimmten Standard?

    Nein, natürlich nicht, wie kommst Du darauf? Dafür müßtest Du doch eigentlich schon lange genug dabei sein, dies bei keinem Browser einfach so zu vermuten ;-)

    Ich habe die neueste Version des Abschnitts »Wahl eines geeigneten Ankernamens« im Bugtracker gepostet. Hat jetzt noch jemand Ergänzungen?

    <a name="Ein &#9829; für Kinder">
    Finde ich aufgrund des '#' nicht korrekt, wenn es als Anker dienen soll. Und außerdem noch ein blödes Beispiel, da dort entweder CDATA oder NMTOKEN stehen muß aber kein PCDATA. Da wird nix geparsed.

    Im Übrigen ist sowieso ziemliche Wichserei. Im Vergleich zu 8.0 steht künftig ein riesiger Haufen langweiliger und für Anfänger unverständlicher Theorie in dem Abschnitt. Vorher gab es nur eine verständliche Praxisempfehlung, die zugegebenermaßen eher empirisch und mit dem gesunden Menschenverstand als theoretisch begründet war.

    Ja, die sollte da auch besser bleiben. Die trockene Theorie mag sich hinter einem Link verstecken.
    Ich habe zwar selber auch über 30 Jahre gebraucht es zu lernen aber doch: ein wenig Pragmatismus tut hin und wieder ganz gut, er beruhigt die Nerven. Die alte Praxisempfehlung ist ja schließlich so falsch nicht.

    Und außerdem: wenn's eine Referenz hätte werden wollen hieße es nicht SELFHTML sondern HTML-Referenz, oder? ;-)

    so short

    Christoph Zurnieden

    1. Hallo

      kurz dazu:

      <a name="Ein &#9829; für Kinder">
      Finde ich aufgrund des '#' nicht korrekt, wenn es als Anker dienen soll. Und außerdem noch ein blödes Beispiel, da dort entweder CDATA oder NMTOKEN stehen muß aber kein PCDATA. Da wird nix geparsed.

      Das ist ein Fehler des Bugtrackers.
      <a name="Ein ♥ für Kinder"> heißt es letztlich.
      <a href="#Ein%20%E2%99%A5f%C3%BCr%20Kinder"> wäre dann in etwa ein Link darauf.

      Übrigens heißt CDATA bei Attributwerten durchaus, dass sie Entity-Referenzen und numerische Zeichenreferenzen beinhalten dürfen und diese aufgelöst werden müssen. <a name="Ein &#9829; für Kinder"> wäre also genauso wie <span title="Hall&ouml;le"> erlaubt.
      http://www.w3.org/TR/html401/types.html#type-cdata
      Für CDATA bei Elementen muss dasselbe gelten, sonst wäre die dortige Einschränkung »kein Auflösen von Zeichenreferenzen innerhalb von script und style« widersinnig.
      PCDATA wird in (X)HTML nur als Inhaltsmodell für Elemente gebraucht, soweit ich das sehe. Was angesichts dessen der konkrete Unterschied zwischen CDATA und PCDATA ist, weiß ich nicht. In XML gibts CDATA offenbar nur noch für Attributwerte, PCDATA nur noch für das Inhaltsmodell eines Elements.

      Mathias

      1. Hi,

        PCDATA wird in (X)HTML nur als Inhaltsmodell für Elemente gebraucht, soweit ich das sehe. Was angesichts dessen der konkrete Unterschied zwischen CDATA und PCDATA ist, weiß ich nicht.

        Der Unterschied ist, daß PCDATA nach enthaltenen Elementen geparst wird, CDATA dagegen nicht.
        Entities/numerische Zeichenreferenzen werden in beiden Typen aufgelöst.

        Da in Attributen niemals Elemente vorkommen können, wäre PCDATA für Attributwerte sinnfrei, CDATA ist vollkommen ausreichend.

        In XML gibts CDATA offenbar nur noch für Attributwerte, PCDATA nur noch für das Inhaltsmodell eines Elements.

        Soweit ich das sehe, ja.

        Daher muß z.B. um den Inhalt von Script-Elementen, sobald tags darin enthalten sind (document.write("<b>"); oder ähnliches) auch eine CDATA-Section gelegt werden, da ja die enthaltenen Elemente/Tags NICHT geparst werden sollen.

        cu,
        Andreas

        --
        Warum nennt sich Andreas hier MudGuard?
        Schreinerei Waechter
        Fachfragen per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
      2. Hi,

        kurz dazu:

        <a name="Ein &#9829; für Kinder">
        Finde ich aufgrund des '#' nicht korrekt, wenn es als Anker dienen soll. Und außerdem noch ein blödes Beispiel, da dort entweder CDATA oder NMTOKEN stehen muß aber kein PCDATA. Da wird nix geparsed.

        Das ist ein Fehler des Bugtrackers.

        Nein, ist doch mein Fehler gewesen?

        <a name="Ein ♥ für Kinder"> heißt es letztlich.
        <a href="#Ein%20%E2%99%A5f%C3%BCr%20Kinder"> wäre dann in etwa ein Link darauf.

        Achso, ein Bug im Bugtracker ;-)

        Übrigens heißt CDATA bei Attributwerten durchaus, dass sie Entity-Referenzen und numerische Zeichenreferenzen beinhalten dürfen und diese aufgelöst werden müssen.

        Ja, da hat Du natürlich Recht, da hat mich mein Schwung etwas mitgerissen. Bei numerischen Zeichenreferenzen bleibt aber das Problem mit der Raute? Ach nein, es wird ja erst aufgelöst, klar.

        so short

        Christoph Zurnieden

  3. Hi,

    Ich bin zunächst davon ausgegangen, das man einfach
      <a name="ö">..</a>
    notieren kann (weil name CDATA ist usw., wie diskutiert) und dann mit
      <a href="#%C3%B6">..</a>
    darauf verweisen kann.

    Allerdings ist Mozilla Firefox der »einzige« Browser, der das versteht, Opera 8.02, MSIE 6 und Konqueror 3.4.2 finden den Anker nicht.

    Das liegt vermutlich daran, daß die Browser eine Dekodierung nur dort vornehmen, wo diese ihrer Meinung nach erforderlich ist: nämlich für eine Kommunikation mit dem Server. Ein Anker wird browserintern gehandelt und geht nicht "nach draußen". Ich weiß nicht, ob diese Unterscheidung nun wirklich gerechtfertigt ist, aber

    <a name="ö">..</a>
    <a href="#ö">..</a>

    funktioniert jedenfalls browserübergreifend.

    freundliche Grüße
    Ingo

    1. Hallo,

      Ich weiß nicht, ob diese Unterscheidung nun wirklich gerechtfertigt ist, aber

      <a name="ö">..</a>
      <a href="#ö">..</a>

      funktioniert jedenfalls browserübergreifend.

      Schon klar. ;) Das Problem ist eben, dass <a href="#ö"> nicht erlaubt ist, weil »ö« nicht unmaskiert in einer URI auftauchen darf. Siehe http://www.w3.org/TR/html4/appendix/notes.html#non-ascii-chars. Deshalb wirds erst kompliziert, ansonsten bestünde nicht viel Diskussionsbedarf.

      Im übrigen funktioniert <a href="#ö"> <a name="ö"> auch nicht ohne weiteres. Wenn ich in einem ISO-8859-1-kodierten Dokument <a href="utf-8.html#ö"> notiere, macht Firefox daraus ein utf8.html#a%F6 (was logisch ist, wenn nicht sogar notwendig). Und das funktioniert wie gesagt nur in einem ISO-8859-1-kodierten Dokument, nicht im UTF-8-kodierten Dokument. (<a href="iso-8859-1.html#ö"> im UTF-8-kodierten funktioniert, weil Firefox iso-8859-1.html#a%C3%B6 daraus macht, was <a name="ö"> im ISO-8859-1-kodierten findet.)

      Opera, MSIE und Konqueror setzen <a href="#ö"> <a name="ö"> um, aber schreiben einfach ...#ö in die Adresszeile. Wunderbar, eine nicht-URI in der Adresszeile. Muss man auch nicht wollen...

      Mathias