httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Zentner <...@2bz.de>
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 ).

--
Boris


Mime
View raw message