Re: charencoding

B. Kamer wrote:
> 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.

Quite complex indeed, I agree... Php should handle this simply but it
doesn't :/

>> GET and POST are converted in i18N on line 313.
> 
> ...what about COOKIES?...

I didn't convert COOKIES, but maybe should. The pear library didn't
convert them iirc, so didn't I.

>> 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...

I think it could allow to make nodes with various encodings coexist till
everyone use only utf8.

> 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?

If it works, it's correct ;-) The idea would be to have a simple & clean
way to do it, but the basic idea is there.
My idea is to change node so:

- if node produces utf8, we suppose it wants utf8 in input too, request
returns POST and GET in utf8 version, output produced is not converted
- if node produces iso8859-1, we suppose it wants iso8859-1 in input
too, an then request would return POST and GET in iso8859-1 version;
output of the node is then converted into utf8

>> 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.

In some years everybody will use utf8 only, I guess...

>> 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")?

rather Request would use i18N globals for internal & output encoding,
and convert POST and GET accordingly; node output would be converted if
the encoding declared by the node doesn"t  match the global encoding for
the site.

>> 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)

See Hans reply entitled '[binarycloud-dev] Re: translation of core files'.


>> 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)

Yes the idea would be to have explicitly in i18n.conf:
   internal_encoding
   output_encoding

And each node would have a param 'encoding', being both internal and
output encoding.

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