Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62540
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <503A7F8D.5070200@sugarcrm.com>
References: <5036551E.1030804@lerdorf.com> <503A7F8D.5070200@sugarcrm.com>
Date: Mon, 27 Aug 2012 06:57:04 +0900
Message-ID: <CAGa2bXbAAQb5ZHkBFcVfP0pT1xG5xzDPFik=Nse-FWSaXrWSvA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Default input encoding for htmlspecialchars/htmlentities
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

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?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net