Thank you!

I still like to use getOpenFile, as it offers a fine TK funtionality to select files in Windows. I changed my subrutine a little bit adding Win32::GetShortPathName() as you suggested. It works fine now. Here is the new script:

sub convert_ansi_to_utf {

my $types = [ ['Text', '.txt'],
              ['All Files',   '*'],];
my $filename= $frame_kwic_setup->getOpenFile(-filetypes => $types);

use Win32;
my $shortpath = Win32::GetShortPathName( "$filename" );
    open(F, "<:encoding(iso-8859-1)", "$shortpath") or die $!;
    open(G, ">:utf8", "$shortpath.utf.txt") or die $!;
    while (<F>) { print G }
close (F);
close (G);

}
[download]

FWIW, there is no need to use Win32 , its always loaded on windows. Also, since there is no need for interpolation, so you can simplify

eval { $filename = Win32::GetShortPathName( $filename ); };
[download]

On an interesting utf sidenote, As of Perl 5.8.7, UTF−8 means strict, official UTF−8 while utf8 means liberal, lax, version thereof.

Using short file names won't work on Windows NTFS file systems for which support for 8.3 file names is disabled. For performance reasons, the file servers where I work do not support 8.3 file names. See How to Disable the 8.3 Name Creation on NTFS Partitions.

There are also times when one needs in one's Perl script the true file name with all its halfwidth katakana and right-to-left Hebrew in it. This is often my situation.

I understand the reason why Perl's support of Unicode file names on Windows is the way it is — which is to say, lame. But I sure wish, in the interest of simple things being easy, it were not the way it is. Even in those cases, like mine, where portability isn't a factor, the often-suggested workarounds using Win32API* modules are less than ideal. And in an ever more plural world, it makes Perl seem not very Modern that it can't speak Chinese file names as easily as it can speak English ones.