httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Zentner <>
Subject Re: Apache::Request, APR::Table and UTF8
Date Thu, 07 Oct 2004 22:37:48 GMT
Hi David,

Am 07.10.2004 um 23:52 schrieb David Wheeler:

> On Oct 7, 2004, at 1:31 PM, Boris Zentner wrote:
>> This is not possible. The reason is that if you call decode for every 
>> parameter, *ALL* parameters must be in utf8. That is not true.
>> Also I can think of the DECODE_UTF8 flag from your example as a 
>> utf8-flag-on-for-all parameters in the table. This is wrong for the 
>> same reason as always off is wrong.
> Well, I suppose that depends on how you write your application. 
> Bricolage, for example, is written in such a way that it expects 
> request parameters to all be in the same character set. So to decode 
> them all would be simple (and very cool).

Thats exactly how my application work. Internaly all data is in the 
same charset for perl 5.6.1 and all is utf8 for perl >= 5.8.0.

The whole discussion came on since I do the conversion from 
Apache::Request's byte strings to perls utf8 for most but not all 
bytestrings. Then _all_ other application parts have no need to ever 
bother with any conversion. But that is not all, other parts can also 
insert data into the object ( utf8 or not).

Now I have a CGI like object, that is similar to pnotes inherited from 
Apache::Request the problem here is why use Apache::Request, if I have 
to use another tool anyway?

>> My current solution is subclass Apache::Request copy all data to a 
>> CGI like object with utf8 conversion, where needed. Then all other 
>> modules act only on the CGI object with the correct utf8 flags and 
>> values. This is far better than any hacks for all on or all off 
>> aproach.
> Yes, it would be cool and proper to have Apache::Request do UTF-8 
> conversion, which I think a subclass would easily be able to do.

Uhh, I do this already, but in fact I replace Apache::Request with 
something similar, so why using Apache::Request?

>> I understand, that APR::Table can not change it's current behavior. 
>> But Apache::Request can and should. I'm really frightened that so 
>> much emails and examples do not convert you all on how important 
>> correct data for perl is.
> I think that we're all in agreement that perl variable flags should be 
> preserved where the underlying code is designed to handle Perl data 
> (such as pnote()), not just character data (as with APR::Table).
>> Again, no conversion just back what I put in that is the minimum 
>> requirement for any data-store. There is no option, perl do it 
>> automatic.
> I think that this may not be possible given what you submit to the 
> browser and get back from the browser is not Perl data (e.g., params). 
> But pnotes(), for example, should do the right thing.

Hmm, look:

1. the data touch my server all data is a sequence of bytes.
2. Apache::Request put this into a table for me. ( the data is 
untouched utf8 or not )
3. my module inherited from Apache::Request convert the utf8 data to 
utf8 with the flag inside the inherited new.

   my $c = 0; # a counter to convert only some data to utf8
   for ( values %$t ) {
     $_ = Encode::encode_utf8($_) if ( $c++ & 1 );

I need only these lines in step three and all other modules can use the 
Apache::Request object and get straight data. Otherwise I need to copy 
the data to maybe pnotes.

a $t->get should return now the correct data regardless if the flag was 
on or off. A $t->set store the data ( the same data as it does now ) 
but also the flag. If a $t->get read the data back the flag is 
restored. If the data is passed to the next handler in mod_perl it 
works as before ( it drops/ignores the flag, the data is the same ).


View raw message