PCRE should operate in UTF-8 mode.
On 25-Jan-07, at 10:15 AM, Nuno Lopes wrote:
So are you saying that php will automatically issue setlocale() calls?
e.g.:
<?php
i18n_loc_set_default('pt_PT'); // or whatever that is called these
days
//now it magically calls setlocale('pt_PT', 'pt_PT.iso8859-1',
'portuguese'); -- linux/bsd/windows
echo preg_match('/^\w+$/', "àáãçêõ"); //prints 1?
?>
Nuno,
The idea is that while internal libs will use it, PHP will do all
the user-locale handling internally.
On 25-Jan-07, at 9:52 AM, Nuno Lopes wrote:
PHP needs locale insensitive strcasecmp() or your developers
will continue
hitting string comparison issues in Turkish and Azerbaijani.
Ilia patched
it in timezone parsing code. Some day other strcasecmp will
pop in other
place.
Switching locale everytime you want to compare strings is a
hack and not a
bug fix.
Its a solution that works. There are very few instances where
such behavior is needed and in php6 it won't be relevant anyway
since posix locales will not be used.
This is not true at all.. I even think this is a big
misconception of PHP 6.
Although this has nothing to do with the issue mentioned above,
we will still need setlocale() in PHP 6 because of externals
libs. Even the bundled PCRE uses locales, and that is very
handful (e.g. locale-dependent '\w'). So, POSIX locales will be
deprecated for string handling, date formatting and such things,
but they will still be used by external libs.
Nuno
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
