Re: charencoding

Hi,

It seems i am confused on what internal vs input vs output encoding  
does (iconv). i thought it automaticly converted from $_REQUEST  
values to internal ones and from internal to printed output. Since  
you mention that input (GET/POST (not COOKIES?)) are specifically  
done  in i18n and creole needed it own conversion. What is the whole  
input/output/internal encoding about then.

I guess internally it is about sorting and finding arrays and  
needles... and such...

On May 8, 2005, at 16:55, Jean-Christophe Michel wrote:

> B.Kamer wrote:
>
>> tried that, seems to break output. either half pages (mostly on   
>> single
>> quotes(!)) or wrong characters (euro signs as garbage, etc...)  are
>> displayed.
>>
>> the solution i have now seems to work... i am just not sure what
>> changing the internal encoding halfway through your the scripts
>> actually does... is it from that point on.... or does it also change
>> existing variables that are encoded. or doesn't it matter as long as
>> your switch before using those variables to the correct encoding.  
>> or...
>>
>
> GET and POST are converted in i18N on line 313.
...what about COOKIES?...
> Maybe we should:
> - have a var in Node and in ndf to indicate the encoding of the output
> - automatically convert to utf8 the other encoded nodes output
> - provide a way for these 'old encodings' nodes to receive GET and  
> POST
> in another encoding (changing Request ?)

sound usefull...

so i am correctly asuming that at this time you need to do this  
yourself and it can be done by changing the internal encodings with  
eg iconv_set_encoding("internal_encoding", "iso-8859-1")? This is not  
incorrect practise?

> In my opinion the "right way", at least the most probable way to do
> things right, is to keep utf-8 as internal and output encoding, and  
> have
> patched for the rare cases where backward compatibility asks for other
> encodings.
ok
> Since it will be temporary,
why temporarily? you mean when 'old encodings' code is converted to  
real bc nodes. or because the whole encoding sceme is going to change  
in the future.
> I propose not to add any attribute in the
> ndf syntax, but only a param named 'encoding' to Node, and add  
> tests in
> init(), process() and render() to change temporary global encoding
> (conf->temporarilySet()) depending on local encoding... Request could
> use this value to return converted GET and POST values too.
>

again...
you would accomplish this by changing the encoding with  
iconv_set_encoding("internal_encoding", "iso-8859-1")?

>> have any conversion... which means bc will accept forms as  iso- 
>> xxxx-x
>> convert it to utf-8 and thus saves it as utf-8 in a  possibly iso
>> encoded db... It should work but isn't very nice...
>
> False, I committed a patch to php4 Creole to convert from and to db
> depending on the conf value 'encoding' in datasource conf.
> But Hans posted here the reply saying he doesn't want to keep this  
> idea
> in Creole php5 :/
> This means that for php5 anyway, no automatic control will work to
> convert encodings with datasources, the developper will have to handle
> all this by hand.

I read that thread... Seems logical if you conclude that a datasource  
could be encoded in multiple encodings. (table x in iso-xxxx, table y  
in iso-yyyy)

>>> maybe another solution would be to have $conf->temporarilySet(path,
>>> value); ?
>>
>> which path do you mean?
>
> a conf var path, like '/i18n/default_character_output_encoding'.
> In fact 'internal_encoding' is not a conf value, maybe it should be
> explicit.

i understand what a path does in this context, just not which  
configuration value you meant... (btw i pitched a method name on #184)



thanks

Bas
_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev