> Ah, that's a problem I've had before :) The absolutely totally latest AxKit
> CVS *might* fix that problem. If it doesn't, you might want to have a look at
> AxKit::XSP::CharConv:
>
> <xsp:expr>
> <char:charset-convert from='EUC'>$foo</char:charset-convert>
> </xsp:expr>
>
> That should take care of converting whatever your input is to UTF-8 (you can
> use it to convert to whatever, so long as your iconv supports it).
I looked at the CVS, and I don't think this issue is addressed. And
quite frankly, I don't want to have to add more taglibs for every
"outside" variable that I need to use, so I have a proposition:
Is it ok if we force the result of a <xsp:expr> to be converted to UTF,
no matter what? Attatched is the diff of this proposition.
This may be too naive and brute force of a way to address this, but
maybe this can trigger brighter minds to come up with a better solution.
--d
Index: lib/Apache/AxKit/Language/XSP.pm
===================================================================
RCS file: /home/cvs/AxKit/lib/Apache/AxKit/Language/XSP.pm,v
retrieving revision 1.59
diff -r1.59 XSP.pm
9a10
> use Apache::AxKit::CharsetConv;
282a284,286
> "use Apache::AxKit::CharsetConv;",
> 'use vars qw/ $CONVERTER /;',
> "BEGIN { \$CONVERTER =
>Apache::AxKit::CharsetConv->new( '$e->{ XSP_Encoding }' => 'UTF-8' ) }",
616c620
< my $text = $document->createTextNode("".do {
---
> my $text = $document->createTextNode( $CONVERTER->convert( "".do {
620c624
< return 'do {';
---
> return '$CONVERTER->convert( do {';
626c630
< my $text = $document->createTextNode("".do {
---
> my $text = $document->createTextNode( $CONVERTER->convert( "".do {
691c695
< }); # xsp tag
---
> })); # xsp tag
697c701
< return '}';
---
> return '})';
702c706
< }); # non xsp tag
---
> })); # non xsp tag
826a831,833
>
> $self->{ Handler }->{ XSP_Encoding } = $doc->getEncoding;
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
