in reply to Re: Unicode File Names
in thread Unicode File Names

Probably you're running into the OEM vs. ANSI code pages. Just using Unicode completely eliminates that problem! There are two versions of the Windows API entry points: The -A form maps the 8-bit string based on current settings. The -W form takes a 16-bit string and doesn't mess with it.

Good idea using OLE! What is "elder perl" though?

--John

Replies are listed 'Best First'.
Re^3: Unicode File Names
by Courage (Parson) on Feb 09, 2005 at 05:30 UTC
    exactly right: OEM vs ANSI. But perl's open does not refer to Unicode file naming conventions, if I am right

    "elder perl" is 5.6.1, when I wrote that script.
    Hence use Unicode::String;

      I used to. In Work Backup I found that turning on ${^WIDE_SYSTEM_CALLS} made File::Find and File::Copy work correctly even if file names contained strange characters. That was on ActiveState Perl 623, Perl 6.5.1.

      The latter ends up calling Win32::CopyFile, but the former ends up calling readdir, a built-in primitive. So I know that at least returned Unicode when getting a list of file names. I also assume it got consistant results and no not-found errors when passing such a name to stat or lstat.

      Trying that now, I see that readdir is not working. It is giving mangled results consistant with using the ANSI form of the underlying Win32 calls.

      It used to work. Now it's crippled.

      --John

        I downloaded the source code. I found
        #define USING_WIDE() (0)
        in win32/perlhost.h. It appears to control the behavior, e.g.
        if (USING_WIDE()) { ... f = _wfopen(PerlDir_mapW(wBuffer), wMode); } else f = fopen(PerlDir_mapA(filename), mode);
        So, it hasn't been totally ripped out; just the ${^WIDE_SYSTEM_CALLS} switch, to specify the wide mode, has been removed. --John
        well, thank you for that bit of knowledge, and, secondly, looks like a perfect time to fill a bug report...
        that should be fixed, of course!