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:49:41 GMT

Am 08.10.2004 um 00:29 schrieb Markus Wichitill:


> A light-weight library like apreq should not try to handle every 
> possible format under the sun, that's why I've already cautioned 
> against linking in full XML support.

But I do not want any handling, just preventing the flag if the data is 
touched from perl itself. And even the the data itself is not changed. 
I just want the utf8 flag saved. And moved around if I move the data 
from within perl.

>> Also I can think of the DECODE_UTF8 flag from your example as a 
>> utf8-flag-on-for-all parameters in the table.
> Technically utf8::decode doesn't set the flag for 7-bit strings.

That does not matter, since the data is the same set or not.

>> 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.
> We seem to mainly differ about whose responsibility it is to handle 
> the UTF-8 issue, the developer's who has all the relevant info, or 
> that of a thin XS layer over Apache internals, which doesn't know 
> anything about the context of the incoming data.

Thats right, I think a perl library should support perl where you think 
in terms of C.

> BTW, I think you make things look a bit too simple in your first post 
> by hiding much of the real complexity behind $something and 
> $something_else. I'm still not sure if you expect Apache::Request to 
> do heuristic scanning of the input to automatically determine the 
> encoding (which would be unreliable at best)?

The $something and $something_else example use keys and/or values and 
so loose the context from key to value, so a application can not know 
which data is utf8 and which not.

>> Again, no conversion just back what I put in that is the minimum 
>> requirement for any data-store.
> Stop thinking of those tables as data stores, they're APIs to a 
> webserver that doesn't really support Unicode. Of course I might be 
> biased, since I've always treated Apache::Request as a read-only 
> object anyway.

But It is allowed to put data in and I use that a lot. Also this 
explain why you can use decode since your data is never changed. In my 
case a result may replace the data again and again. And get wrong and 
wronger with every store.


View raw message