Hi,
Am 24.09.2004 um 01:50 schrieb Stas Bekman:
Boris Zentner wrote:
Hi,
Whenever I store something into a APR::Table I get different data back. Even with a recent mod_perl I use
APR::Table stores plain strings. It doesn't know what type of a string it has stored. If you store utf8 data you need to tell perl that the string is utf8, by calling Encode::encode. It's exactly the same as getting some UTF8 data from the client, you need explicitly decode it to make Perl see it as UTF8 data.
I do understand that the data has no utf flag if I got them, but if I store data I get it wrong back. Also the utf8 flag is not for the whole table, it is for the string.
In the example I have already a string in utf8 data ($utf8). The problem is that this string lose the information and I do not know if it is a plain string or if it is one, that lost the information.
If I have to record somewhere else the utf8 flags, why should I use APR::Table at all? I can store the data better in a perl array or hash, that did not loose the data. In my case Im not sure if I know which data is utf and which is not and double encoded data is even wrong.
In my real case, I get the data from libapreq2 in raw format and my desire is to convert some of them inplace to utf8. Then the rest of my application can rely on libapreq's functions. But if the flag is lost, my output is wrong. If I have to copy the data from libapreq and track them myself, why should I use libapreq2 or any other module, that use APR::Table?
At the end a little quiz, here are four numbers, two are octal the others are decimal, witch are the octals? ;-)
2 55 26 17
I don't think you can always guess correctly, though I think Encode has some functions that try doing that. Why do you use APR::Table and not pnotes or some perl hash? It's possible that there is a problem and we could handle the in and out of the table in some better way, but your data will need to be converted back and forth every time you need it. Isn't that a waste?
Frankly, seeing the nightmare happening at p5p, I don't think we even want to venture into trying to handle UTF-8 internally on behalf of the user. I hope that we could stay out of it.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
