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.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to