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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
