Boris Zentner wrote: [...]
May be expicitly setting the utf8 flag will work as a temp solution for you? If all your data is stored in utf8, then it will perfectly fine.
No, this will not work in my case.
Below is the revision of your test program, that does what you want. (If you didn't know, you can use APR:: classes outside of Apache, so you can run this program from the command line):
This aproach will not work for me, since the get part is out of my control. And I do not know which of the vars in the table are already utf8 at get time.
My current cure is to copy the table to a object, that works like APR::Table. With the wast of copy all the data even if it is not used.
Understood.
Another idea to get the encoding right is:
All data in the table get the right encoding ( some data is utf some not ).
You mean, what I suggested?
<quote>
It's possible that if APR::Table sees a UTF8 flag on set(), it should encode it back to the utf8 string before storing it, since as you've pointed out there is no way to restore the UTF8 flag back. But also as you've pointed out, it's a huge waste of resources. since you will need to decoded it again, when you get() it and before you can use it.
</quote>
I think it makes sense, but as I've shown in the previous example, the setting of the utf8 flag may do the trick, in which case they won't want to have the cycles wasted to convert the data back and force. Since APR::Table will have to do that and then users will need to decode it back, I think we should defer that to users. They should handle a utf8 string to APR::Table, and free APR::Table from doing work, that will be a waste for many.
Require all operations on table objects to have a cleared utf8 flag even if the data is in utf8.
You mean, when creating and returning a perl variable to the user? It never has utf8 at the moment, since we don't try to set it. Or did you mean something else?
In that case, I can use APR::TABLE and all other ill-formed data providers. But if any datasource like databases or scalars have the utf8 flag set all data is busted again. So I have to fight against perls auto conversion ( use bytes is not helpfull since I do not controll all source ). And I fear to lose somewhere.
I don't know. May be you can convince Joe that Apreq's APR::Table subclass could handle that utf8'ness.
In any case APR::Table is not designed for anything but storing and returning strings. The only problem that you are correct about is that it silently accepts PVs with UTF8 flag on and then returns the new variable, w/o it. For example we could croak if we see a perl PV with UTF8 on. But then as mentioned before for some people it'll be fine for them to have the utf8 flag set manually on retrieval.
At the moment I can't see any better solution, but leaving it as it is. Unless someone convinces me otherwise.
-- __________________________________________________________________ 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]
