tart here:
http://perldoc.perl.org/perlunicode.html
i think you're going to have to handle alot of this yourself ...
bonne chance.
_
From: Dichi [mailto:dich...@gmail.com]
Sent: Tuesday, August 31, 2010 3:06 PM
To: modperl@perl.apache.org
Subject: UTF-8
Hi,
I'm sure this gotta be one of
Hi,
I'm sure this gotta be one of the top questions. We're using mod_perl 1.3.41
with Apache 1.3 and we're wondering how does mod_perl handle unicode
strings. Does mod_perl convert STDOUT into utf-8 ?
Thanks
Torsten Foertsch wrote:
On Sun 22 Jun 2008, André Warnier wrote:
Now, the first thing I would like to understand is why this is so.
Since this is a POST, and since the browser knows that "everything" is
UTF-8, I would expect it to send the proper multipart POST, with each
item marke
André Warnier wrote:
Hi.
I apologise if this is not really a mod_perl problem, but this list
might be my best chance to find the competences required for some tips.
Platform : SunOS 5.8 (Solaris 8)
Apache : Apache/2.0.52
Perl : v5.8.5 built for sun4-solaris
CGI.pm : 3.37
That version of CGI
On Sun 22 Jun 2008, André Warnier wrote:
> Now, the first thing I would like to understand is why this is so.
> Since this is a POST, and since the browser knows that "everything" is
> UTF-8, I would expect it to send the proper multipart POST, with each
> item marked as UTF-
UTF-8 encoded, and has (in addition) a meta tag which
says so. The browser "knows" it is UTF-8 (verified).
The itself has an Accept-charset=utf-8 attribute.
Among the values send by the applet in the post, are some paths names,
of files on the workstation (Windows).
The html
On Nov 16, 2007 10:34 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> On 16.11.2007 17:08 Michael Peters wrote:
> > binmode(STDOUT, ':utf8');
>
> that did the trick, many thanks!
>
> - Michael
Michael - what version of mod_perl are you using?
On 16.11.2007 17:08 Michael Peters wrote:
> Is this a mod_perl problem? You didn't mention if it occurred in
plain CGI or not.
It would be difficult to port the application to plain CGI but you are
right, I could have built an independent test script. But because I
could swear I did
perform the encoding yourself
before call it, e.g.:
$r->print(Encode::encode('utf-8', $html));
Michael Lackhoff wrote:
> use utf8;
> sub streamtest {
> my $self = shift;
> $self->header_type('none'); # for streaming
> # Write the content type to the client...
> my $r = $self->param('r');
> $r->content_ty
On 16.11.2007 17:39 E R wrote:
> On Nov 16, 2007 10:34 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
>> On 16.11.2007 17:08 Michael Peters wrote:
>
>> > binmode(STDOUT, ':utf8');
>>
>> that did the trick, many thanks!
>>
>> - Michael
>
> Michael - what version of mod_perl are you using?
2.0
On Nov 16, 2007 10:42 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
>
> On 16.11.2007 17:39 E R wrote:
>
> > On Nov 16, 2007 10:34 AM, Michael Lackhoff <[EMAIL PROTECTED]> wrote:
> >> On 16.11.2007 17:08 Michael Peters wrote:
> >
> >> > binmode(STDOUT, ':utf8');
> >>
> >> that did the trick, ma
Hello,
I have a problem printing UTF-8 from mod_perl.
The sample-/test-code looks like this:
use utf8;
sub streamtest {
my $self = shift;
$self->header_type('none'); # for streaming
# Write the content type to the client...
my $r = $self->param('r');
You will want to do 2 things:
1. Set the content type to utf8 ($r->content_type)
2. Encode your output to utf8 (if it's not done already. Sometimes it's
just latin1)
Cristina Nunes wrote:
Hi.
I was wondering how I could set the mod_perl (1.x) STDOUT (and STDERR)
to expect utf8 char encoding?
Hi.
I was wondering how I could set the mod_perl (1.x) STDOUT (and STDERR)
to expect utf8 char encoding?
In perlrun, you can just set it by using -CS parameter, ie, `perl -CS
-le 'print "olé"'`, or at runtime binmode(STDOUT, ":utf8");
Thanks,
Cristina
--
Saying that Java is nice because it wo
none assumed
my $utf8_aware_string = decode_utf8( $known_to_be_utf8 );
..
# the above works (we get our data back in one piece)
# and of course the HTML entities have been turned into UTF-8 chars
}
I tried some form attributes:
enctype="multipart/form-d
tf8 = $q->param('test'); # form post doesn't
> give charset, none assumed
>my $utf8_aware_string = decode_utf8( $known_to_be_utf8 );
>..
># the above works (we get our data back in one piece)
># and of course the HTML entities ha
On Jun 5, 2007, at 12:56 PM, John ORourke wrote:
my $q=Apache2::Request->new($r);
my $known_to_be_utf8 = $q->param('test'); # form post doesn't
give charset, none assumed
slightly off topic, my suggestion on implementation would be along
the lines of this:
package Context();
Hi folks,
I've been dragged kicking and screaming into the 21st century and am
making my mod_perl application fully utf-8 aware and transparent. It's
all going OK but I want to know if anyone has a better solution to
receiving form data containing non-ASCII chars.
Output is fi
I realise that you're probably not using template toolkit, but on a
separate but related note:
For those on the list using Template Toolkit, if your templates contain
UTF8, you need to prefix them with a UTF8 BOM for them to be recognised
as UTF8, otherwise TT gets really confused.
See here for m
with templates, we tell
Perl that the file is UTF-8 formatted, by creating the file handle as such, and
that's it really; internally Perl automatically treats that string content as
UTF-8 unless we state otherwise explicitly. We use the Encode module all the
time to convert between UTF-8 a
>
>We also do everything (not source code, which is in ISO-8859-1, only content)
>in UTF-8 where I >work, and we support many different languages.
Jeff,how did you do it by using utf-8 for everything?can you give a rough
description?Thanks.
--
mailto: [EMAIL PRO
We also do everything (not source code, which is in ISO-8859-1, only content)
in UTF-8 where I work, and we support many different languages. We never use
any apache configurations or make any explicit reference to the OS locale being
used. As of Perl 5.8*, internally Perl assumes UTF-8 for
I should be using "PerlPassEnv LANG" or something.
I don't know that much about unicode, but I do remember that Perl does
some automatic encoding in certain situations. There was that problem
in Red Hat a few years ago when they set LANG to UTF-8 and it broke
all kinds of CPAN mo
anged the following in Apache
to add support for UTF-8 charset:
AddDefaultCharset UTF-8
The application itself doesn't handle character set encoding as I
verified
with the vendor that they don't have anything to do with character
encoding
and they verified that their application is work
If I instruct the browser to render to UTF-8, The strange characters disappear,
but the proper characters don't show up - instead I get the gap indicative of a
non-rendering character or nothing at all, depending on the browser (IE and FF
do different things here - big surprise).
The pr
Philip M. Gollucci wrote:
> Jason Rhinelander wrote:
>> Is it, then, intentional?
> You know, I'm not entirely sure, but I betting its because
> STDIN, STDERR, STDOUT are re-tied to the streams in the request object
> automagically for you in Registery/PerlRun under the 'perl-script'
> Handler. Un
Gunnar Koppel wrote:
> Seems my joy was too early. As i said, I alway use uppercase
> filehandlers and so was in every real situation, where was this problem
> with UTF<->modperl2.
>
> As a script solution with STD* works fine, but as a handler it gives
> same output as earlier.
>
> My little tes
Gunnar Koppel wrote:
Gunnar Koppel kirjutas:
Thank you and all others! That's it. BTW, i always use uppercase
Seems my joy was too early. As i said, I alway use uppercase
filehandlers and so was in every real situation, where was this problem
with UTF<->modperl2.
As a script solution wit
lpha = qw(a b c d e f g h i j k l m n o p q r s š z ž t u v õ ä ö
ü x y);
$q = new CGI;
print $q->header(-type=>"text/plain", -charset=>"UTF-8", -cookie=>'');
print "\u$_ " foreach @alpha;
print "\n";
On Fri, May 26, 2006 at 11:44:29PM -0700, Jason Rhinelander wrote:
> [EMAIL PROTECTED] wrote:
[...]
> It is, because in Perl stdin, stdout, and stderr are aliases for STDIN,
> STDOUT, and STDERR [...]
You're right. Sorry for the noise.
Regards
-- tomás
signature.asc
Description: Digital signat
Jason Rhinelander kirjutas:
The script as above doesn't work out of the box -- the '$lc' variable
isn't defined. Commenting out that line, I got the same results as you
Yes, i took out some lines from my test script, which defined $lc, but
forgot still this line. Oops.
and eventually figu
Jason Rhinelander wrote:
Is it, then, intentional?
You know, I'm not entirely sure, but I betting its because
STDIN, STDERR, STDOUT are re-tied to the streams in the request object
automagically for you in Registery/PerlRun under the 'perl-script'
Handler. Under the mod_perl handler, these ar
Philip M. Gollucci wrote:
>> It is, because in Perl stdin, stdout, and stderr are aliases for STDIN,
>> STDOUT, and STDERR -- but that aliasing doesn't appear to be present
>> under mod_perl. Now, perhaps it was intentional, but in that case it
>> should at least be documented somewhere.
> Feel fr
It is, because in Perl stdin, stdout, and stderr are aliases for STDIN,
STDOUT, and STDERR -- but that aliasing doesn't appear to be present
under mod_perl. Now, perhaps it was intentional, but in that case it
should at least be documented somewhere.
Feel free to supply a documentation patch and
[EMAIL PROTECTED] wrote:
>> makes it work properly. This seems to me like a bug, but perhaps
>> someone more familiar with mod_perl's STDOUT tying than I can explain
>> this (or confirm this as a bug).
>
> Duh. Sorry I didn't see that before. In Perl, the file handles for
> stdin, stdout and stde
On Fri, May 26, 2006 at 02:56:17PM -0700, Jason Rhinelander wrote:
> Gunnar Koppel wrote:
[...]
> > I have little problem with UTF-8 under modperl2. I made such little
> > script for testing:
[...]
> > binmode stdin, ":utf8";
> > binmode stdout, ":utf8&quo
Gunnar Koppel wrote:
> Terr!
>
> I have little problem with UTF-8 under modperl2. I made such little
> script for testing:
>
> ---
> #!/usr/bin/perl
>
> use strict;
> use locale;
> use utf8;
> binmode stdin, ":utf8";
> binmode stdout, ":
Addition:
Seems, that under modperl2 are 4 problematic characters
(õ [otilde] ä [auml] ö [ouml] ü [uuml]) converted to ISO8859-x charset.
And i can't avoid it. Why are they converted and how to keep them as UTF?
--
Best regards,
Kõike hääd,
Gunnar Koppel
Terr!
I have little problem with UTF-8 under modperl2. I made such little
script for testing:
---
#!/usr/bin/perl
use strict;
use locale;
use utf8;
binmode stdin, ":utf8";
binmode stdout, ":utf8";
my @alpha = qw(a b c d e f g h i j k l m n o p q r s š z ž t u v
> In fact I'm not actually getting *any* headers back:
Checking your server ident you're running modperl 1.
Sure you're calling
$r->send_http_headers()
?
Carl
> http://www.verizonnoticias.com/
Sure it validates on w3c?
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.verizonnoticias.com%2FHome%2Findex.ad2
In fact I'm not actually getting *any* headers back:
$ telnet www.verizonnoticias.com http
Trying 69.88.132.175...
Connected to www.v
> -Original Message-
> From: Christopher H. Laco [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 03, 2006 12:53 PM
> To: [EMAIL PROTECTED]
> Cc: John N. Brahy; modperl@perl.apache.org
> Subject: Re: is there a way to force UTF-8 encoding
>
> Christopher H. Laco
>>> Cc: modperl@perl.apache.org
>>>> Subject: Re: is there a way to force UTF-8 encoding
>>>>
>>>> John N. Brahy wrote:
>>>>> Is there a way to force UTF-8 encoding? I have tried
>>>>>
>>>>> AddDefaultCharset
Christopher H. Laco wrote:
> John N. Brahy wrote:
>>> -Original Message-
>>> From: Christopher H. Laco [mailto:[EMAIL PROTECTED]
>>> Sent: Friday, March 03, 2006 12:28 PM
>>> To: John N. Brahy
>>> Cc: modperl@perl.apache.org
>>
John N. Brahy wrote:
>> -Original Message-
>> From: Christopher H. Laco [mailto:[EMAIL PROTECTED]
>> Sent: Friday, March 03, 2006 12:28 PM
>> To: John N. Brahy
>> Cc: modperl@perl.apache.org
>> Subject: Re: is there a way to force UTF-8 encoding
>&
> -Original Message-
> From: Christopher H. Laco [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 03, 2006 12:28 PM
> To: John N. Brahy
> Cc: modperl@perl.apache.org
> Subject: Re: is there a way to force UTF-8 encoding
>
> John N. Brahy wrote:
> > Is there
John N. Brahy wrote:
> Is there a way to force UTF-8 encoding? I have tried
>
> AddDefaultCharset utf-8 in the httpd.conf
>
> OS: OpenBSD
> Apache: Apache/1.3.29 (Unix) mod_perl/1.29 mod_ssl/2.8.16 OpenSSL/0.9.7g
>
> But
> 1) wget -S says it's Content-Type: t
Is there a way to force UTF-8 encoding? I have tried
AddDefaultCharset utf-8 in the httpd.conf
OS: OpenBSD
Apache: Apache/1.3.29 (Unix) mod_perl/1.29 mod_ssl/2.8.16 OpenSSL/0.9.7g
But
1) wget -S says it's Content-Type: text/html; charset=ISO-8859-1
2) when I try the HTML validator on w3
Markus Wichitill wrote:
Stas Bekman wrote:
Markus Wichitill wrote:
No, Perl can deal with a BOM at the start of a file. But
convert_script_to_compiled_handler() puts the BOM in the middle of
the string that is eval'ed. A bunch of raw bytes has no place in the
middle of a script.
Aha! Now it's c
Stas Bekman wrote:
Markus Wichitill wrote:
No, Perl can deal with a BOM at the start of a file. But
convert_script_to_compiled_handler() puts the BOM in the middle of the
string that is eval'ed. A bunch of raw bytes has no place in the
middle of a script.
Aha! Now it's clear. Thanks Markus.
Do w
Markus Wichitill wrote:
[...]
But first I would like to know why the script doesn't fail when run
outside mod_perl. We do nothing special here, other than read+eval,
compared to require. So it looks like a bug in perl.
No, Perl can deal with a BOM at the start of a file. But
convert_script_to_
a bad idea to add any s/// in the code, since it's
slowing things down. And it certainly shouldn't be a penalty for most
other users who don't have this problem. So this can be done in a
subclass of RegistryCooker.
Fine by me, I've told my editor to not save UTF-8 BOMs anyway,
Markus Wichitill wrote:
Stas Bekman wrote:
It seems as if mod_perl doesn't recognize the format of the script file
correctly. Any tips why this may occur? Thanks a bundle in advance!
Wow! That's interesting.
Please take a look at the code in function
convert_script_to_compiled_handler at
ModPerl
Stas Bekman wrote:
It seems as if mod_perl doesn't recognize the format of the script file
correctly. Any tips why this may occur? Thanks a bundle in advance!
Wow! That's interesting.
Please take a look at the code in function
convert_script_to_compiled_handler at
ModPerl-Registry/lib/ModPerl/Reg
ÐÐÐÑÑ ÐÑÐÐÑÐÐ wrote:
Hi everybody. I ran into a problem with Perl scripts stored in utf-8
and I couldn't find the answer to it on the Internet or mailing lists.
Please tell me what I'm missing.
SYSTEM: Windows XP SP2, Active Perl 5.8.4.810, Apache 2.048, mod_perl
1.9912.
I need to r
Игорь Кудашев wrote:
I use the Windows' Notepad and save the file as utf-8. Everything works fine
while I run the script from the command line or through CGI without mod_perl.
PROBLEM: When I try to run the script using mod_perl, I get the following ERROR:
[error] 3320: ModPerl::Pe
Hi everybody. I ran into a problem with Perl scripts stored in utf-8 and I
couldn't find the answer to it on the Internet or mailing lists. Please tell me
what I'm missing.
SYSTEM: Windows XP SP2, Active Perl 5.8.4.810, Apache 2.048, mod_perl 1.9912.
I need to run scripts stored in u
Rob Mueller wrote:
Ok, I've tracked this down a bit more, and I think it's a perl problem.
Basically it seems tainted variables and utf-8 don't work together. I did
find one example of someone posting the same problem:
http://groups.google.com/groups?q=taint+group:perl.unicode&
Ok, I've tracked this down a bit more, and I think it's a perl problem.
Basically it seems tainted variables and utf-8 don't work together. I did
find one example of someone posting the same problem:
http://groups.google.com/groups?q=taint+group:perl.unicode&hl=en&lr=&
le is that? my, our, global? Usually a variable
that once became PVMG, won't go back to a lower type PV. But it should not
have the MG flags set.
2. join with utf-8 strings doesn't seem to leave the joined string with the
utf-8 flag on
I'd try to minimize your setup to exclude e
ut I can't seem to narrow it down. Just creating a basic
handler to test this seems to work, but when it's used like this buried deep
in some code, it fails. Always a bugger of a problem to track down.
Anyway, the problem seems to be with using "join" where the array has utf-8
please post a proper bug report, Matthew. We don't even know which mp2 do you
use. A complete *real* short example is expected as well.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_
Stas Bekman wrote:
Matthew Darwin wrote:
Stas Bekman wrote:
Ah, I suppose this is a typing error:
> my $string < ...
> ...
> EOF
> print $string;
you miss '='
Sorry... writing up exmaples has inherent dangers.
Also try adding utf8::encode($string);
Tried that already. No help.
--
Matth
Matthew Darwin wrote:
Stas Bekman wrote:
Ah, I suppose this is a typing error:
> my $string < ...
> ...
> EOF
> print $string;
you miss '='
Also try adding utf8::encode($string);
Finally your bug report is missing. Please submit one, including a real
example that we can try to reproduce the pro
Stas Bekman wrote:
Can you reproduce this problem outside of mp2? just a plain perl program?
No.
Any difference if you add:
use Apache::RequestIO ();
binmode(STDOUT, ':utf8'); # Apache::RequestRec::BINMODE()
Yes, I get different garbage.
before you do the print. Or if you use $r->print() instead
Matthew Darwin wrote:
I'm not sure if anyone has noticed this, so I thought I'd post.
If I create a string using here syntax:
my $string <
And $string contains UTF-8 characters they get mangled somehow when they
go through the output chain.
However, if I build the same docum
Hello there,
On Wed, 25 Feb 2004, Matthew Darwin wrote:
> If I create a string using here syntax:
> my $string < ...
> EOF
> print $string;
>
> And $string contains UTF-8 characters they get mangled somehow when they
> go through the output chain.
>
> However, if I
I'm not sure if anyone has noticed this, so I thought I'd post.
If I create a string using here syntax:
my $string <
And $string contains UTF-8 characters they get mangled somehow when they
go through the output chain.
However, if I build the same document using
my $st
Ged Haywood wrote:
Hi Stas,
On Tue, 11 Nov 2003, Stas Bekman wrote:
[snip]
Who would think that a response handler:
print while ;
would affect the special vars in the filter called by print.
Who indeed!
[snip]
So let's decide how do we act upon this:
[snip]
I'm not sure whether we should
Hi Stas,
On Tue, 11 Nov 2003, Stas Bekman wrote:
> [snip]
> Who would think that a response handler:
>
>print while ;
>
> would affect the special vars in the filter called by print.
Who indeed!
> [snip]
> So let's decide how do we act upon this:
> [snip]
> I'm not sure whether we should
Matthew Darwin wrote:
After extensive playing around with this (inside mod_perl and out), I
have come up with two observations:
1) doing regexes on UTF-8 characters split across buckets in an output
filter seems to be not a problem. All my regexes are against ASCII
characters.
Good. But could
After extensive playing around with this (inside mod_perl and out), I
have come up with two observations:
1) doing regexes on UTF-8 characters split across buckets in an output
filter seems to be not a problem. All my regexes are against ASCII
characters.
2) mod_perl seems to get confused
Matthew Darwin wrote:
Stas Bekman wrote:
I'd suggest to take whatever data you s/// and try it outside mod_perl
first. May be your filter or some previous filter has truncated the
UTF-8 char in the middle? You should be aware that other filters are
not aware of the encoding, and they
Stas Bekman wrote:
I'd suggest to take whatever data you s/// and try it outside mod_perl
first. May be your filter or some previous filter has truncated the
UTF-8 char in the middle? You should be aware that other filters are not
aware of the encoding, and they just give you the amou
that have UTF-8 data:
[Wed Nov 05 17:30:00 2003] [error] [client 127.0.0.1] panic: sv_pos_b2u:
bad byte offset at
/kinnetics/component/perllib/site_perl/Apache/Kinnetics/Output.pm line 221.
Line 221 is the start of this regex:
s{ <\?nm( # opening angle bracket
(?:
I'm just wondering if anyone has any input on this issue. I'm
implementing an output filter, like so:
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOutputFilterHandler Apache::Kinnetics::Output
and I get the following error on some web pages that have UTF-8 data:
77 matches
Mail list logo
