On Fri, 2003-12-12 at 23:28, Ilia Alshanetsky wrote: > On December 12, 2003 04:18 pm, Moriyoshi Koizumi wrote: > > I disagree, because of the following reasons: > > > > 1) Not a few people *actually* use fgetcsv() commonly > > with multibyte characters indeed. Regarding this, > > applications made by those who don't use > > such characters don't (and won't) use multibyte specific > > functions and that's the problem. This greatly prevents > > them from being portable. > > People have lived without multibyte support in fgetcsv() for many years now, > and I did not see a single request on bugs.php.net for fgetcsv() multi-byte > support. So, while this is certainly useful functionality I do not believe it > is as widely needed as you say it is. We also have a multibyte extension that > already implements multi-byte safe variants of common functions, why make > exception for fgetcsv() and add multibyte code into core?
Just an observation: it seems that the PHP users who need multibyte support are generally self-supplied by default. It's often hard to convince programmers to change their code as fundamentally as you often need to do to support not just UTF-8 but the whole range of CJK charsets, it adds complexity and can slow things down. These users are used to maintaining their own patches for all kinds of software. The process of merging in multibyte character features often takes several years. Because of this (if my observation is correct), you can't really tell for example how many Japanese users are having issues with fgetcsv() by counting requests on bugs.php.net. I agree with Moriyoshi Koizumi that performance is not necessarily the primary factor here. IMHO performance is important, but generality and realibility is more so. With all due respect to everyone, I think that we should be a bit more welcoming to people who offer help in making PHP a better language for CJK websites. There's still a huge amount of marketshare waiting for PHP in Asia. :-) - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
