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

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

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