Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62541
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.220.170 cause and error)
Message-ID: <503A9CB5.2010506@lerdorf.com>
Date: Sun, 26 Aug 2012 15:01:25 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 PHP internals <internals@lists.php.net>
References: <5036551E.1030804@lerdorf.com> <503A7F8D.5070200@sugarcrm.com> <CAGa2bXbAAQb5ZHkBFcVfP0pT1xG5xzDPFik=Nse-FWSaXrWSvA@mail.gmail.com>
In-Reply-To: <CAGa2bXbAAQb5ZHkBFcVfP0pT1xG5xzDPFik=Nse-FWSaXrWSvA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Default input encoding for htmlspecialchars/htmlentities
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 08/26/2012 02:57 PM, Yasuo Ohgaki wrote:
> Hi,
> 
> 2012/8/27 Stas Malyshev <smalyshev@sugarcrm.com>:
>> Hi!
>>
>>> In PHP 6 we tried to introduce separate input, script and output
>>> encoding settings. Currently in 5.4 we don't have that, but we have
>>> those 3 separately for mbstring and for iconv:
>>>
>>> iconv.input_encoding
>>> iconv.internal_encoding
>>> iconv.output_encoding
>>> mbstring.http_input
>>> mbstring.internal_encoding
>>> mbstring.http_output
>>>
>>> Ideally we should be getting rid of the per-feature encoding settings
>>> and have a single set of them that we refer to when we need them. This
>>
>> I agree, having unified set of encodings would be a good thing. However,
>> I have a feeling most of the people won't really understand what these
>> three do, and would never bother to set them. From my experience, people
>> don't even bother to set PHP timezone, even though PHP complains each
>> time date function is accessed. So these will be left as default in
>> 99.999% of cases.
> 
> I agree. Other than applications that are made by CJK native, I rarely
> see them set.
> 
>>
>>> So do we create a new default_input_encoding ini directive mid-stream in
>>> 5.4 for this? Of course with the longer-term in mind that this will be
>>> part of a unified set of encoding settings in 5.5 and beyond.
>>
>> What happens to these 6 directives? Will we now have 9 directives for
>> setting the encoding? This reminds me of: http://xkcd.com/927/. Having
>> yet more settings is not really a solution to the problem of too many
>> different settings. So unless we deprecate all others in 5.5 and have
>> people use only generic ones it's not very useful. If we do deprecate
>> them, we need some kind of migration path - i.e. if you set
>> iconv.input_encoding what actually happens? If you set
>> default_input_encoding will it also set mbstring.http_input - or will it
>> affect mbstring without actually setting it?
>> I guess we'd need a good detailed RFC on this :)
> 
> If I write patch for it, I'll modify iconv.*/mbstring.* to use php.* (or zend.*)
> When default_chartset is set and other settings are null, use it as
> default for all including htmlentities(), mb_*(), etc.
> 
> default_charset will be single encoding configuration if user uses
> single encoding for application.
> 
> How to deal with iconv.*/mbstring.*
>   master: remove iconv.*/mbstring.*
>   5.4: iconv.*/mbstring.* remains for compatibility and use them it they set.
> 
> We could remove iconv.*/mbstring.* for 5.4. It's a big change for CJK
> users but they will be okay with it. Almost all users are using single
> encoding for application anyway.
> 
> I think removing iconv.*/mbstring.* for master and5.4 would be nicer.
> Any opinions?

We can't remove them in 5.4. We can add new ones without breaking
anything and we can make mbstring/iconv/html* use those if they are set
and then mark the mbstring/iconv settings as deprecated in master.

-Rasmus