vielleicht auch nur ein Bug?

[Sven Rautenberg]

Moin!

ich bin gerade dauernd in Manuals und Webseiten unterwegs die ähnliche Probleme hatten nach der Umstellung.

Hier ist mir zufällig ein Bug Report von PHP aufgefallen.

http://bugs.php.net/bug.php?id=46990

Könnte das auch mit meinem Problem zusammenhängen?

Ja, das ist exakt dein Problem.

PHP hat keinen Mechanismus, einem String in einer Variable auch noch ein Encoding zuzuordnen. Und es hat außerdem keinen Mechanismus, dem Dateinamen bei der Funktion fopen() über einen gesonderten Parameter ein Encoding zuzuordnen.

Die Bytes, die im String als Dateiname drinstehen, werden einfach 1:1 durchgereicht ans Dateisystem, und das muss dann sehen, wie es damit fertig wird.

Windows-Dateisysteme nutzen UCS-2 als Speicherformat für Dateinamen, aber es gibt einen Kompatibilitätslayer, der die Dateinamen in Windows-1252 überführt. PHP nutzt beim Dateizugriff diesen Layer. Es ist also derzeit unmöglich, mit PHP auf Windows korrekte Unicode-Dateinamen zu verwenden. Wie im Bugreport ausgeführt, wird das erst mit PHP 6 funktionieren.

Klar, man könnte die relevanten Funktionen (also z.B. fopen()) auch alle um einen Encoding-Parameter erweitern - das wäre aber vermutlich viel aufwendiger und würde vielleicht auch künftigen Erweiterungen widersprechen, insbesondere steht es im Widerspruch zum beabsichtigten Unicode-Support in PHP 6, der solche Spielchen komplett überflüssig machen wird.

Solange ausschließlich PHP den Dateizugriff realisiert, ist es hinsichtlich der Dateinamen übrigens egal, ob das Dateisystem UTF-8 kann, oder nur die String-Bytes unverändert speichert und wieder ausliest. Spannend wird es erst dann, wenn auch andere Zugriffe auf den Dateinamen erfolgen, z.B. vom Explorer, der Kommandozeile, oder dem Webserver. Dabei kann dann alles mögliche schiefgehen - deshalb sind Dateinamen mit etwas anderem als ASCII grundsätzlich eher böse.

- Sven Rautenberg