On Mon, Dec 6, 2010 at 7:49 PM, Dmitry Stogov <dmi...@zend.com> wrote: > Hi Moriyoshi, > > On 12/06/2010 01:31 PM, Moriyoshi Koizumi wrote: >> >> Hi, >> >> How about using the value of mbstring.script_encoding to determine >> whether to enable the encoding conversion feature? If the value is >> the same as that of mbstring.internal_encoding, then no conversion >> should be needed in the first place. Besides we can define some >> singular value like "none" that completely disables the conversion. > > Right now I introduced zend.multibyte directive which enables to look into > mbstring.script_encoding and mbstring.internal_encoding as it did before > with --enable-zend-multibyte. Note that we can't check for them in ZE > directly because ZE knows nothing about ext/mbstring. It may be not compiled > into PHP or compiled as DSO. Probably it's possible to do through additional > callbacks.
Indeed mbstring.script_encoding is only used by zend_multibyte, so it would make sense to alter the name of the ini setting to something like zend.script_encoding, and move the relevant part of mbstring.c into zend_multibyte.c > >> Regarding the dependency on mbstring extension, I think it's time to >> enable mbstring by default. > > The idea I'm working on is to provide an ability to enable/disable all > multibyte features without PHP recompilation. So the same binaries will be > able to support Asian languages and work with European without performance > degradation. My second patch adds the missing parts (POST request parsing, > htmlentities, EXIF). I sent it to internals@ today. I am totally fine with the idea. I just mentioned it in terms of users' convenience. > Thanks. Dmitry. > >> >> Regards, >> Moriyoshi > Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
