Perl Filesystem Encoding erkennen

[Rolf B]

Hallo pl,

Dateinamen kennen keine Zeichenkodierung! Von daher liefert readdir(), weil es grundsätzlich bytesemantisch arbeitet, stets Oktetten. Wenn das nicht die Oktetten sind die erwartet wurden, ist beim Anlegen der Datei was schiefgegangen.

Also nochmal von vorn...

Das ganze Chaos resultiert daraus, dass man einem Perl-String nicht anzusehen können scheint, ob er eine Bytefolge oder einen String repräsentiert. Man muss es wissen. Und bei Bedarf transformieren. Aus Sicht von Perl von einem Irgendwas-String in einen anderen. Aus Sicht des Programmierers aus einer Codierung in eine andere. PHP ist da nicht besser. C#, Java und JavaScript schon, die trennen säuberlich zwischen byte[] und string.

Dateinamen sind Strings. Die bestehen aus ZEICHEN. Im Falle von NTFS bis WinNT 4 aus Unicodezeichen der BMP, seit Win2K ist der ganze Unicodezeichensatz möglich. Diese Strings müssen einem Anwendungsprogramm übergeben werden. Das geschieht unter Windows - und vermutlich auch unter Unix - so, dass die Anwendung einer API-Funktion einen Speicherbereich zeigt und sagt: Schreib's mir dort hin. Unter Windows gibt es zwei Möglichkeiten dafür: die Ansi-Variante und die Wide-Variante. Je nach Variante übergibt Windows den String ANSI codiert (ein Byte=ein Zeichen, gemäß der Codepage der Anwendung) oder UTF-16 codiert.

Da in der ANSI-Codierung ein Zeichen ein Byte ist, kann man eine ANSI-codierte Bytefolge leicht mit einem String verwechseln. Und readdir tut genau das. Es liefert einen String, der kein Perl-string ist, sondern eine Bytefolge darstellt, die erstmal in die Perl-konforme String-Darstellung überführt werden muss. Mit decode("CP1252", $_).

Und von da aus geht es dann passend weiter nach UTF-8. Die encode-Stufe KÖNNTE unnötig sein, falls Perl Strings intern als UTF-8 Bytefolge ablegt. Aber das weiß man nicht sicher, das ist nicht standardisiert, wenn ich die Perlmonks richtig verstanden habe.

Rolf