Hallo,
die technischen Hintergründe kann ich nicht beurteilen und nehme das als gegeben hin.
dann nehme ich mal die gegenüberliegende Position ein. :-)
Mir ist jedoch eingefallen, dass Textile 1.0 auch nicht mit Umlauten umgehen konnte, Textile 2.2 kann das und mir sind keine Sicherheitsprobleme bekannt. Keine Ahnung, wie das gelöst ist.
Hab ich auch keine Ahnung, zumal ich nicht weiß, was Textile in diesem Beispiel ist.
Seit ein paar Jahren sind Umlaute in Domainnamen prinzipiell erlaubt ("mäh.de" wäre also möglich), allerdings nur an der Benutzerschnittstelle. Das heißt, man kann "mäh.de" im Browser eingeben, der Browser kann/darf es auch so anzeigen, aber intern wird die Umlaut-Schreibweise in Punycode umgesetzt. So hat man die Rückwärtskompatibilität zum bisherigen DNS sichergestellt.
Ergo: Auf Anwenderebene gibt es Domainnamen mit Umlauten, auf Protokollebene nicht.
Etwas anderes sind Umlaute im lokalen Pfad einer URL. Dort erlaubt HTTP sie immer noch nicht; will man also unbedingt welche haben, muss man sie URL-codieren, so wie du es eben auch getan hast. Problematisch ist dabei, dass die an dieser Stelle vom Server verwendete Zeichencodierung völlig unbekannt ist. Die ist aber entscheidend für das richtige Interpretieren der Eingabe. Es ist also von außen nicht erkennbar, ob man example.org/M%C3%BCnchen oder etwa example.org/M%FCnchen eingeben muss, damit die Eingabe richtig verstanden wird.
Ergo: Umlaute in URLs können problematisch sein, am besten vermeiden!
So long,
Martin
--
Elefant zum Kamel: "Sag mal, wieso hast du denn den Busen auf dem Rücken?"
Kamel: "Ziemlich freche Frage für einen, der den Penis im Gesicht hat."
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(