Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58886
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.215.170 cause and error)
Message-ID: <4F5E5219.7080501@lerdorf.com>
Date: Mon, 12 Mar 2012 12:44:25 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: PHP internals <internals@lists.php.net>
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>
In-Reply-To: <4F5E5148.4030106@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] default charset confusion
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 03/12/2012 12:40 PM, Stas Malyshev wrote:
> Hi!
> 
>> And yes, it may very well be dangerous to use the wrong charset and now
>> that we have better support for GB2312 and other asian charsets in the
>> entities functions in 5.4 it is even more prudent to choose the right
>> one so we should provide some way to help people get it right short of
>> changing every call.
> 
> I'm not sure "changing every call" is such a big problem - it's one grep
> and one replace, can be done in one line of sed/awk/perl/php probably.
> But a bigger issue is here that people insist on using wrong charsets
> and expect language to have some magical external defaults that work for
> exactly their use case, instead of doing what they should be doing all
> along - putting charset right there in the argument.
> We need to get people off this mindset fast, since it is not a good one.
> Having tons of hidden defaults that modify behavior of functions called
> with the same arguments in hundreds of different ways is a coding and
> maintenance nightmare. Now if I write htmlspecialchars() I can never be
> sure if works right and uses UTF-8 - what if somebody messed with the
> INI setting because of some other broken library that required that to
> work?

But you can't necessarily hardcode the encoding if you are writing
portable code. That's a bit like hardcoding a timezone. In order to
write portable code you need to give people the ability to localize it.

-Rasmus