Re: charencoding

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

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.
Since it will be temporary, 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.

> and then there is still the issue of the backend that currently  doesn't
> 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.

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

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