On 12/03/12 20:51, Stas Malyshev wrote: > Hi! > >> 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. > > No, it's not like timezone at all. I have to support all timezones in > a global app, but I don't have to internally support every encoding on > Earth - having everything internally in UTF-8 works quite well, and a > lot of applications do exactly that - they have everything internally > in UTF-8 and only may convert when importing or exporting the data. I > don't see anything in using UTF-8 throughout the app/library that > makes it non-portable. However, if we allow to change defaults in > htmlspecialchars() etc. that essentially makes having defaults useless > as I'd have so explicitly specify UTF-8 each time - otherwise it's a > gamble what encoding I'd actually get. If you are a framework developer, and really want to shield against a bad php.ini setting, you could ini_set() to your prefered charset at the beginning of the request.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
