dedlfix: Umlaute und Dateinamen

Beitrag lesen

Hi!

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.

Vergiss die Multibyte-String-Extension, was deren Aussagen zum Rest von PHP anbelangt. Sie ist nur ein Zusatz und alles was man mit ihr üblicherweise anstellt, hat keine direkten Beziehungen zu anderen Funktionen und Funktionalitäten von PHP, auch nicht in lesender Richtung. Eine Ausnahme bildet das Function Overloading Feature, das man aber normalerweise nicht in freier Wildbahn aktiviert findet. Und wie gesagt, PHP hat derzeit mit UTF-8 nichts weiter am Hut, als dass es ein paar wenige Funktionen liefert, die optional Zeichenkodierungen berücksichtigen (oder für explizite Konvertierungen gedacht sind). Da es keine generelle Unterstützung für UTF-8 mitbringt, stellt es sich auch nicht gemäß irgendwelcher Kodierungen um oder dergleichen. Zudem kann man aus einem Datenstrom keine Kodierung erkennen. Sie müsste dazu in Metadaten bekanntgegeben werden. Für Dateien gibt es keinen solchen Mechnismus, so dass lediglich ein Raten übrigbleibt, und das macht PHP nicht, weil ... kein UTF-8, wissenschon.

In Quelltext steht nun <param name="FlashVars" value="src=Qualit�t ...">.

Weil dir glob() und/oder das Betriebssystem einen ISO-8859-1- oder Windows-1252-kodierten Dateinamen geliefert hat.

<meta http-equiv="content-type" content="application/html; charset=UTF-8">
bringt den Browser zwar dazu, die Kodierung auf utf-8 zu setzen.

Falsch formuliert, deutet auf eine Wissenslücke hin. Richtig wäre: Das bringt den Browser dazu, das Dokument nach den Regeln von UTF-8 zu interpretieren. Und wenn da ein einzelnes Byte aus dem Bereich x80..xff zwischen ansonsten x00..x7F drin steht, wie es für ein ISO-8859-1-Umlaut der Fall ist, dann gibt das Ungültig-Zeichen �.

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!

Exaktamente. Aber nicht der Browser findet, sondern der Webserver.

mb_internal_encoding("utf-8");
bringt mir zwar
var_dump(mb_internal_encoding());
"UTF-8",

Vergiss mb_internal_encoding() in dem Fall, das wirkt nur auf die mb_*-Funktionen.

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?

PHP weiß nichts von der Kodierung, die dein Texteditor verwendet hat. Es benötigt nur ASCII für seine Schlüsselwörter. Der Rest von x80..xFF wird nicht ausgewertet sondern als einzelne Bytes angesehen. mb_internal_encoding() und glob() kennen sich nicht. Du kannst nichts beeinflussen, nur das beste aus der ISO-8859-1-Situation machen. (raw)urlencode() schon probiert?

Lo!