And I think PerlSetEnv would not work anyway.
It will set PERL_UNICODE in time for the handler/script to print it, but
probably too late for Perl to take it into account, since by that time
the Perl interpreter is already up and running, so the internal
$^UNICODE variable is already set since a long time.
That's why I was asking when it was being set.
By the way, in my case (apache2/mp2 and virtual servers), the Apache
SetEnv sets $ENV{PERL_UNICODE} for the handler, but $^UNICODE remains 0.
One more thing to try : doing a
use open ':utf8';
in the global mod_perl startup script.
Rob French wrote:
Setting the environment variable has always worked. mod_perl can "see"
the PERL_UNICODE variable is set based on the fact that the
${^UNICODE} variable is returning 63 (SDA). The problem is that it
seems to ignore it.
On Wed, Mar 19, 2008 at 12:01 PM, Dondi Stroma <[EMAIL PROTECTED]> wrote:
Maybe you need to use PerlSetEnv ?
----- Original Message -----
From: "Rob French" <[EMAIL PROTECTED]>
To: "André Warnier" <[EMAIL PROTECTED]>
Cc: <modperl@perl.apache.org>
Sent: Wednesday, March 19, 2008 2:41 PM
Subject: Re: [mp1] Can't get UTF8 input streams to automatically be decoded
using PERL_UNICODE under mod_perl
I have tried setting it via Apache SetEnv directive as well as in my
environment as root when starting Apache. In both cases the variable
is correctly set in mod_perl it is just ignored.
As another test I tried the same code as a plain ol' CGI script and it
works in that case. So the issue is definitely with mod_perl and its
interaction with the PERL_UNICODE env variable.
Thanks for your help investigating. I was worried that it might be a
mod_perl 1.x thing or a Perl version thing. Good to know it isn't just
my setup :)
Rgrds,
Rob
