Passender Zeichenvorrat erspart das Encoding

[Der Martin]

Hallo,

Prinzipiell gilt die ungeschriebene Regel: Keine Zeichen oberhalb #127 verwenden und von denen auch nur eine beschränkte Auswahl.

du redest noch von URLs und Dateinamen? Dann stimme ich zu.

Während URLs zwar mit dem Percent-Encoding eine Möglichkeit vorsehen, Zeichen außerhalb dieses Bereichs "sicher" zu übermitteln, scheitert das eventuell an etwas anderem, nämlich an der Zeichencodierung, die dann nicht eindeutig ist.

In Dateinamen sind zwar in manchen Dateisystemen Zeichen außerhalb des ASCII-Bereichs erlaubt, eventuell sogar das ganze Unicode-Spektrum. Aber auch hier gilt: Anwendungen "wissen" nicht unbedingt, in welcher Zeichencodierung das File-API des Betriebssystems die Dateinamen erwartet. In Windows ist das entweder eine landestypische 1-Byte-Codierung (hierzulande meist Windows-1252), wenn man die alten Funktionen verwendet, oder UCS2 (eine Untermenge von UTF-16) bei Verwendung der modernen Funktionen; in Linux ist es häufig UTF-8 (wobei der Linux-Kernel selbst sich nicht um die Zeichencodierung schert). Ich hatte da letztes Jahr eine lange Diskussion vor allem mit Tom, der das Zusammenspiel von PHP unter Windows und anderen Anwendungen aufdröseln wollte, damit aber letztendlich gescheitert ist.

Probleme machen nämlich nicht nur HTML und HTTP, sondern auch das Filesystem des Zielservers und ggf. das des Request-Hosts, sowie das DNS.

Das DNS eigentlich nicht, denn in Hostnamen ist nur eine sehr eingeschränkte Untermenge von ASCII erlaubt. Domainnamen, die scheinbar diesen Rahmen sprengen, werden hinter den Kulissen durch Punycode auf den erlaubten Zeichensatz abgebildet, so dass im DNS meines Wissens nur [a-z0-9.-] auftreten - und der Punkt sogar mit der Sonderbedeutung, Namensteile voneinander zu trennen, so dass er nicht innerhalb eines Namensteils verwendet werden kann.

So long,
 Martin