in reply to problems matching umlauts in env vars

You said:
it does match the exact same string when I use a variable, but not when handed down by $ENV{'PATH_TRANSLATED'} - which probably is a non-encoded 8bit string.
(emphasis added). Meanwhile, the docs for "utf8" have this to say about the "upgrade" call:
Note that this should not be used to convert a legacy byte encoding to Unicode: use Encode for that.
So, if your environment variable's value is actually set via some single-byte European character encoding ("Latin1"), then just passing it to utf8::upgrade amounts to just calling it utf8 when it really is not. The upgrade call returns the number of octets in the "converted" string (which doesn't really get converted -- it just gets it utf8 flag turned on, I think). So you'll get a non-zero return unless the string is completely empty.

(I confess I'm a bit confused by the docs for "utf8::upgrade" -- especially its behavior wrt "characters in the range 0x80-0xFF". There are odd things about this range and its treatment in perl 5.8 that I still need to understand better.)

Anyway, try this:

use Encode; # ... $fileAsked = decode( "iso8859-1", $fileAsked);
and then see whether "VALID4" shows up. Check the Encode man page for more options (e.g. trapping character conversion failures using eval).

Replies are listed 'Best First'.
Re^2: problems matching umlauts in env vars
by december (Pilgrim) on Aug 02, 2004 at 04:56 UTC

    Yeah, it does, thanks. I don't understand how perl succeeds in converting the 8bit string in PATH_TRANSLATED to the one given in decode though... I've tested several browsers; some send utf-8, and some seem to send iso-8859-1 or iso-5589-15. The $fileAsked variable could be in any charset, really.

    Oh well... I hope those internationalisation issues will solve itself in the next couple of years, not just for Perl, but for all software really.