Hallo Auge,
Da wir das Thema schon vor einigen Tagen hatten, lies bitte mein dortiges Posting *und* Sven Rautenbergs Korrektur meiner Ausführungen wegen der Prüfung, ob die Erweiterung überhaupt vorhanden ist.
var_dump(mb_internal_encoding()); bringt iso-8859-1 auf meinem Rechner wie auch auf dem Server. Obwohl ich das Dokument im SciTE mit UTF-8-Kodierung bearbeite.
In Quelltext steht nun <param name="FlashVars" value="src=Qualit�t ...">.
Browser sucht nun also per http nach einer Resource namens "Qualit�t.mp3", die es aber nicht gibt.
<meta http-equiv="content-type" content="application/html; charset=UTF-8">
bringt den Browser zwar dazu, die Kodierung auf utf-8 zu setzen. Dann wird aber dennoch im Titel, den ich ja auch angebe,
"Qualit�t" angezeigt. Weil ja, vermutlich, vielleicht dämmerts jetzt (?), der Server das "ä" als iso-8859-1 ausspuckt. Der Browser zeigt es falsch an und frägt deshalb auch nach der falschen Resource, nämlich nach "Qualit�t.mp3", welche es ja nicht gibt. Das kann ich testen, indem ich die Kodierung per Hand umstelle. Dann findet er auch die Ressource!
Aber
header ('Content-type: text/html; charset=utf-8');
mb_internal_encoding("utf-8");
bringt mir zwar
var_dump(mb_internal_encoding());
"UTF-8",
aber der Browser zeigt mir in der UTF-8-Kodierung immer noch "Qualit�t", was ja wohl heißt, dass PHPs glob() die Dateinamen als iso-8859-1-kodiert angibt. Test dazu: utf8_encode($mp3File) eingebaut, und es wird "Qualität" angezeigt und die korrekt Ressource gefunden. Aber das ist ja hyperkandidelt.
Bleib ich bei iso-8859-1 und wundere mich, warum sich PHP nicht von der Kodierung des Texteditors, den Headern und der mb_internal_encoding() beim Auslesen mit glob() beeinflussen lässt. Oder doch ein Denkfehler bei mir?
Dank und Gruß
jobo