RE: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch)
| From: | Rasmus Lerdorf | Date: | Sat, 13 Dec 2003 01:47:54 +0000 |
| Subject: | RE: [PHP-DEV] Re: Regarding the latest patch on fgetcsv() (stable branch) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-6396@lists.php.net to get a copy of this message | ||
On Sat, 13 Dec 2003, Steph wrote:
> > > If you get multibyte data from a form and want to perform string
> > > operations on
> > > it such as strlen(), ereg(), etc... would you not need mb_* or iconv_*
> > > functions?
> >
> > In such a case, yes, I do. But I don't think that's directly related
> > to the issue..?
>
> The real question is, what does mbstring do that iconv fails to do? And why
> do we need to restore the initial form in any sense? And if iconv were
> built-in, would mbstring still be needed, and if so, why and where?
The cool thing that mbstring provides is transparent overloading of some
of the common string manipulation functions. This means that at least for
a subset of applications, even though they may not have been written with
multibyte support in mind, they may in fact work perfectly in a multibyte
environment with mbstring enabled and overloading turned on.
This is at the heart of this discussion, I think. We are trying to make
as many functions as possible behave correctly in both cases. Simply
saying that we should just have an mb_* version of a function to deal with
the mb issues doesn't give us the power of being able to run the same code
in both environments. If we can make an mb_ version of a function that is
similar enough argument and functionality-wise that we can cleanly
overload the non-mb version of the function causing it to do the right
thing, then I think we are most of the way there.
-Rasmus