Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58892
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F5E5893.9030903@lerdorf.com>
References: <4F5D9C77.3030000@lerdorf.com>
	<4F5DA152.10109@sugarcrm.com>
	<4F5DA894.8060606@lerdorf.com>
	<4F5DAB49.3030808@sugarcrm.com>
	<4F5DAFCE.8020600@lerdorf.com>
	<4F5E5148.4030106@sugarcrm.com>
	<4F5E5219.7080501@lerdorf.com>
	<4F5E53C3.8060502@sugarcrm.com>
	<4F5E5893.9030903@lerdorf.com>
Date: Mon, 12 Mar 2012 21:19:59 +0100
Message-ID: <CAEZPtU4Z-YNMMk4ZewhZbYp+BjJcayusxehXcTZFs=scGw0dHQ@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] default charset confusion
From: pierre.php@gmail.com (Pierre Joye)

hi Rasmus,

On Mon, Mar 12, 2012 at 9:12 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> If everything was UTF-8 we wouldn't have any of these issues.
> Unfortunately that isn't the case. The question is what to do with apps
> that need to deal with non UTF-8 data. Are we going to provide any help
> to them beyond just telling them to convert everything to UTF-8?

That's not really an acceptable solution, obviously.

> We took steps in 5.4 to improve htmlspecialchars to understand more
> encodings and we have the concept of script_encoding and
> internal_encoding that is used both in the engine and in mbstring.
>
> Currently internal_encoding isn't checked by htmlspecialchars. If you
> pass it '' it checks script_encoding and default_charset which is a bit
> odd since neither directly relate to the encoding of the internal data
> you are feeding to it. So maybe a way to tackle this is to use the
> mbstring internal encoding when it is set as the htmlspecialchars
> default when it is called without an encoding arg.

That's why I would prefer to use an existing setting and clearly
document it instead of creating a new ini settings with a totally
different impact than the existing ones. Not sure which one would fit
best tho'.

Reading these last two paragraphs gave me a headache and I did not
know anymore which encoding we were talking about ;-)

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org