2013-08-26 13 views
5

Wyjście z następującym minimalnym przykład pokazuje, że (na moim komputerze Linux) File :: Glob wydaje się mieć nieoczekiwany efekt uboczny konwersji ciąg utf8 do non-utf8:Czy plik Perl's :: Glob zawsze powinien być filtrowany przez utf8 :: decode?

#!/usr/bin/perl 

use utf8; 

use strict; 

my $x = "påminnelser"; 
my $y = glob $x; 

print "x=",utf8::is_utf8($x),"=\n"; 
print "y=",utf8::is_utf8($y),"=\n"; 

to jest przyczyną złego zachowanie w moim programie. Na Linuksie wygląda na to, że mogę to naprawić przez zastosowanie utf8 :: decode() po File :: Glob. Czy to jest właściwy sposób, aby to naprawić? Czy jest to błąd w File :: Glob? Czy moja poprawka da poprawne wyniki w innych systemach, takich jak Windows?

Odpowiedz

4

Obsługa kodowania funkcji związanych z nazwami plików znajduje się obecnie na liście zadań perla: Unicode in Filenames. Problem polega na tym, że niektóre popularne systemy operacyjne (na przykład Linux) nie obsługują kodowania nazw plików (poza używaniem bieżących ustawień regionalnych, ale jest to zepsute przez projekt), więc uzyskanie przenośnego rozwiązania w Perlu nie jest takie proste.

Moja rada to unikanie w ogóle nazw plików spoza ASCII.

+0

Dzięki za pomocne informacje +1. Ale to nie odpowiada na moje pytanie, które dotyczyło tego, czy moje obejście było poprawne i/lub wskazane. Nie chcę arbitralnie informować użytkowników, że nie mogą mieć nazw plików spoza ASCII. –

+0

Wskazane jest tylko wtedy, gdy wszyscy użytkownicy używają UTF8 jako kodowania nazw plików. Jeśli masz użytkowników, którzy mają na przykład no_NO.ISO8859-1 jako swoje ustawienia narodowe i tworzą nazwy plików zgodnie z tymi ustawieniami regionalnymi, to nie będą działać. W tym przypadku zaczynasz zgadywać, może używając 'Encode :: Guess' lub podobnych modułów. –

+0

Rozumiem. Tak więc myślę, że odpowiedź na moje pytanie jest taka, że ​​moje proponowane obejście jest złym pomysłem i prawdopodobnie zostanie złamane dla niektórych użytkowników. +1 –