Das Problem dabei ist immer nicht die eine Einstellung an einer Stelle, sondern daß mehrere Einstellungen zusammen inkonsistent sind.
Der Http-Header sagt UTF-8 (Download.exe mit der -h - Option):
QUOTE E:\Temp>download
http://www.dryadesgarten.com/ -h
Pragma: no-cache
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: text/html; charset=UTF-8
Date: Fri, 23 Jan 2009 14:49:25 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Set-Cookie: osCsid=aa2a975ed8c2c02517acf3d8c70bce4f; path=/tmp; domain=dryadesgarten.com
Server: Apache
Status: 200 OK
Das PHP-Script scheint aber als ASCII gespeichert zu sein und liefert effektiv nur einen 1-Byte-Zeichensatz aus: Mit dem Download.exe die Startseite einmal speichern. Dann zwei Möglichkeiten:
(1) Das Ergebnis mit Notepad aufrufen. Dann 'Speichern unter' wählen - da wird die aktuelle Datei als ASCII interpretiert.
(2) Das Ergebnis mit dem uralten edit.com aufrufen, das ist quasi ein Hex-Viewer. Da sieht man, daß kein BOM mitgeliefert wird (sonst sehen die ersten drei Zeichen kryptisch aus) und daß die Sonderzeichen nur als 1-Byte geliefert werden. Bei UTF-8 müßten aber zwei Byte geschickt werden - also weiß der Browser, nicht was er darstellen soll.
Mangels detaillierter PHP-Kenntnisse weiß ich nicht genau, weshalb das Script auf ASCII umschaltet. In einer Windows-Umgebung würde ich sagen: Speichere das als UTF-8. Aber wenn das 1000 Dateien sind...
Der Html-Header
QUOTE <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
ist bei dieser Konstellation irrelevant: Es wird ja bloß ein Byte für einen Umlaut geschickt. Nur ist dieses Byte bei einer UTF-8-Codierung unverständlich. Es ist weder ASCII (< 128) noch ein korrektes erstes Byte gefolgt von einem zweiten. Also ist der Browser ratlos.
In .NET ist das eine zentrale Konfigurationseinstellung 'liefere UTF-8 aus' - damit hat sich das Problem.
