Hallo,
»» http://www.faqs.org/rfcs/rfc1738.html -> Abschnitt 2.2
»» Also nur druckbare Zeichen des ASCII-Character Sets sind gestattet.
»» [...]
Soweit so klar, aber da bleibt immer noch offen, was die hexadezimalen Werte darstellen sollen. UTF-8-Sequenzen oder ISO-8859-1 oder ...?
natürlich bleibt das offen, denn das ist dann schon nicht mehr der URL-Kontext, sondern dessen Abbildung auf das Filesystem oder andere lokale Eigenschaften des Servers. Die Eigenschaften dieses serverinternen Kontexts (also z.B. die Zeichencodierung oder eine eventuelle Beschränkung auf ein Subset) muss man daher schon beim Erzeugen der Roh-URL beachten, noch bevor die URL-Codierung mit dem %-Prefix greift.
Die Post schreibt uns ja auch nicht vor, wie wir einen Briefbogen zu beschreiben haben, sondern nur die Beschriftung des Umschlags.
Mir ist nicht bekannt, dass man dem Apachen sagen könnte, gemäß welcher Kodierung er das zu interpretieren hat
Er muss das gar nicht interpretieren, sondern die URLs nach der URL-Decodierung uninterpretiert an das Subsystem übergeben, dessen er sich bedient (Filesystem, Handlerfunktion, CGI-Schnittstelle). Auch bei internen URL-Operationen (z.B. mod_rewrite) muss der Apache nicht wissen, was die Bytes bedeuten, die er da vergleicht. Er behandelt sie Byte für Byte, ohne sich dafür zu interessieren, für welches Zeichen diese Bytes stehen.
Der allgemein gültige Rat lautet immer noch: Nicht-ASCII-Zeichen in URLs und Dateinamen vermeiden (egal ob umkodiert oder nicht).
Ja. Auch wenn in einem gegebenen Kontext vielleicht eine Menge Sonderzeichen erlaubt sein mögen, tut man gut daran, sie zu vermeiden, solange man die Schnittstellen zu anderen Systemen nicht exakt kennt.
Ciao,
Martin
Niemand ist überflüssig: Er kann immer noch als schlechtes Beispiel dienen.