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 <der...@php.net> wrote: > On Fri, 12 Mar 2010, Hannes Magnusson wrote: > >> On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi <m...@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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
