Re: PHP 6
| From: | Moriyoshi Koizumi | Date: | Sat, 13 Mar 2010 03:57:45 +0000 |
| Subject: | Re: PHP 6 | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-47212@lists.php.net to get a copy of this message | ||
Huh? mbstring has been capable of handling lots of encodings other
than UTF-8 since it was introduced.
We might often find it annoying that Unicode is handled transparently
through I/O functions when the internal encoding is different from the
outside encoding. It just seems you didn't ever make a serious
internaltionalized application.
Moriyoshi
On Sat, Mar 13, 2010 at 3:34 AM, Derick Rethans <derick@php.net> wrote:
> On Fri, 12 Mar 2010, Hannes Magnusson wrote:
>
>> On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi <mozo@mozo.jp> wrote:
>> > I'd love to see my brand-new mbstring implementation in the release.
>> > Dropping mbstring completely won't be any good because lots of
>> > applications rely on it, but I don't really want to maintain the funky
>> > library bundled with it.
>>
>> Thats actually one of the ideas we had on IRC.
>> That mbstring patch and more ext/intl features should be enough to
>> solve "the unicode problem".
>
> Sorry, but that is not true. intl and mbstring can provide functionality
> to deal with UTF 8 string manipulation functions, they can not provide
> proper Unicode support. Proper Unicode support is *not* only just
> dealing with UTF-8 strings. Proper Unicode support includes dealing with
> file streams, with different encodings, with localiztion, with sorting,
> with locales, with formatting numbers. Offloading this to extensions
> makes Unicode support an add-on hack, and not a language feature. I am
> not saying that intl and mbstring aren't *useful*, but they definitely
> do not solve "the unicode problem".
>
> regards,
> Derick
>